I have a problem when I want to implement an event in my state machine.
The state machine is reading serial communication through 10+ different states.
The problem came when I tried to add an event inside state number 10. In state number 9 the code seems to run only partially (one radio button is not possible to change value on).
It looks almost that it is frozen but when I highlight the code I can see it is running though (radio button is not).
It is strange that when I remove the event in state 10 everything is fine again? The event code is not even run yet because it is in the frame after!
I am running LabView 2013 on a Windows 7 PC.
Solved! Go to Solution.
Please attach your VI. It sounds like you have more than one event structure, which will really mess things up, but it's hard to tell just from your description.
Event structures should never be hidden from dataflow. They will queue up events even if they can never execute them. If the event is set to lock the front panel, there is no escape.
Please attach your code.
Since this is a big program I am only sending two of the cases in my state machine. This example will show states 9 and 10 refered to in my previous post.
The Event Structure needs to bee in a parallel loop not hidden inside a case structure. None of the Sequence Structures are necessary and the just hide your code, get rid of them. If you wer to follow data-flow programming practices, which is the way things should be done in LabVIEW, none of the local variables are necessary. Use the Time Delay express vi for your waits as it has error terminals. Whay do you need the timed loop?
Look up Producer/Consumer design pattern. You also might want to look at the LabVIEW tutorial.
I put the event structure outside of the timed loop structure but it seems that the event is not running?
Why is it that just frame 9 is froozen and not the previous frames?
You asked about the timed loop, it was a leftover from a previous project so I guess I can get rid of that.
Regarding the sequence structure I found it good when you want to get back and forth between different states.
"Frame 9" is meaningless as you've gotten rid of some of the cases. Also, sequences have frames. Case structures have cases not frames. Event structures have event cases, not frames. Using that terminology please explain it again so I can understand.
I can say that having a event structure inside a case structure is going to cause nothing but problems. If you press a button or otherwise trigger an event while in the case that does not hold the event structure the event you wanted will not happen. The event structure needs to be outside the case structure, best in a separate loop.
The stop button has a switch action instead of a latch action, which will also cause problems in the event structure. Boolean controls need to be inside their event case.
OK - I meant previous cases not frames. And I refered to frame 9 in previous comments too, not the VI I sent that only hold 2 cases.
I know that the stop button has a switch action, you can't use latch action if you have made the button into a local variable.
It seems that event is not what I would use in this case, the reason for using this was to be able to have a button to write different serial data in a loop ONLY after a button press and not repeatedly in every loop.
I'm trying to figure out which of the two cases is the one that seems to hang so the name would be better than a number.
When using am event structure you don't we want to use a local variable. In fact, you should only use local variables on rare occasions as they break data flow. An event structure is fine for input. The problem is the way you're handling things after the button is pressed. Again, I think you need to look at a Producer/Consumer design pattern with a queued state machine.
The easiest way to have a write happen only after a button press is to have the code for the write in a case that is only active when the button is true and is simply empty when it's false.