LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT FIFO with complex data?

Solved!
Go to solution

Timed loop must read with timeout zero and handle the timeout gracefully.  Otherwise you have jitter.  Of course it depends on how much jitter you can tolerate.  If 1ms is too much, then timeout 0 is the only option.  If 20ms Jitter is OK, then you might be able to get away with a non-zero timeout, but you still should handle a possible timeout gracefully.

0 Kudos
Message 11 of 14
(1,194 Views)

The idea is that, I would use a Queued State Machine "on" the Timed Loop (deterministic loop). So I just Enqueue a new "measure!" command after every iteration again. If a command apears in the low priority TCP/IP loop, a priority command will be inserted into the front of the Queue, and then processed in the Timed Loop. Does this makes sense? So I would set the timeout of the Dequeue element in the Timed Loop to -1 (never time out), since it is ensured there is always element in the Queue.

 

It would be great to process faster when a priority command is Dequeued in the Timed loop, and not a simple "Measure!" task (which needs to take 1 second with some jitters not a problem). Is this possible somehow? Hmm, I think I need to dig into the help of the Timed Loop, I am really not familiar how to use it properly 🙂

0 Kudos
Message 12 of 14
(1,191 Views)

I would never use a timeout -1 in a timed loop.  If you are guaranteeing that an element is present, then use timeout 0 and handle errors if no item is found, that will help you debug.

 

In your case you would also have to refrain from autoinserting a "measure!" command if the priority queus is not empty.

 

I think maybe a timed loop is not the correct choice for your application.  Why not use a simply while loop?

Message 13 of 14
(1,187 Views)

Yep, maybe we try to use a screw driver for a nail. For sure a While loop would be just more simple to use, with additional benefit it is easy to set different timings inside the cases (measurement task should round up to 1 second, any other priority commands should execute as fast as possible). And we still keep the other benefits of a Real Time OS, but we do not need tight timing...

Thanks!

0 Kudos
Message 14 of 14
(1,173 Views)