10-02-2017 02:10 PM
I have a queued state machine.
In step1 and step 2 a sub Vi, which takes 1000 ms, decides which step to goto next.
That’s okay.
My problem arises, when I try to invoke the process by the stop button.
Because the program is inside subvi 1 or subvi 2, and have not yet reached the enqueuer element the queue suddenly contains 2. elements and the process goes from step1 (or step2) - end - step 1 – end ….
Which way would be the best way to fix the problem?
Solved! Go to Solution.
10-02-2017 02:12 PM
another snip
10-02-2017 02:51 PM
Without getting into the subVIs, the first change you'll need to make is moving the While Loop conditional boolean values to be set to something other than False. Best approach is to move this value inside the Event handler in the top loop and inside the Case Structure in the bottom loop.
As it stands now neither loop will ever exit.
10-02-2017 04:33 PM - edited 10-02-2017 04:55 PM
Only 5 edits are needed:
Since you named the queue you may also wish to "Force Destroy" the queue when you release it in case someone else opened a reference to "state" queue so that code errors out appropriatelty. (or don't name a queue that is only used locally)
Also, you will want to type def that state enum to make your life a lot easier in the future
10-02-2017 04:51 PM
It seems like you are just experimenting around right now, but when you do make a real application, make sure to look at the Queued Message Handler template that ships with LabVIEW. You will find some features that you may want to incorporate into your project:
10-03-2017 12:59 AM
I know. This was just a very quick example to visualize my problem
I try to look at the template
10-03-2017 01:06 AM
Hmm
I didn't find anything the solve my poblem with mixing of to states in the queued state mashine
10-03-2017 06:34 AM
What you have is a Queued Message Handler (QMH). It should only receive commands from the outside world. It should not enqueue onto itself due to these race conditions that you are running into. If you want an actual Queued State Machine (QSM), then you need a queue for maintaining your states and another queue for receiving messages. Part of your sequence of states should be a state for checking for messages. Alternatively, you could use the timeout capability of your dequeue. You just store in a shift register which state you go into if no message was received.
And the loop that is reading from the queue should be the one to close it. As it stands, you will almost guaranteed to get an error code1 after the producer loop stops and the consumer tries to read the stop command since the producer destroyed the queue. And with that error, you will get the default value for element, which will be whatever is in spot 0 (I am guessing that is Step 1).
10-03-2017 08:26 AM
Thank you guys. I can see that I have a lot to learn.
I will indeed try to do so. I would like to return tomorrow with a corrected example – then you are free to make fun of me if it’s totally wrong J
10-03-2017 11:03 PM
While I may use humor to point out flawed code, I try to never make fun of a poster wishing to learn. (Besides, you should see some code I wrote years ago)