How to enable RT FIFO on shared variable made from custom control

[FireIce]

I am trying to get my shared variables to behave: update when I tell them to and only update once. This is sort of 2 separate problems. Only updating once should be fixed by enabling RT FIFO on the shared variable. However, if you create a shared variable using a custom control (because your data type isn't available from the drop down menu), RT FIFO enabling is not available. Why is this? Is there another GUARANTEED way to do this?

Description of my goal: after having numerous issues with a large scale version of my Real Time program, I've started from scratch. My program only does the very basics with the goal of sending a waveform to my target to run on a few D/A channels, then return the data that I read from the A/D channels to make sure the waveform looks the same. Also, the program should be able to repeat this process endlessly without having to re-start.

-Host is a state machine with: Initialize - reset variables, Check for UI events - to start target, stop target, and end program, Send data - to create 2 waveforms and send it to the target via shared variable "input data" (2D array of doubles), Get data - to read the entire waveform on various channels after it has run using shared variable "all output data" (2D array of doubles), Write to file - (does nothing), stop - ends program.

-Target is a while loop with 2 states inside: False - target does nothing as it waits for the host to say "Start", True - target gets input data from shared variable, runs on 2 D/A channels and reads the A/D equivalent channels to ensure the waveform actually ran as expected. This happens in a deterministic loop with a non-deterministic loop waiting for the "Stop" command from the host. After the stop comes, the Written D/A waveforms and Read A/D waveforms are put into a 2D array and sent to host via shared variable, "all output data".

-I have tried putting "all output data" into a while loop that must re-iterate if it doesn't get data in the specified timeout period. I have also removed the while loop but kept the timeout specified. In both cases, the data is collected twice!

-Without specifying a timeout period, the host never gets updated data from "all output data" before it moves on to another state.

Summary: I need to have my shared variables update only once when I ask them to. I think my program is about as simple as you can get so I'm amazed at why it is currently completely unreliable.

(I have attached the host vi, target vi, and variables)

[FireIce]

I found that I had better success with the timeout on the "all output data" shared variable when I had it inside a while loop with the waveform graph outside of the loop. No double data collection so far. But is this the "proper" solution?

Also, the bigger the 2D array I am getting from the target, the longer I need my timeout to be in order to actually get the data.

[Will_S. · Accepted solution]

Hi FireIce,

To address your different questions:

1. RT FIFOs only support data types that can have pre-allocated space. This is to conserve determinism on the RT system.

2. Reading in the shared variable in the loop and having the graph outside the while loop will only show the last value from the shared variable, effectively showing only a single read. So if that works for you, it will give you the same result.

It sounds like  you have network buffering enabled on your shared variables. Is this true? Shared variables always need to have a value of some sort, and so it will continue to contain old data until new data is written to it. If you have network buffering enabled, the new data can be added after the old, thus making it look like you are reading the old data twice before getting the new.

[jkurtw]

Hi FireIce,

I will take a look at your VIs.

The ability to create an RT FIFO of a flat cluster (which is probably what your custom datatype is) was added in the LabVIEW 2009.

It sounds like you have your application well thought out. Have you looked at the architectures recommended in the CompactRIO Developer's Guide? Section 4 includes information on adding a networked UI and sending commands. 

Kurt 

Message Edited by jkurtw on 01-18-2010 11:22 AM

[jkurtw]

FireIce,

There are two primary things I would change in your logging state.

1) Use a regular while loop for the consumer loop

2) Change the global variable to an RT FIFO

Right now you have a single element variable to transfer data between the loops; effectively a register. For your use case (streaming data to a lower priority loop) it is better to use a FIFO that can hold many elements until they can be logged by the consumer loop.

The consumer loop here is data driven rather clock driven. This allows the consumer loop to sit and wait for data to be present. Then when there is enough processor time (the timed loop is not busy) the regular while loop will run as fast as it can until the timed loop interrupts it or until the FIFO times out (is empty).

This will prevent you from logging duplicate data and from losing data in the case that the file I/O takes longer than it should.

Hope this helps!

Kurt 

[FireIce]

I think I confused a few people by retaining shared variables that were present when the project was created in my diagram but not actually using those variables. I am not interested in the shared variable, "output data-RT", inside the deterministic loop. The only thing I need between the deterministic and non-deterministic loop is the update of my shared variable, "Stop-network", which stops data collection. The shared variable I am using to collect my data is outside the deterministic loop and called, "all output data-network". All of the data from each loop iteration is stored using indexing into a 2D array. I set it up this way so I don't slow down data collection by transferring data during each loop iteration. And the custom data-type of the shared variable, "all output data-network", was a 2D array of booleans (not a cluster).  I can pre-allocate this array prior to running but I know that won't change the options for RT-FIFO in the Properties box for the shared variable.

(I have attached an image of the target without the un-used variables)

-Will S. asked if I had network buffering enabled: when I do, I get the data twice. I turned that off and found that the output data plot on the target shows the data momentarily, then overwrites it with a 2D array with 2 different data points collected (see 2nd attached image). This is what the host receives from "all output data-network" since the real data gets overwritten.  Disabling the buffer probably is a good solution to the double data collection problem. Now I have to figure out why my 2D array of output data is getting overwritten.

-Kurt, I haven't looked at the CompactRIO Developer's Guide because I am using a PXI machine. Does this matter?

Thanks everyone for the help so far!!!

[FireIce]

Ok! I figured out the problem: I had buffering enabled on my "Start-network" shared variable. This was set to go False when I hit "Stop-network" so that the target would not re-run after I hit stop. But the target would query "Start-network" before it had been set to False and re-run anyway. With the buffer disabled, the target sees that "Start-network" is False and doesn't re-run and, thus, overwrite my output data.

Overall, I feel overwhelmed by the number of options for shared variables. Does anyone know of a comprehensive guide to setting up your shared variables properly? If I had set up my variables right the first time, I wouldn't have seen these quirky problems!

Thanks to Will S. for the solution!

---

Will S. wrote:

...

It sounds like  you have network buffering enabled on your shared variables. Is this true? Shared variables always need to have a value of some sort, and so it will continue to contain old data until new data is written to it. If you have network buffering enabled, the new data can be added after the old, thus making it look like you are reading the old data twice before getting the new.

---

[jkurtw]

The white paper, Using the LabVIEW Shared Variable, is the closest thing to a comprehensive shared variable guide.

Kurt