passing enum values via rt fifo

[sciu]

Hi everyone

I've got a question about passing enum values via a rt FIFO queue. When I want to pass clusters of double or boolean values it works fine (even though clusters aren't supported by rt FIFO - somehow). When I want to pass unsigned word enums the values do not arrive (or just occationally). Attached you'll find 2 VI's: A "set process data" VI and an "init" VI.

Does anyone have a suggestion regarding that issue?

Thanks a lot for support :-).

[crossrulz]

Are you getting errors anywhere in the path of the data?  I'm specifically referring to anything upstream to the FIFO Write and the FIFO Read.  I have had no issues passing enums through an RT FIFO.

[sciu]

No, I'm not getting Errors anywhere in the path. The path works fine until the "set-process-data"-VI. There I don't get a value change of the enum. I can also attach the superior VI where the "set-process-data"-VI and other relevant VIs are located. You may find eventually a mistake of the programming at the stage of the superior VI....

But what I had to do is to give a min. dt-value of 10ms to the timed-loop in order to avoid an -8888 error/warning (finished-late warning).

thanks a lot

[Bob_Schor]

Hmm, I'm "on the road" and unable to reach my Test Machine where I've safely installed LabVIEW 2017, but I'm wondering about something you said, "There I don't get a value change of the enum.".  I may be "mis-remembering", but does the Real-Time OS support Events?  I have a vague recollection that the answer was "No".  I haven't done major development on my big RTOS Project for two years or so, but I recall using other methods, like Notifiers and Queues, to say "Do this now" ...

Bob Schor

---

[sciu]

Hi Bob_Schor

Well, I'm using Event structures in my main GUI. The values are queued in regular Queues and that works fine. Also the Transmission via Network Streaming works fine. The values are then "extracted" from the Network stream and handed over to the rt-FIFO Write function. After that step the value of this particular enum seems to get lost. All the other values such as booleans, double etc. are getting transferred by the rt-FIFO function...

Thanks a lot

[wiebe@CARYA]

---

@sciu wrote:

No, I'm not getting Errors anywhere in the path. The path works fine until the "set-process-data"-VI. There I don't get a value change of the enum. I can also attach the superior VI where the "set-process-data"-VI and other relevant VIs are located. You may find eventually a mistake of the programming at the stage of the superior VI....

But what I had to do is to give a min. dt-value of 10ms to the timed-loop in order to avoid an -8888 error/warning (finished-late warning).

thanks a lot

---

Everything that happens happens in subVI's that are not included. We'd need those (in a zip).

[Bob_Schor]

Interesting!  When I learned about Real-Time, I recall being told about Determinancy and Jitter, and about "hierarchies" of transmission from various loops to preserve determinancy.  The Timed Loop was supposed to "do the least", getting data with minimum (and deterministic) latency and getting rid of it ASAP through the RT-FIFO.  The typical data being managed were straight from the hardware devices, i.e. they were numeric or boolean, never "programmatic" variables such as Enums.  Once we got the data safely out of the Timed Loop, transmission to other processing loops could go via Queues, Notifiers, Network Streams, etc. (indeed, my RT-FIFO's data is enqueued to another processing loop that sends the data to the Host via a Network Stream and does some local decision-making as well).  Not near my PXI, so I can't test ...

Bob Schor

[sciu]

Well, I'm going to try to convert the enum value to another data Format before it's been transferred via rt FIFO...maybe not a "clean" solution but we'll see...

thanks

[sciu]

So far it didn't work...I'll have to check it out tomorrow....

[wiebe@CARYA]

Just an idea...

The RT Queue is set to a size of one element. So when you write faster then you read, you will either lose items, or stall the write loop. Usually you use queues to decouple dependencies like this. A queue size of 1 is useful to distribute the current value, which is what you seem to be getting at the moment. If you want all changes, the queue should be large enough to cover jitter between read and write loops.