Queue driving loop timing?

[philips]

Maybe I've just been at this too long for one day, but I have 2 loops running in parallel and they have a timing dependency which I don't think should be there.

The top one contains serial read / write (not using VISA becaase it's going to run on a PDA eventually)

The lower one contains a simple generator to send periodic commands to the serial port (now just wired to the loop iteration counter).

The generator send data to the serial loop using queues.

Problem - the serial loop should just free run accoring to it's timed wait, as it has done in other VIs I've written, and 5x the speed of the Generator loop.

BUT it doesn't! It only runs after each completion of the generator loop.

What am I missing - probably something very simple!

BTW I'm using LV 7.1

Thanks,

Phil

[LAVA 1.0 Content]

Maybe I've just been at this too long for one day, but I have 2 loops running in parallel and they have a timing dependency which I don't think should be there.

The top one contains serial read / write (not using VISA becaase it's going to run on a PDA eventually)

The lower one contains a simple generator to send periodic commands to the serial port (now just wired to the loop iteration counter).

The generator send data to the serial loop using queues.

Problem - the serial loop should just free run accoring to it's timed wait, as it has done in other VIs I've written, and 5x the speed of the Generator loop.

BUT it doesn't! It only runs after each completion of the generator loop.

What am I missing - probably something very simple!

BTW I'm using LV 7.1

Thanks,

Phil

The dequeue element by default will wait untill it has somthing in its queue before it continues execution. Since you are enqueueing at a rate of 500 ms in your generator loop your serial loop can only dequeu at that rate, thus the dependency. The timeout in ms terminal on the dequeue element vi determines how long it will wait, before continuing execution. For example, if you wire 10ms to that terminal, the dequeue will wait untill somthing is in the queue or 10 ms, which ever comes first. A few other observations; you obtain the send message queue 3 times but you only release it once, so every time you start and stop this application you are leaving two references to the send message queue in memory, this may or may not cause you a problem. There is three solutions for you 1. only obtain the queue once and pass out its reference to the enques and deques and release queue. 2. relese the queue three times then it will be destroyed. 2. there is an optional boolean terminal on the release queue, if you make this true it will destroy the queue. I see no use for the recieve queue in the application, unless there is another VI runinng in parrelle that obtains a reference to the recieve queue. Also, I would consider using a state machine for this, it will make it easier to modify the code moving forward, and has many other benifits. I have never written code for a PDA perhaps you are aware of a reasons to use the sequence that I am not, but as a general rule it is never recommended to use a sequence. Hope this helps :thumbup:

[Yair]

One other thing to keep in mind is that the PDA module seems to have some serious timing issues when it comes to anything under 200 ms. From my experience it seems that you can either have roughly 5 iterations a second or millions (0 or no wait). Anything in the middle usually comes out as 5. As was said, having the timeout terminal in the Dequeue function should help and you can use the timeout output to decide whether you even want to do the serial write. Note that the PDA module has quite a few bugs and it doesn't always work as you would expect it to.

[i2dx]

I'd like to append, that I experienced timing problems with parallel loops in the PDA-Module, too. I did not track it down, and so I can not give any detailed advice, but last but not least, I came to the conclusion, that it's no good idea to use parallel while loops with the PDA Module.

I experienced the problems, when I tried to use a "quite normal queued statemachine" on the pda ....

[philips]

Thanks for the replies all round - changing the tiimeout solved the immediate problem.

My application is actually much more complex than this - it's a messaging system and dialler that runs on a PDA communicating with the outside world via serial port or bluetooth to a modem.

I originally wrote it as a demo using parallel timed loops communicating via queues - one for serial, one for each aspect of the UI system that required different timing, but the delay thru the app was horrible and unpredictable, sometimes up to 30s between when you pushed the button and when it came out the serial port. It was my first serious LV app (this is my second!) so I'm sure there are heaps of mistakes.

I decided to rewrite it using Events for the UI inside a State Machine, with queues to handle the comms between processes, notably the serial port and the UI / message handlers.

However the serial will not run inside the state machine becuase the Event structure for the UI locks the machine until an event happens (I think?), so I put a timed loop outiside to handle the serial comms, and another which needs to generate data for the serial port and deal with data from it in nreal time, independent of the UI - see the attached.

Any useful comments appreciated - I'm demonstrating it tomorrow at a trade show and it's far from finished since I decided on the complete rewrite only a couple of days ago.

Thanks,

Phil

[LAVA 1.0 Content]

Thanks for the replies all round - changing the tiimeout solved the immediate problem.

My application is actually much more complex than this - it's a messaging system and dialler that runs on a PDA communicating with the outside world via serial port or bluetooth to a modem.

I originally wrote it as a demo using parallel timed loops communicating via queues - one for serial, one for each aspect of the UI system that required different timing, but the delay thru the app was horrible and unpredictable, sometimes up to 30s between when you pushed the button and when it came out the serial port. It was my first serious LV app (this is my second!) so I'm sure there are heaps of mistakes.

I decided to rewrite it using Events for the UI inside a State Machine, with queues to handle the comms between processes, notably the serial port and the UI / message handlers.

However the serial will not run inside the state machine becuase the Event structure for the UI locks the machine until an event happens (I think?), so I put a timed loop outiside to handle the serial comms, and another which needs to generate data for the serial port and deal with data from it in nreal time, independent of the UI - see the attached.

Any useful comments appreciated - I'm demonstrating it tomorrow at a trade show and it's far from finished since I decided on the complete rewrite only a couple of days ago.

Thanks,

Phil

You are definetly moving in the right direction. I have attached a simple example VI that illustrates a more flexible frame work. Hopefully this will give you some ideas, if not for this project than your next. The event structure has a timeout much like the queue, I pointed it out to you in the example, along with some other insights. Good luck, and keep at it :thumbup:

Download File:post-3882-1142874382.vi

[philips]

Thanks for the example - some questions though - how is it that you can put both the state name and the message into the queue? What is you have a message which inludes by chance,one of the state names - won't it force the machine to change state? Don;t you need separate queues for state, send and receive messages?

Also I need to have a watchdog message sender which sends out a message every 10 secs or so, is it ok to have a seperate timed loop which jcust generates this message and adds it to the message queue?

Cheers,

Phil

[LAVA 1.0 Content]

Thanks for the example - some questions though - how is it that you can put both the state name and the message into the queue? What is you have a message which inludes by chance,one of the state names - won't it force the machine to change state? Don;t you need separate queues for state, send and receive messages?

unless you are enqueuing into the same queue from multiple parallel VI's you should be able to confidently control the order of elements in the queue, which means you can be confident that if you enqueue two elements at once they will come out in that order. However when enqueing from multiple parrelel VI's it can cause a problem if your not careful. Another way of doing it is creating your own enque protocol i.e <state case>:<data>

Also I need to have a watchdog message sender which sends out a message every 10 secs or so, is it ok to have a seperate timed loop which jcust generates this message and adds it to the message queue?

I would make a seperate VI with its own queued message state machine, and a reference to the main Queue. I would keep track of the time not in a while loop, but by enqueing back to the same case, when time expired enque to "send watch dog" which would enque into mains, perhaps send:<message>. I also would spawn this VI from main. Perhaps this seems to complex, but it leaves you with a lot of flexibility to grow the app. I attached a modified version of the last example that illustrates some of these points, it is by no means comprehensive, but it should get you started.

hope this helps

Cheers,

Phil

Download File:post-3882-1142948761.vi

[philips]

unless you are enqueuing into the same queue from multiple parallel VI's you should be able to confidently control the order of elements in the queue, which means you can be confident that if you enqueue two elements at once they will come out in that order. However when enqueing from multiple parrelel VI's it can cause a problem if your not careful. Another way of doing it is creating your own enque protocol i.e <state case>:<data>

I would make a seperate VI with its own queued message state machine, and a reference to the main Queue. I would keep track of the time not in a while loop, but by enqueing back to the same case, when time expired enque to "send watch dog" which would enque into mains, perhaps send:<message>. I also would spawn this VI from main. Perhaps this seems to complex, but it leaves you with a lot of flexibility to grow the app. I attached a modified version of the last example that illustrates some of these points, it is by no means comprehensive, but it should get you started.

hope this helps

Thanks again - what is the difference between your 2 examples? I couldn;t spot it?

[LAVA 1.0 Content]

Thanks again - what is the difference between your 2 examples? I couldn;t spot it?

Apparently the only difference is in the file names. I messed up somehow when saving it in 7.1, and I can't find my modified code. I don't have time to redo now, maybe at lunchtime, I will get it out today.

[philips]

Apparently the only difference is in the file names. I messed up somehow when saving it in 7.1, and I can't find my modified code. I don't have time to redo now, maybe at lunchtime, I will get it out today.

No problem - don't rush!

I got my app working beautifully yesterday thanks to your help.

It now runs predictably, reliably, fast and exits cleanly. In fact I put a 200ms wait in the Receive state to slow it down so it doesn't use 100% cpu - on the PDA if you "exit" the application (as distinct from actually stopping it in LV), it just gets backgrounded but keeps chewing CPU so everything else slows down.

Thanks again!

Phil

[LAVA 1.0 Content]

No problem - don't rush!

I got my app working beautifully yesterday thanks to your help.

It now runs predictably, reliably, fast and exits cleanly. In fact I put a 200ms wait in the Receive state to slow it down so it doesn't use 100% cpu - on the PDA if you "exit" the application (as distinct from actually stopping it in LV), it just gets backgrounded but keeps chewing CPU so everything else slows down.

Thanks again!

Phil

Glad to here you got your application running. Here is the example I tried to send before. I also included the spawned watchdog VI. Set the path control on the communication3.vi to the location of the watchdog.vi and run. You should see a watchdog1 message in the sent message indicator every 10 seconds it will send another watchdog message. it will also send what ever message you send from the front panel. take a look at the code it should help you on your next project. Also, you may want to look into GOOP, I don't go anywhere without it. :thumbup:

Download File:post-3882-1143421814.zip