LabVIEW
Buttons stop response at one state
Solved!
Why is the "car position slider" a control, it seem to be used mostly as indicator controlled by the state. Make it an indicator (possibly keep it in a shift register to eliminate all the locals) and remove the associated event.
Your events are also configured to lock the front panel until the event completes, so if you have wrong code logic somewhere and the event structure cannot be reached in a reasonable time, the computer will lockup forever.
(I haven't looked at your code logic, but the above should give you some pointers.)
@altenbach wrote:
Why is the "car position slider" a control, it seem to be used mostly as indicator controlled by the state. Make it an indicator (possibly keep it in a shift register to eliminate all the locals) and remove the associated event.
Your events are also configured to lock the front panel until the event completes, so if you have wrong code logic somewhere and the event structure cannot be reached in a reasonable time, the computer will lockup forever.
(I haven't looked at your code logic, but the above should give you some pointers.)
If I recall correctly, the slider controls the car as well as indicates where the car is. You should be able to manually move it away from the "correct" position. I believe test gives you the main VI with the front panel already configured.
Unfortunately I can't open this version of LabVIEW, so I can only make general comments.
- You shouldn't need anything fancy like unlocking the front panel in this exercise. it's all pretty straightforward.
- If your "timer" is simply a wait, expect nothing to happen until it finishes. You have to loop through the code, checking elapsed time every time through the loop in order for this to work.
Okay, a teachable moment. Turn on highlight execution - the lightbulb. (You may want to increase the allowable time for each station a bunch, so the elapsed time doesn't time out before the program has a chance to go through a couple of loops in lightbulb mode.) If you cannot guess what is wrong, at least tell me what you are observing.
BTW - it's a-OK to use the elapsed time express VI. Anything in LabVIEW that can make your life easier is in fair play. And the elapsed time express VI is one express VI that is actually worth using. 🙂
Thank you for describing this to me. Do you ever see the state with the event structure pop up? The event structure doesn't just magically work; it follows the same data flow rules as everything else. In order for it to service an event, it needs to be fired. Since it never reaches that state ever again, no events are serviced. The front panel becomes unresponsive.
Two things to take away here. You have flawed logic. It never goes back to the idle state; therefore, none of the events are ever serviced. But even more basic is that you need to have the event structure available when you need it. It needs access every time the loop iterates. It can't hide inside a state.
Although it's probably a little overkill for this situation, the QMH design pattern guarantees access to the event structure all the time. I did use the QMH for my CLD test, though, because that's what I was comfortable with, but I've seen solutions that didn't even use an event structure.
Your VI enters the idle state exactly one time (at least for me), at the beginning, so you can interact with the front panel exactly once. After that, it never sees the idle state again, so whichever events the event structure is handling - which is most likely every single button and slider - will never fire. In any case, the idle state doesn't fire often enough for the event structure to service an event in a timely fashion, leaving the front panel locked.
The reason why I'm not giving you outright answers isn't so much that I don't want to do the work for you; because you are looking to take your LabVIEW learning to a higher level, I want you to be able to figure out these things with just a little nudge, at the most.
