Eugen Graf Posted September 7, 2007 Report Share Posted September 7, 2007 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 Quote Link to comment
ragglefrock Posted September 7, 2007 Report Share Posted September 7, 2007 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? Quote Link to comment
Eugen Graf Posted September 7, 2007 Author Report Share Posted September 7, 2007 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 Quote Link to comment
Cmal Posted September 7, 2007 Report Share Posted September 7, 2007 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 Quote Link to comment
Dirk J. Posted September 7, 2007 Report Share Posted September 7, 2007 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.... Quote Link to comment
Eugen Graf Posted September 7, 2007 Author Report Share Posted September 7, 2007 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 Quote Link to comment
orko Posted September 7, 2007 Report Share Posted September 7, 2007 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. Quote Link to comment
Eugen Graf Posted September 7, 2007 Author Report Share Posted September 7, 2007 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 Quote Link to comment
orko Posted September 7, 2007 Report Share Posted September 7, 2007 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.