 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : NY Geothermal GUI Interrupts
| Author | Message | ||||
| Paul_L Guru  Joined: 03/03/2016 Location: United StatesPosts: 769 |
I am thoroughly confused by the GUI controls for the uM+ MMBasic. Please examine the following code fragment. Option Explicit const numbox1=20 dim var1=124.6 dim ctrlval(numbox1)=var1 CLS GUI Interrupt TouchDown, TouchUp GUI Numberbox numbox1, 100, 100, 100, 100, RGB(yellow), RGB(64,64,64) mainline: do ' time dependent repeating code goes here ' which must repeat at least every minute or so ' and will manipulate any variables including those assigned by GUI controls var1 = somethingelse ctrlval(numbox1) = var1 loop sub TouchDown select case touch(REF) case numbox1 'numbox1 is touched var1 = ctrlval(numbox1) ' assign result of numbox1 to var1 end select end sub Note that I assign var1 (a floating point number) to ctrlval(numbox1) before the mainline, but var1 can be changed in the main loop. Do I have to repeatedly reassign ctrlval(numbox1)=var1 in the main loop each time var1 is changed? If the value of var1 changes in the main loop will the value displayed in numbox1 change as soon as ctrlval(numbox1)=var1 is executed or must numbox1 be touched first for the displayed value to change? When the numbox1 numberbox is touched a numeric keypad will pop up on the screen and the user will be able to enter a new number for ctrlval(numbox1). Does this mean that the code has entered the TouchDown procedure? While the keypad is visible and the user is keying in numbers will the mainline loop continue to cycle or will it be interrupted? |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Hi Paul, Just played with that code a bit, not sure that the sub is needed. I got it to work like this:- [Code]Option Explicit const numbox1=20 dim Float var1=124.6 CLS 'GUI Interrupt TouchDown', TouchUp GUI Numberbox numbox1, 100, 100, 100, 100, RGB(yellow), RGB(64,64,64) ctrlval(numbox1)=var1 mainline: do Pause 500 ' time dependent repeating code goes here ' which must repeat at least every minute or so ' and will manipulate any variables including those assigned by GUI controls ' var1 = somethingelse var1=ctrlval(numbox1) Print Var1 loop sub TouchDown select case touch(REF) case numbox1 'numbox1 is touched var1 = ctrlval(numbox1) ' assign result of numbox1 to var1 end select end sub [/code] The PRINT command proved that the main loop was still running while the number pad was displayed & waiting for input. Phil. |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
@Phil Thanks for taking a look at the code. As near as I can tell the TouchDown sub is where changed ctrlval(numbox1) values returned by the magic GUI NUMBERBOX are assigned to var1. The TouchDown sub case selection will normally separate return values from a whole bunch of different magic GUI NUMBERBOXes. Did you use the displayed number pad to change the value of var1? Did the main loop repeatedly print the original value of var1 until you changed it? Did the main loop print the new value of var1 after you entered it? I have several reasons for trying to determine if using one cpu chip will work. Note that there are currently 365 numeric variables which currently need to be passed back and forth between two cpus, MAIN and USER. 219 of these vars are user settings and 136 are observed or calculated values. 1. I believe that the new uM+ chips probably have way more power than is needed to be able to accept slow motion user inputs via interrupts and continue the repetitive main loop calculations without serious delay. 2. I believe that the communication routines needed to pass all the 365 vars back and forth between a MAIN cpu chip and a USER cpu chip will use more MAIN and USER cpu time than the handling of interrupts from the touch display using a single cpu chip. 3. The communication code needed to pass the 365 vars back and forth between a MAIN cpu and a USER cpu will probably amount to between 100 and 300 lines of code in each cpu, depending on whether the vars are encoded as arrays or as individual named variables. This increase in code requirement will just increase the chance of making a typographical or lexicographical coding misteak. See what I mean? What do you think about this????? Paul. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Yes, you do seem confused but you are not alone there. Many people find GUI programming difficult until they get the hang of it. There are a couple of issues in the first few lines. For a start CtrlVal can be used as a command or a function but in either case you cannot DIM it (ie, you cannot create it) like a variable (as pointed out by Phil). The second issue is that you are trying to set the value of the numberbox before it has been created - this will throw an error. Your code should be something like this: Option Explicit
const numbox1=20 dim var1=124.6 CLS GUI Interrupt TouchDown, TouchUp GUI Numberbox numbox1, 100, 100, 100, 100, RGB(yellow), RGB(64,64,64) ctrlval(numbox1)=var1 This will create the numberbox and then set its value to 124.6. MMBasic will immediately update the control on the screen to display this value. The other issue is that you seem to be using the numberbox for two jobs. Firstly, you are using it to display the value of var1. Secondly you are allowing the user to enter a new number into the numberbox. These will clash. For example, if the user does enter a new number it will be immediately be overwritten by the value of var1. Even worse, the value of the numberbox will be continuously updated (in the main loop) while the user is keying in a new number - I don't have an MM+ on hand to test this scenario but I am sure that the result will be messy (yes, the main loop keeps running even while the keypad is active). Another problem is that you are getting the value of the numberbox in the pen down interrupt. This happens when the user first touches the control, ie before he has entered anything. If you want to get the user's entry you should do that in the pen up interrupt, which signifies that the numberbox has removed its virtual keypad. I am not sure what your program is doing but perhaps it could be rewritten to something like this: Option Explicit
const numbox1=20 dim var1=124.6 dim flag1 = 1 CLS GUI Interrupt TouchDown, TouchUp GUI Numberbox numbox1, 100, 100, 100, 100, RGB(yellow), RGB(64,64,64) ctrlval(numbox1)=var1 mainline: do ' time dependent repeating code goes here ' which must repeat at least every minute or so ' and will manipulate any variables including those assigned by GUI controls var1 = somethingelse If(flag1 = 1) Then ctrlval(numbox1) = var1 loop sub TouchDown select case touch(REF) case numbox1 ' numbox1 is touched flag1 = 0 ' prevent update of the control by the main loop end select end sub sub TouchUp select case touch(LASTREF) case numbox1 ' touch is removed from numbox1 var1 = ctrlval(numbox1) ' assign result of numbox1 to var1 flag1 = 1 ' allow the control to be updated by the main loop end select end sub This is still not the best. For the user it could be confusing - he (she?) enters a number into the number box and immediately it starts changing. They will think "did I enter the right number?". Geoff Geoff Graham - http://geoffg.net |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
|
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Thanks Phil. The GUI interface does seem to be independent of the main loop. Geoff has apparently found a way to make this little chip think it can handle multi-threaded code! You are right when you say that the comm routines between your 4 processors is where the weakness in the code shows most readily. I don't even want to try having 2 cpus talking to each other. But, the interactions within the GUI routines are not clear to me so I have to get them straight in my mind. I suspect that Geoff is the only one who has all the answers. Paul |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Geoff, thanks, I think I'm a little less confused for the time being. Are the following statements correct: 1. CTRLVAL(n), might look like an array, but it is not an array, and does not get dimensioned. It is a reserved word which is used to set an initial NUMBERBOX value, CTRLVAL(n)=var(n), and to read a changed NUMBERBOX value, var(n)=CTRLVAL(n). 2. Before the first pass of the main loop for each NUMBERBOX set CTRLVAL(n)=realvar(n), changedflag(n)=0, updateflag(n)=0. 3. The first touch on a NUMBERBOX calls TouchDown which sets updateflag(n)=1. 4. The enter touch on the keypad calls TouchUp which sets changeflag(n)=1. 5. On the next main loop pass for each NUMBERBOX if updateflag(n)=1 and changeflag(n)=1 then set realvar(n)=CTRLVAL(n), changedflag(n)=0, updateflag(n)=0. 6. GUI DEFAULT HIDDEN will hide newly declared controls. 7. GUI SHOW n,n,n,n will display and activate individual controls. 8. GUI HIDE n,n,n,n will hide and deactivate individual controls. I guess I threw you a curve with var1=somethingelse in the main loop and confused the issue. There will be many paged display formats. There will be 219 user set variables which appear on GUI only pages but these user settings will not be changed by the main loop. There will be 136 observed or calculated variables which appear on non-GUI display pages which can be changed in the main loop. I, of course, have some more questions: 1. After you touch a NUMBERBOX can you escape out of the KEYPAD without changing the value? 2. Are there internal flags set depending on whether you use ESCAPE or ENTER to leave a NUMBERBOX KEYPAD or do you have to test the CTRLVAL(n) to see if it has changed? 3. How many different GUI NUMBERBOX controls can be defined simultaneously? 4. How many NUMBERBOX controls do you think I can display simultaneously on a single large display page? 5. Are the answers the same for SPINBOX controls? Paul |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Yes, that is a correct. In MMBasic there are a number of constructs like this - another good example is the PIN(n) = command. I don't follow you here, are these points a statement or a question? The GUI DEFAULT command was removed from the latest version (V5.2) as its functionality is now provided by the GUI SETUP command. You can download the current manuals from: http://geoffg.net/Micromite.html Yes, this is (I thought) clearly explained in the manuals. Yes, in 5.2 there is a "Can" button on the alternate keypad screen. No, there are no flags. Escaping out of a KEYPAD is just the same as never having activated it in the first place. Limited only by the number of controls that can be defined (currently 100). This is only limited by the size of each control and how many pixels you have on your display panel. There is nothing in MMBasic that would limit you. Paul, I am happy to answer questions but most of yours are covered in the documentation or could be discovered with a few simple tests. I don't want to discourage you here but you do need to test and experiment for yourself. Geoff Geoff Graham - http://geoffg.net |
||||
| HankR Senior Member  Joined: 02/01/2015 Location: United StatesPosts: 209 |
Geoff, Following this discussion, I read your docs and found them fairly clear as to how the GUI controls are implemented. There probably could be an additional paragraph or sidebar to spell out the independence from the main code for those not familiar with the mechanics of control response. I would say a little more in the manual regarding the specifics of the application of touchup and touchdown would be most helpful in view of the above explanation for Paul of the use of those two triggers. Hope this is not a dumb question, but I was referred by the manual to your pump GUI demo which I saw maybe a year ago, and wanted to see again. The link to youtube came up dead, and my search for it somewhere else on youtube came up empty, too. Is that gone for the time being? If so, I hope you can bring it back, or something similar. Hank |
||||
| HankR Senior Member Joined: 02/01/2015 Location: United StatesPosts: 209 |
Paul, You've been talking about your control project for quite a few months, and occasionally posting bits of hypothetical code and asking some fairly good questions, but I'm not sure if you yet have acquired an MM or fired it up even this late in the game. Please get one if you haven't already and do some of your own testing as Geoff has suggested. After all, you know better than anyone what you want the system to accomplish. Just use print statements to get a view to what's going on. A lot of it then becomes fairly simple if not trivial to determine what the MM is doing. Regarding you knowing what you want to achieve and the posting of code, your code was a little hard to figure out and we out here have two problems, answering your questions about MM use and behavior, and figuring out what the heck your code is INTENDED to do. That is not easy when the code as presented to us is based on mistaken notions of how GUI controls work and how they are used in the language. So I would ask that in future postings of code you paint a picture for this forum in simple words of what specifically you're trying to do. Not specifically that's it's a heat pump application, but, for an example in this case, how a control is supposed to function by your design. Is it to just input a value to the program, or to both input to the program AND display output. Hank |
||||
| HankR Senior Member Joined: 02/01/2015 Location: United StatesPosts: 209 |
Ah, I think it's bordering on outlandish, even for an experimental or research platform. I think if this ever is to get beyond the pipe dream or vaporware stage, you're going to have to get real. If I recall correctly you had something running with relays and thermostats, and maybe still do. Surely you can pare down what you're thinking about now to something that's doable in the next century and a cut above the R & T system. Here in our neck of the woods Paul it's almost heating season. What are you doing? Have you strung any of the electronic temp. sensors yet? You must not have had hundreds of mechanical settings before, so why not shoot for implementing something that is remotely practical in a sensible period of time with your programming experience and ability. At this rate I'm really not sure you're going to be ready for October 2017. Hank |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3282 |
Good point, thanks. I will look at it. I replaced the video with a more up to date version but forgot to update that link, thanks for the warning. The proper link is: https://youtu.be/j12LidkzG2A Geoff Geoff Graham - http://geoffg.net |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
I'm sorry Geoff, I did not explain that these items are supposed to be my understanding of the sequential steps I would use to flag whether a parent var was changed in the keypad and needs to be updated. I can work this out for myself. That link seems to be broken and the most recent manual I have is for v5.1. I guess that the absence of flags means that I would have to compare CTRLVAL(n) after the keypad exits with the original loop variable to see if it has changed in order to determine if updating the loop variable is required. That means that I will have to limit the maximum number of user settings which can be made! Geoff, thank you very much for answering my questions. I appreciate that you are very busy and I don't want to waste your time. I have not yet acquired the needed hardware to test anything because I have been trying to decide which hardware I need. I am considering the E64 or E100 from Rictech. I still have not concluded if I can expect only one of these to handle both the computational loop and the user input and display. Your explanation above of the ability of MMBasic to continue the main loop processing while the keypad is waiting for user input indicates that one cpu might do the job, but the limitation of 100 maximum defined GUI controls which you also mentioned above might reverse that conclusion. Using two E100 cpu boards, (or an E100 plus an E64), would require carefully controlled communication routines with handshaking between the two. I could alternately elect to use a PC to write user settings to a file structure on a removable card and read the file at run time which would remove the user input requirements completely from MMBasic, but I would hate to make the system dependent on an external PC. I am also worried about my ability to physically assemble the cpu boards and a display board to a mother board because of my lack of physical dexterity and bad eyesight, however I think I will be able to decide which implementation to try with the information you have generously provided. I took a look at your new video showing the E100 board and it is a very nicely made video. 55 years ago I was in the audio and video production business. Could you please provide a link pointing to the most recent v5.2 documentation? I hope that the next time you hear from me I will be sending you a video of this thing working! Paul |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4036 |
I think the link should use a lower case m http://geoffg.net/micromite.html#Downloads John |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Hi Hank, I'm very pleased to meet you. This geothermal system has been running here in my house since October of 2011 under the control of 5 Dwyer TSS2 programable thermistor bridge temperature switches which control high power relays. The thermistors used exhibit long term drift and require re-calibration every few months so I have been searching for a practical way of using band gap sensors like the DS18B20 since 2013. I did not want to re-invent the wheel by writing a complete system in C for the PIC line of processors so I wasted about 6 months trying to use a combination of PICAX chips communicating with an OpenWrt router running LUA and html pages communicating with a browser for a user interface. That became way too much of a mess. Then, in January of this year I discovered Geoff's excellent work with MMBasic so I initially decided to use a MaxiMite to do the job. Then in April I saw Geoff's video of version 5.1 running the pump control with a touch screen on an E64 board and I decided to use two E64 boards to do the job. I know that it seems to you that I am progressing at a glacial pace, but my problem is not stringing wires and placing sensors, indeed most of the sensor wiring is already in place, put there by an electrician friend. My problem is that Geoff Graham, Graeme Rixon and others here at the Back Shed are too darned smart! They keep making better stuff! Since April the E64 and E100 boards have become available and the GUI controls have expanded in 5.2. Every time I lay out a design they produce something better and I have to scrap what I have done and use the newer and better ideas. Geoff has just explained the granularity of the GUI interrupts to me and told me about the 100 control limitation of the GUI interface. I now might be able to get this thing done. In the meantime the geothermal system is working controlled by the Dwyers. In the last five years it has saved me about $85,000 worth of heating oil and actually reduced the total electric bill slightly because the summer cooling is much more efficient. In addition Uncle Sam decided to give me a one time income tax reduction of about $30,000 for digging up the yard and installing the thing in the first place, so I'm not complaining. My limitation in getting this thing done relates to my age and physical condition. I'm working on completing my eight decade above the daisies and I'm not in terribly good health. I know that when I start trying to physically assemble this thing I will have difficulty so I don't want to experiment with PCBs, breadboards and wires any more than is necessary, but I would definitely like to have it working before October of 2017! Where on this big continent are you located? PM me if you have any constructive ideas you would like to share with me and we can switch to email or the old fashioned phone. Paul |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Thanks John, that worked! Paul |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
Hi Paul, At this stage I'd suggest getting an E100 along with Grog's Expansion Board . If you could get the temp sensors in & going you could get the system running in a purely monitoring state to check on it's outputs before putting it into real world control. All the outputs could be GUI indicators & you could also log it's operation to an SD card to review that it's correctly performing all the required tasks. Phil. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
