LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT FIFO with complex data?

Solved!
Go to solution

Scenario:

We have a deterministic loop on an RT target (NI-PXI). The speed need to be 1 Hz only with as less jitter as possible. This deterministic loop will execute picoAmp measurements using many Keithley6487 units (using low level SCPI functions, so Measurement configuration, then "INIT" command all devices (takes about 2 msec per device), and about 300 msec later "FETCH" data from all Keithleys (requires about 10 msec per device). This deterministic loop will have a state machine and accept commands coming from lower priority loops (like zero check, reset, etc one Keithley or multiple). The measured data will be in a form of double array, so it is OK for RT FIFO communication between the loops.

However I wonder how to extend features: during measurments some warning might be created by the Keithley VIs in string forms. Also, an acknowledgement/feedback of certain actions performed on the Keithley should be reported back to the lower priority loops, again in original form they are strings. Strings are not supported by RT FIFOs, but I have found this trick below how to convert it (see below).

 

To broadcast all info properly, I think I should send the measurement data as a double array, and a same sized string array which would hold any SCPI related warnings/acknowledgments from the Keithley units. Since I cannot use cluster either for RT FIFO, is there a trick to "compress" or convert the complex cluster type into something RT FIFO compatible?

 

Right now I think about just a workaround: I could create two RT-FIFOs, one for the double data array and another using the trick below to convert from string (both fixed sizes). I could convert the Keithley info string array into a comma delimited single string, so I could use the "String to byte array" function.

 

Any advices and suggestions are very welcomed! 🙂

 

disclaimer: I am a beginner in the field of RT...

 

fifo test with strings.png

0 Kudos
Message 1 of 14
(6,634 Views)

if you know what error/info text can be returned, why not try to use "return-codes/error-number" to transport the info,

then afterwards you can lookup in an array/typedef


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
Message 2 of 14
(6,628 Views)

Thanks, a lookup table is a good idea. But the other part of my question is still: so should I use two RT-FIFO? No performance issue using two? One for the double data array, and another one for some lookup table codes (U32 array for example)?

0 Kudos
Message 3 of 14
(6,622 Views)

i must pass on that one, didn't use any rt-fifos yet... my infrastructure is not time critical so i use network streams,

but i guess that shouldn't be a problem.

 

<edit>

ok rt-fifos are intra target... i use plain queues/user-events for that

</edit>


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 4 of 14
(6,619 Views)

You can pack the data into whatever format you like and then send a DVR (fixed length 32-bit) instead of the data itself.  You can even send Objects this way.

Message 5 of 14
(6,614 Views)

Hmm, another option is to just use some simple Queue. In this case we can have a bit more jitter, but the code will be more flexible. I have a kind of feeling that for our applicaton the RT-FIFO with deterministic loop is a bit overkill. It is right that I can send the data in my VI between two loops with tight timing, but in the end we will have a network with Ethernet: 3 or 4 PXI systems with many GPIB interfaces and many Keithley units. There will be a "master PXI", which will collect up all data and info from other PXIs, and send everything to a Siemens S7 PLC using TCP/IP. Also, the master PXI must recieve commands from the PLC and address the required Keithley units accordingly.

 

I guess with the above design we will have jitters anyway (TCP/IP), so why to use RT FIFO in each PXI I ask myself? I will try to convince my boss that it is just OK if the Siemens PLC gets data "roughly" at every 1 second. Anyway, here our processes ar not too time critical, but we need high reliability (i will need to design the GPIB DAQ state machine on the RT OS that it must survive a failing Keithley or phyiscal disconnection, plus option to programmatically reconnect, etc...)...

0 Kudos
Message 6 of 14
(6,607 Views)

@Intaris wrote:

You can pack the data into whatever format you like and then send a DVR (fixed length 32-bit) instead of the data itself.  You can even send Objects this way.


Could you show me an example or a link? Thanks!

0 Kudos
Message 7 of 14
(6,605 Views)
Solution
Accepted by topic author Blokk

When initialising the RT-FIFO instead of using a fixed-size array, use whatever format you require for your data but before passing it to the "Create FIFO" Function, use the "Create new DVR" function and when reading use the "Destroy DVR" function to reclaim your arbitrary length data package.

 

DVR RTFIFO.png

 

Message 8 of 14
(6,599 Views)
Solution
Accepted by topic author Blokk

At that point you might as well use a standard queue instead of an RT-FIFO. At 1hz, my guess is the difference in jitter between that and an RT-FIFO will be minimal (based on experience, but I haven't benchmarked it). If you really, really want to minimize potential jitter with a standard queue, you can pre-fill the queue to the maximum number of elements you plan to put in it (and then flush it), which will avoid the time needed to allocate slots to fill the queue the first time elements are enqueued.

Message 9 of 14
(6,534 Views)

@nathand wrote:

At that point you might as well use a standard queue instead of an RT-FIFO. At 1hz, my guess is the difference in jitter between that and an RT-FIFO will be minimal (based on experience, but I haven't benchmarked it). If you really, really want to minimize potential jitter with a standard queue, you can pre-fill the queue to the maximum number of elements you plan to put in it (and then flush it), which will avoid the time needed to allocate slots to fill the queue the first time elements are enqueued.


My recent plan is that, I would have two Queues: one for the incoming commands (from a low priority TCP/IP loop) to process, and another Queue for data to send from this deterministic loop to a low priority loop for after-processing. So this means I would have a Dequeue element in the deterministic loop to dequeue an incoming command. Also, an Enqueue element for the other Queue ref, to send GPIB measurement results to another loop.

In this case, if I use a Dequeue in the Timed Loop, how should I setup parameters like timeout for the Dequeue, etc? Can a deterministic Timed Loop play nice together with Queues on an RT target?

Thanks!

0 Kudos
Message 10 of 14
(6,480 Views)