Need help using queued state machine

[Eugen Graf]

Hello,

I use a queued state machine in my program. The bottom loop is my parser and works in own VI. If I click connect my parser should start to read interface and triggers himself for the next read. But if I want to stop them, they will not stop. I see why, but have no right solution.

http://forums.lavag.org/index.php?act=attach&type=post&id=6857

My bad solution is to flush the queue in state idle, but it works wrong, if I click any other button while waiting on reading (5 sek). In realy reading doesn't need 5 seconds, it only to show you my problem.

http://forums.lavag.org/index.php?act=attach&type=post&id=6858

Thank you, Eugen

[ragglefrock]

QUOTE(Eugen Graf @ Sep 6 2007, 07:43 AM)

Hello,

I use a queued state machine in my program. The bottom loop is my parser and works in own VI. If I click connect my parser should start to read interface and triggers himself for the next read. But if I want to stop them, they will not stop. I see why, but have no right solution.

http://forums.lavag.org/index.php?act=attach&type=post&id=6857

My bad solution is to flush the queue in state idle, but it works wrong, if I click any other button while waiting on reading (5 sek). In realy reading doesn't need 5 seconds, it only to show you my problem.

http://forums.lavag.org/index.php?act=attach&type=post&id=6858

Thank you, Eugen

I'm confused as to why the Read case needs to queue itself up. Reading the Queue happens every iteration anyway, so it doesn't serve any purpose to have a specific Read case to tell it to do so. Can you explain what you're trying to accomplish? Do you only want to process messages after hitting Connect?

[Eugen Graf]

QUOTE(ragglefrock @ Sep 6 2007, 04:48 PM)

I'm confused as to why the Read case needs to queue itself up. Reading the Queue happens every iteration anyway, so it doesn't serve any purpose to have a specific Read case to tell it to do so. Can you explain what you're trying to accomplish? Do you only want to process messages after hitting Connect?

I want only to start the COM-interface reading in the bottom loop from the upper loop. After it is started, it should do reading up to the upper loop commands idle.

Why not? What can be wrong here?

Thanks, Eugen

[Cmal]

QUOTE(Eugen Graf @ Sep 6 2007, 10:32 AM)

I want only to start the COM-interface reading in the bottom loop from the upper loop. After it is started, it should do reading up to the upper loop commands idle.

Why not? What can be wrong here?

Thanks, Eugen

The "Message" event case is sending a True constant to stop the upper loop. Is there any reason you're stopping the upper loop on the Message event?

Chris

[Dirk J.]

Eugen,

You have a TRUE constant wired to the 'stop' terminal in the "message case" of the top loop.

After you click 'message', your top loop w/ the Event structure stops working.

If you remove the boolean, it works fine.

-edit- argh... just too late....

[Eugen Graf]

QUOTE(Cmal @ Sep 6 2007, 05:52 PM)

The "Message" event case is sending a True constant to stop the upper loop. Is there any reason you're stopping the upper loop on the Message event?

Chris

Oops, sorry that was wrong because of duplicating of stop event case. Case "message" should not stop the upper loop, this event case is onle here to show that any other events can occure.

Eugen

[orko]

Okay, here's one way you may be able to get the answers you're looking for:

0) Take care of that bug in the "Message" event case :-)

1) Right click on the Queue RefNum input terminal inside the bottom while loop right before the Dequeue Element and put a probe there.

2) Run the VI and watch the probe. Notice how each time you click on Connect/Disconnect, there is another "read" that goes into the queue (effectively adding 5 seconds in this case before the next read is queued)

3) Click the Connect/Disconnect button a few times, then click on Stop. Notice where the "exit" is in the queue stack? I assume that it needs to be in the front of any other queue elements.

4) Right click the Enqueue Element in the Connect/Disconnect event case in the top loop and replace it with a "Enqueue element at opposite end.vi" in the queue operations pallete. This one puts the element at the front of the queue, and I use it for stop or error conditions that I need handled right away (on the very next iteration of the queued state machine).

To handle the reads stacking up the way they are with each Connect/Disconnect button press, you can do several things. One suggestion is to preview the queue elements (with "Preview Queue Element.vi") and if there is already a "read" in there not adding another.

You can also create a subVI that previews the next queue element and if it is NOT a Stop or a read, then it queues up the next read. I think this may be a little more elegant solution.

Hope this helps out.

[Eugen Graf]

QUOTE(orko @ Sep 6 2007, 06:17 PM)

Okay, here's one way you may be able to get the answers you're looking for:

0) Take care of that bug in the "Message" event case :-)

1) Right click on the Queue RefNum input terminal inside the bottom while loop right before the Dequeue Element and put a probe there.

2) Run the VI and watch the probe. Notice how each time you click on Connect/Disconnect, there is another "read" that goes into the queue (effectively adding 5 seconds in this case before the next read is queued)

3) Click the Connect/Disconnect button a few times, then click on Stop. Notice where the "exit" is in the queue stack? I assume that it needs to be in the front of any other queue elements.

4) Right click the Enqueue Element in the Connect/Disconnect Stop event case in the top loop and replace it with a "Enqueue element at opposite end.vi" in the queue operations pallete. This one puts the element at the front of the queue, and I use it for stop or error conditions that I need handled right away (on the very next iteration of the queued state machine).

To handle the reads stacking up the way they are with each Connect/Disconnect button press, you can do several things. One suggestion is to preview the queue elements (with "Preview Queue Element.vi") and if there is already a "read" in there not adding another.

You can also create a subVI that previews the next queue element and if it is NOT a Stop or a read, then it queues up the next read. I think this may be a little more elegant solution.

Hope this helps out.

Thank you for.

After some consideration I think I found a solution. What are you thinking about?

EDIT: Not realy complete solution, but I think a right approach.

Eugen

[orko]

QUOTE(Eugen Graf @ Sep 6 2007, 10:33 AM)

After some consideration I think I found a solution. What are you thinking about?

Now your read state doesn't do anything but wait... I think you forgot to put the enqueue in the false case

Using the number of elements in the queue will probably cause problems in the future. I would stick to previewing the element that is next in the queue to decide whether or not to queue up the next read. Something like this for example:

http://forums.lavag.org/index.php?act=attach&type=post&id=6872

Here's the SubVI:

http://forums.lavag.org/index.php?act=attach&type=post&id=6873