Better Real Time Patterns?

[xkenneth]

All,

   I'm working on a complex real-time design where I want to communicate about 100 RT variables from a cRIO to a network interface. I'm following the suggested "myVar - rt" and "my-Var - network" pattern. I've got all of my variables clustered logically amongst multiple lvlibs. So basically, to communicate these to the HMI via the shared variable engine. I've got to statically "write" in a low priority loop all of the "rt" variables to the "network" variables.

   This sucks.

   Is there any easier way to do this? 

   Can I programmatically search the lvlibs and get a reference to the shared variables and then execute this code programmatically?

   And what about writing back from the HMI? I can't really do "control" communication from the HMI to the real-time via shared variables, so I've got to use TCP (for which I've employed the STM library.) So now I've not only got to update all 100 of these RT variables in a loop, I've got to have a loop that's listening for 1 of 100 TCP commands to change the value of any of these 100 RT variables!

  Am I doing this completely backwards here?

  Am I completely wrong?

  Thoughts, comments, questions, or flames welcome.

- Ken 

[Ben]

---

xkenneth wrote:

All,

   I'm working on a complex real-time design where I want to communicate about 100 RT variables from a cRIO to a network interface. I'm following the suggested "myVar - rt" and "my-Var - network" pattern. I've got all of my variables clustered logically amongst multiple lvlibs. So basically, to communicate these to the HMI via the shared variable engine. I've got to statically "write" in a low priority loop all of the "rt" variables to the "network" variables.

   This sucks.

 ...Am I completely wrong?

  Thoughts, comments, questions, or flames welcome.

- Ken 

---

No flames from me! I have been stoke the fire since LV 8.0. 

I just write my own TCP/IP functionality. And if you don't want to implement the protocl yourself then ...

Action Engines can be used to access functions across networks using VI server. All I have to do is manage my IP addresses. I have been using this technique since LV 5.1 and it still works good.

Ben

PS And if your app can stand it SCRAMNet shared memory screams.

Message Edited by Ben on 10-27-2009 06:09 AM

[viScience]

Hi Ken,

Yes, I think you have identified a weakness in the SV concept since you cannot obtain a reference to a single process SV.  However, I also have a large scale distributed cRIO system with multiple HMI's and have a workable architecture that avoids the static transfer of SV<->NSV's.  In its simplest configuration I have bound all IOV's to NSV's on the cRIO targets.  I then bind HMI NSV's to cRIO

NSV's.  I have found that reading NSV's on the cRIO is fast and efficient, writing NSV's are expensive but I limit this overhead with intelligent writes that look for significant change before committing.

I also have a more elaborate architecture that programmatically addes a CVT (current value table) layer in between the IOV's and the cRIO NSV's.  This allows me to do filtering, table based linearization, zero offseting, etc.  I can then operate from the CVT's which are a bit more efficient than the NSV's, however it does require arbitration logic to mantain HMI NSV write capability via bindings to the cRIO NSV's.  For me the value of being able to have all my variables automatically bound, viewable and loggable is worth the extra trouble to deal with NSV overhead in my cRIO logic.

[jkurtw]

The ability to programmatically access network shared variables was added in LabVIEW 2009.

Check out this white paper: http://zone.ni.com/devzone/cda/tut/p/id/9351 

See the section called Reading and Writing I/O

Kurt

[viScience]

Kurt - nice article, but it appears that you still cannot open a reference to a single process shared variable in LV2009.

[jkurtw]

Yes, you are correct sachsm. This is still a gap that needs to be addressed.

From the original post, I believe xkenneth only needed programmatic access to network variables.

Kurt 

[Ben]

---

jkurtw wrote:

Yes, you are correct sachsm. This is still a gap that needs to be addressed.

From the original post, I believe xkenneth only needed programmatic access to network variables.

Kurt 

---

THen Datasocket reads and writes are a good aproach, after all that is what LV converted all of my old DSC tags into when the Tag engine was toossed and replaced with the Shared Variables (when updating LV 6.1 DSC to LV 8.2 DSC). Data sockets let you define the URL of the shared vables you will R/W and allow you to scale up an app with little effort aside from updating the library.

Ben

[Jarrod_S.]

The new Dynamic Variable API in LabVIEW 2009 should have better performance than the old DataSocket functions. I would recommend using these instead. The Dynamic Variable API functions also let you dynamically build variable references. The variable references are a special data type that can be wired into a Property Node and such, but you can also convert to them easily from strings that contain the proper URL.

[Ben]

---

Jarrod S. wrote:
The new Dynamic Variable API in LabVIEW 2009 should have better performance than the old DataSocket functions. I would recommend using these instead. The Dynamic Variable API functions also let you dynamically build variable references. The variable references are a special data type that can be wired into a Property Node and such, but you can also convert to them easily from strings that contain the proper URL.

---

Now I am just plain disappointed that info is not well published.

Is there a while paper comparing the speed and illustrating how we can use them?

What release note should I have read that would have told me about that?

Ben

[Jarrod_S.]

Consider the speed comment hear-say for now, I suppose. I'm not sure of any official benchmarks, but that's not to say they don't exist.

Here's a help document about using the new functions. The What's New in LabVIEW 2009 help topic would certainly list this new feature.