LabVIEW
Buttons stop response at one state
Solved!
@yumeng0426 wrote:
I see your points. The reason that happens is not because the logic is wrong. It is due to that the program does not get any input in working state. Since the person needs to change slider position manually, and any control is sort of frozen while operating in work state (this is not suppose to happen), the person cannot move the slider to the next correct position. In the end, the program will be stuck in the work mode and never enter idle. In the idle state, event structure is created with start or slider value change to exit. It was a separate state before. Since it has the same issue and I thought it may be the reason, I made the change to merge two states. Nothing changes on the behavior so far.
What bothers me is that it won't record any value once work mode is executed and I cannot figure out why. I am willing to spend time on debugging and learning, but it is endless now to actually know what is going on there. The flow is working; as long as work mode is not involved, it is working. So it has to be with work mode. But unfortunately, I cannot figure out what is the reason for the past a week and a half. It is weird for me because even if I only have work state, it should at least let me click on the button, just like any while loop. Position slider, start and stop are all available in the main loop. My understanding is that these controls would be able to record value change at the time I click on it. On the other hand, if I only include controls in certain state, then the value would not be recorded until that state is executed.
Well, the obvious thing is... if the logic is right, then why isn't it working? The most frustrating thing about programming is that the computer does exactly what you tell it to do. The more experience you get, the more this aligns with what you want it to do. Now, I've given you the tools, laid out the groundwork. You have to make this jump. It's critical to your understanding of LabVIEW. Listen carefully: The event structure follows the rules of data flow and fires only when it is called.
Now it occurs to me what you are missing. As long as the timer isn't going, the state machine has a chance to return to idle and service events with the event structure. Click a button, no timer, so it can go idle and service the next event. Once you move the slider, the timer gets going, it doesn't go to the idle state so the front panel locks up. It never returned to idle for me because the first thing I always tried was moving the slider. I haven't yet checked if it goes back to idle when the timer expires, though.
So what's your takeaway on this? Hint: "Idle" means "I'm not doing anything". I'm sure you want to be taking care of the UI even when the program is doing stuff. This is why there are standard design patterns. Use a standard design pattern, most of the thinking is done for you and you can spend your time thinking about what you want to do and not how to do it.
You have to check your ego at the door if you are going to be a successful developer. If it's not working it's your fault. With rare exceptions, it is doing exactly what you tell it to do, and if it's not aligning with what you want it to do, your logic is incorrect.
If you surrender control of your UI to the event structure, as normally happens in an application with user interaction, the event structure needs to be available any time the user needs to interact with the application - which is usually all the time. LabVIEW places all events that you tell the event structure to handle into a queue to be serviced, one at a time, by the event structure. If the event structure never gets to run, the events never get serviced. All the controls that have events defined in the event structure become unresponsive as their events pile up in the queue, waiting to be serviced. So your logic needs to include "I have to ensure that the event structure is always available to handle UI events". Since the idle state doesn't seem to be happening often enough to let the event structure handle events in a timely fashion, you have to move the event structure elsewhere. Here's a basic tutorial on using an event structure.
The easiest way to ensure events are handled in a timely fashion is by using the QMH design pattern. This even moves the event structure out of the loop and into its own loop for instant event handling gratification.
@yumeng0426 wrote:
Ok. I think I figured out. It seems that due to the event structure in idle case of "slider value change". So is that true that if one control is used for event structure, then it may lead to no response if that state is not executed? Thank you.
For some reason or other, I never saw this post. YOU ARE ON THE RIGHT TRACK!!! Since all the buttons you want to use are defined in there, all those buttons become locked. Frankly, it's been so long since I've thought about this, I can't remember if it's just those controls, or the entire UI that gets locked up. BUT YOU ARE GETTING IT!!!
My previous post makes for good reading, but you seemed to have gotten the very point it was trying to make before I posted it. Thumbs up!
