Menu options and ideas
TC
Posts: 1,019
Hello all,
Still working on the reflow oven.
I am figuring out the menu for this oven, but I am having trouble deciding if what I have is OK, or is there something I missed. I feel like I am missing something. So I begging for your honest opinions and ideas.
Here is what I came up with for a menu. Nothing is set in stone, so please don't be afraid to say "That is a dumb idea"
Thanks
TC
Still working on the reflow oven.
I am figuring out the menu for this oven, but I am having trouble deciding if what I have is OK, or is there something I missed. I feel like I am missing something. So I begging for your honest opinions and ideas.
Here is what I came up with for a menu. Nothing is set in stone, so please don't be afraid to say "That is a dumb idea"
Thanks
TC
1024 x 342 - 66K
Comments
I like that idea, should not be a problem.
It is for a DIY reflow oven.
To set the values of the PID, each digit of the value can be selected and adjusted. With a max value being 99.999. I only had the clear option to make it easier to start over or to turn off a value. Do you think it would be a waist of time?
"Zero" or "Disable"? IMO, "Clear" is okay.
I like the flow chart. I need to do that more often.
I like the "Disable" name. I could set something up that if the value is zero, then display "Disabled" instead of the value.
This is the first time doing a flow chart. I had to do something, I was doing this menu blind and out of my head. It is allowing me to be able to check off what I have done.
I am sorry, but I am not quite understanding what you are explaining. Could you offer a simple example?
Each menu item/function is enumerated and we have a stack to PUSH and POP the menu state.
I'm still not fully understanding, I think I am going to jump in to it head first. And see if I float or drown.
Another code organization feature may be for each main menu item to have it's own .spin file.
Many things can be done in code to make things easier in the long-run that may seem unnecessarily difficult to some in the short-run.
Depending on how many items are in your list, you could do away with the list "menu" by using some code like this:
PUB FindStringOrderPtr(firstStr, stringIndex) '' Finds start address of one string in a list '' of string. "firstStr" is the address of '' string #0 in the list. "stringIndex" '' indicates which of the strings in the list '' the method is to find. result := firstStr repeat while stringIndex repeat while byte[result++] stringIndex--To display item3 you'd use:
I only use the above method on relative short lists that don't need to be accessed quickly.
The above method is also limited to data structures not containing a zero (such as strings).
I do like that idea. Right now, I have each part of the menu in its own method.
Yep, that's me. But I trust people on here, most of you have a lot more experience than me.
I am sooooo sorry, but I cant see why this is better.
Would this not be the same?
DAT RunProfile BYTE "Run Profile", 0 LoadProfile BYTE "Load Profile", 0 DeleteProfile BYTE "Delete Profile", 0 PUB menu LoadString(RunProfile) LoadString(LoadProfile) PUB LoadString(StrPntr) Display.str(@StrPntr)I could be wrong on the "@" placement, but I think you get the idea.
For one reason the address listed in the array "menu" need to be corrected because the compiler offset the RAM by 16 bytes in the top object.
It's not necessarily better than the way Mike G illustrated (I use a similar technique with my robot remote code) but being able to access the strings with a index number is very useful when making menus.
DAT RunProfile BYTE "Run Profile", 0 LoadProfile BYTE "Load Profile", 0 DeleteProfile BYTE "Delete Profile", 0 PUB menu LoadString(@RunProfile) LoadString(@LoadProfile) PUB LoadString(StrPntr) Display.str(StrPntr)Yes, I get the idea (and I fixed your "@" placements).
No, it's not the same.
In your code the method "menu" only displays those strings each time.
However if you used Mike G's suggestion, your "menu" method would be more like this:
DAT RunProfile BYTE "Run Profile", 0 LoadProfile BYTE "Load Profile", 0 DeleteProfile BYTE "Delete Profile", 0 menuList WORD @ RunProfile, @LoadProfile, @DeleteProfile PUB menu repeat LoadString(menuList[activeMenu]) ' do stuff while in this particular menu ' wait for active menu to change PUB LoadString(StrPntr) Display.str(StrPntr + addressCorrection)The above code isn't anything close to the code you would really want to use but I was just trying to illustrate how having the active menu identifiable by some number can make constructing a menu easier to maintain in the long run.
Or as jazzed said:
Sorry, as I read back over this post, I feel like I've failed to express myself well. Hopefully another forum member can explain this concept better.
YAY
For my display, that is ok. The display will show the last thing it received, until it is changed.
It might not be close, but it helped. Now I understand it. Tell me if I am wrong. Lets say I want to add "EditProfile" between "RunProfile" And "LoadProfile", I would just have to do
DAT EditProfile BYTE "Edit Profile", 0 RunProfile BYTE "Run Profile", 0 LoadProfile BYTE "Load Profile", 0 DeleteProfile BYTE "Delete Profile", 0 menuList WORD @ RunProfile, @EditProfile, @LoadProfile, @DeleteProfile PUB menu repeat LoadString(menuList[activeMenu]) ' do stuff while in this particular menu ' wait for active menu to change PUB LoadString(StrPntr) Display.str(StrPntr + addressCorrection)No you haven't, it is me that was having the problems. For things to click in my head, I have to see a benefit on doing it.
First you need to decide on the main and sub menus. Since you are using a small display you may have to step through the menu levels and choices, so keep each level to four or fewer choices if possible. What you have is a good start but I would change Edit Profile to Add/Edit Profile. Once a main menu item is selected it presents a sub menu similar to the suggestions below.
- Add/Edit Profile > New Profile, Profile 1, Profile 2, Profile 3, ...Profile n
Selecting New Profile would create a default profile and ask for a profile name before proceeding to the edit profile functions.
Selecting one of the existing profiles would allow editing of the selected profile.
- Run Profile > Profile 1, Profile 2, Profile 3, ...Profile n
Starts executing the selected profile. May want to display Press x to start run before starting the profile.
- Load Profile > Profile 1, Profile 2, Profile 3, ...Profile n
Loads the profile into ram? What then?
- Delete Profile > Profile 1, Profile 2, Profile 3, ...Profile n
Deletes or marks the profile as deleted. Should have ARE YOU SURE YOU WANT TO DELETE Profile x Y/N
Having Run and Load seems to be a bit redundant. Would you want to change some parameters for a single run without saving the changes?
I like that idea. I dont see me editing profiles that much, but if I do I would just Add a new profile.
I was thinking the same thing. That way it would confirm I wanted to add a new profile.
Instead of "Press x to start" I am going to use a stand alone button that has a duel color LED in it. The button would be for starting and stopping the oven. Green would be start, and red would be stop. The button is a SPDT type. I am using both the NO and the NC of the button. The NO is for starting the oven (makes sure the button is pressed), and the NC is for stopping the oven(Faster response)
I have not figured out all the details yet, mostly because I have never done anything like this yet, and I have to take things step by step to figure them out.
But what my plan is, When a profile is selected to be loaded and ran, A pointer to that profile would be saved in the upper side of the eeprom(so I don't have to keep selecting the same profile every time I turn on the oven), the first zone data would be loaded to RAM and ran. Once the first zone is done, the next zone is loaded and ran. That will continue until there are no more zones in the current profile. I figure by doing it that way, I would not have to worry about how many zones there are in the selected profile. And since all the zone data are the same, I would only have to have the same amount of RAM for each zone.
I agree with you there. But I was going to use the stand alone button for "YES" and the encoder select for "NO", just to make sure I do not select "YES" by mistake.
The "Run" is to run the current/last profile, and the "Load" is to change the current profile to a different profile.
I dont really know, I never put any thought into that. I was just assuming that if I wanted to change something I would just edit and save the profile. Then if I use the changes, I would just create a new profile that has the changes.
I am still learning, and figuring things out. A couple things have changed because members have given me better ideas.
First, get your menu system working then worry about the control logic.
I think I do.
Profile = what the oven uses for temperature and time settings
menu = what the user uses to select, edit, and change parameters of the oven
That is what I wanted to do. The SD card has more space available, and that leaves me more room on the upper 32k for menu data.
Agreed, I figured the menu would take the most time, and effort to do.
Since the only difference between adding a new profile and editing an existing one is providing a name for the new one it makes perfect sense to combine them, and it saves a bit of menu and memory space.
Having separate buttons for those functions is a great time saver.
Both excellent ways to go at this. Divide it into small steps then solve them one at a time. Since many of the pieces will be similar you can use what you learn from one step to solve next one.
Another safety measure would be to mark the profile as deleted by changing the first character of the name to an asterisk (like msdos did) and leave the rest intact until the space was needed. That makes it possible to to recover an accidentally deleted profile.
Ah, that makes sense.
Being able to change values for a single run without actually changing the profile might be handy for troubleshooting or optimization. In heat treating metal parts being able to change the soak time was very useful. It may or may not be of any use for this application.
Select “New” and you would always proceed to the edit function. After editing you would be presented with the “Save”, “Run” or “Cancel” functions. If you choose to run the function you would be presented with the “Save”, “Run” or “Cancel” functions again.
Select an existing protocol and you would automatically load that protocol and be presented with the “Edit”, “Run” or “Delete” functions.
This would be the ultimate in brevity and memory savings. The program would page through the “New” and existing protocols in the SD card to create the menu so no hub space would be needed to store the protocol names. The only hub memory required other than the program would be for four protocol names and the selected Protocol parameters.
Agreed, but I do want to keep it simple and try to keep it clean. That is why I changed the incandescent light bulb that was in the switch, to a dual color LED. I was able to turn 1 button into 2 buttons by adding the LED.
Last time I used MS DOS, I was a kid. And even then I never paid to much attention to what happened when files were deleted. I will go that route later on.
I guess you are right. What I could do is, add a section to the "RUN" screen that allows me to change values on the fly.
Hahaha.... Welcome to my world, I do that all the time. Mostly when I just lay down for bed.
I want to keep the "RUN" function simple (K.I.S.S). My goal is, when the oven is powered up, the "Run Profile" (with the last profiles name) function is loaded and on the screen. The Green LED button would be flashing to indicate to "push me to start". I push the button, and the oven starts. No menus to go through, nothing to change, just start. But if I wanted to change, edit, delete, or anything, I would turn the encoder knob at the "Run Profile" screen.
I would be adding a flashing arrow indicator on the right side of the "Run Profile"( RunProfile "->" ) to show that there are more options. And with the Noritake 24x6 display, having individual characters flash just takes sending 2 bytes ($1B, $42) before I send the string data, then send 2 more bytes ($1B, $41) to turn off the flash for the rest of the screen.
That is exactly my plan. I could not see using up hub memory to load every part of the selected profile, when I could only use one zone worth of data at a time.
For the SD naming I was thinking of just doing the first 8 characters of the profile name, with a .PRO extension. That way, I could also use the computer to edit, add, delete profiles. Again K.I.S.S.
IE
General Profile = GENERAL_.PRO
Lead Free = LEAD_FRE.PRO
Leaded = LEADED__.PRO
I really hope so. Thanks