RT Target: Using SPVs vs Local Variables from controls/indicators

[ftsiiii]

I'm building a power plant simulator that runs a model on a headless RT desktop target and communicates with the physical plant controllers(e/ip) and an operator gui(NSV). The model often freezes in interactive mode and leaves no trace of where it's hung up. It seems that my lack of fundamental understanding of LabVIEW data structures is costing me a lot of development time. After some searching I still have some specific questions followed by a brief description of my application...

Question:

1. I know RT Targets remove the front panel, but local variables created from them are convenient, and it SEEMS to work most of the time. Is this method okay?

2. How would it affect the execution to remove all the controls and just use the SPVs throughout the model VI? Note: They are all read and written multiple times throughout the plant model vi.  

3. Seeing as I'm only interested in the current values, I DO NOT use buffers or RT FIFO. Is this a mistake?

4. I try not to put the terminals inside the timed loop that contains the model, instead using local variables inside, but was unsure if this makes a difference.

My plant model has become quite large and it seems that crashes are becoming more and more frequent.

1. Data is read/written concurrently in a seperate Communications VI via ethernet/ip.

2. This data is shared via SPVs between the Commucations VI and the Plant Model vi.

3. Inside the model, I start by reading the SPVs (about 30) and writing them to controls/indicators.

4. I use local variables from the contols/indicators pretty liberally throughout a very long, flat sequenced vi containing the plant model.

5. At the end of the sequence I write the new values to the SPVs which then go back to the commmunications vi and are written to the controllers via ethernet/IP.

Any help would be greatly appreciated! Thanks!

[Bob_Schor]

I don't know what a SPV is.  Use of Local Variables is always a problem because of race conditions, and where could race conditions cause more havoc than with a Real-Time system?

Some Basic Information would help me (and probably my colleagues) have a better idea of your system and requirements.

• What version of LabVIEW are you using?
• What is the RT Platform?  [It sounds like a PC on which you have installed LabVIEW RT and a suitable RT-OS -- please clarify].
• What sort of clock rates are you running?  How fast does the RT system have to run (what is its basic loop time or frequency)?
• What type of communication do you need (and at what frequency) between the Host and Remote system?

I have an RT Project where the basic clock rate on the RT side is 1KHz.  It communicates with the Host PC using Network Streams.  Both the Host and Remote have a basic State Machine based on the Queued Message Handler, and a pair of Network Streams are used to let the Host send a Message to the Remote, and the Remote send a Message to the Host -- this is used primarily for synchronization and Start/Stop/Settings control of the Remote.  Other Network Streams transfer data from the Remote to the Host -- in our case, we stream 16-24 channels of sampled (1KHz) data to the Host, which streams it to disk while displaying 50-point averages (so we get a new point every 20 msec, with our scrolling Chart showing the last 30 seconds of data).

I suspect that a similar design might work well for your project, provided the data rates aren't orders of magnitude higher than mine ...

Bob Schor

[ftsiiii]

Bob, I appreciate the patience the quick reply!

By SPV i meant Single Process Variable, sorry.

What version of LabVIEW are you using?

LabVIEW 2015

What is the RT Platform?  [It sounds like a PC on which you have installed LabVIEW RT and a suitable RT-OS -- please clarify].

You are correct. I'm using a desktop PC with the LabVIEW RT-OS installed.

What sort of clock rates are you running?  How fast does the RT system have to run (what is its basic loop time or frequency)?

I was running it at 100ms periods on a 1Khz  clock.  When I deployed our RT App I noticed, via a network sharved variable on the host PC (labview development on a windows machine) that the iterations were clocking in way too fast on the target (1ms) no matter what I set the dT to outside of the timed loop. So, shooting in the dark, I tried the MHz clock with a dT of 10000us. This seemed to give me the 10ms loop time I was looking for. By the way, the method I used in the model loop to get loop time was the 'Get date/time in seconds' functions with a feedback node, taking the difference and writing it to a network shared variable. Also this MHz clock was not the <absolute time> option as I was still seeing 1ms loop times.

What type of communication do you need (and at what frequency) between the Host and Remote system?

1. One computer hosting the SVE and  acting as an Operator/'Student' console.

2. Another Computer acting as the 'Instructor' console communicating with the Operator via PSP Aliased Shared Variables.

3. The Third computer is the RT Desktop Target running the actual power plant model VI and a Communications VI in parallel. (reading this answer now makes me wonder why I have them in parallel and not in series.)

-The Communications VI on teh reads the Network Shared Vars from the Operator/host and writes them to corresponding Single Process Shared Variables that are used as the inputs to the Plant Model VI.

-Those single process variables are written to controls at the beginning of the Plant Model VI. These controls are read/written multiple times throughout the routine.

-The plant model returns single process variables that are read byt the Communications VI and written to Network Shared Variables to be used by the Host/Student. 

Frequency: 10ms is what I've been using, although I bet I could probably get away with 100ms.

[Bob_Schor]

Some things to consider when running LabVIEW-RT:

• Only the RT Target can be expected to have an accurate "clock".  Because of this, only the RT Target can "time itself", and can pass that time (via a non-deterministic route, whether Shared Variables or Network Streams or VI Server) back to the Host.
• Trying to synchronize Host and Target is difficult at best.  Don't rely on the timing of data from the Target to synchronize Host and Target.
• It isn't (yet) clear to me what the communication path (and timings) are between Target and Host.  It sounds to me like your Target is running a simulation and generating data points at 100 Hz.  What interaction does the Host need with the model running on the Target?  Is "Start" and "Stop" adequate, or is finer control ("Change the Gain" or "Change the Time Constant") required?
• Remember that the only system with accurate timing is the Target!  It needs to be allowed to "do its thing" with nothing to interrupt the time-critical Timed Loop.
• For Timing, use the Timed Loop structure.  Do not use the "Get Date/Time in Seconds" or other functions on the Timing palette.
• You definitely want to take advantage of LabVIEW's parallel architecture!  Your Timed Loop should be structured to do "almost nothing" -- you want to do a single calculation, or a single DAQ Read ("single" might mean "take 10 samples at 1 KHz and call me when you have them all"), then ship the data out of the timed loop to a parallel process that's just waiting for data to chew on.  The lower-priority "processing" loops can occasionally take more time to process data than the Timed Loop does to acquire it (for example, if you are streaming data to the PC via Network Streams, the first packet may need to "prime the pump" to get the Host and Target synchronized, but once the transfer is going, it should be able to keep up).  Keep the Timed Loop "lean", and definitely do not put "Communication" code in there.
• I don't think that Network Shared Variables are as robust and as speedy as Network Streams.  I know whenever I've tried to use them, even for the occasional small amount of monitoring data, they caused trouble for me.
• I'm puzzled by your description of two hosts and one RT Target.  Is the Target trying to talk to both Hosts?  Sounds complicated ...

Bob Schor