Jump to content

Need help using queued state machine


Recommended Posts

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

Link to comment

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

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?

Link to comment

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

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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 :oops: 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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.