network shared variables in RT

[pittlei]

Hi

I have a system comprising of a control computer with labview and 3 CRIO.

I created hundreds of shared variables in a library under CRIO RT.  so that I can create the PID loop with those SV and communicate with my PC.

I am wondering if I can create the SV under my computer, instead of the CRIO RT?   in this case, if I reboot my computer or lost the connection between my PC and CRIO, will the PID VI (in the CRIO) associated with the SV under my computer got error and out of control?

thanks

[GerdW]

Hi pittlei,

---

@pittlei wrote:

I am wondering if I can create the SV under my computer, instead of the CRIO RT?   in this case, if I reboot my computer or lost the connection between my PC and CRIO, will the PID VI (in the CRIO) associated with the SV under my computer got error and out of control?

---

When your host computer hosts the NSVs then your cRIO(s) will act "strange" when they have lost communication with their host. You might either operate on stale data or get an error when trying to read the NSV…

I guess you already implemented some error handling in your PID control VI!?

---

@pittlei wrote:

I created hundreds of shared variables in a library under CRIO RT.  so that I can create the PID loop with those SV and communicate with my PC.

---

"Hundreds" of NSVs? Really?

I guess there are better ways to setup a communication between host PC and cRIO…

[rwunderl]

---

@pittlei wrote:

I am wondering if I can create the SV under my computer, instead of the CRIO RT?

---

Is there a reason for moving the library? Why would you not want to control the system and host the variables on the same RT platform?

When the host is unreachable, there are generally two different errors that will occur: an immediate error saying the shared variable was not found, or a long timeout error (e.g., 10 seconds) while it waits for a response from the host. It's difficult to tell which error you will get depending on when exactly the disconnect occurs.

I would recommend hosting variables critical to control on the system performing the control. Inputs to the control can be distributed, but you do need some smarts to handle remote data this is not being collected (for whatever reason).

You can also distribute the variables; host some on the computer and some on the cRIOs, whatever makes sense for your application. Use the shared variable programmatic access API, not implicit nodes and you can easily access shared variables hosted anywhere from anywhere (and it's configurable using PSP URL strings).

[pittlei]

@rwunderl

thank you for your answer. it is very helpful.

The reason I want to host the SV in the PC is because I need to log the data.  I used the citadel database and in future third party historian requires the OPC connection. It seems to me I can perform the logging when the SV is under the PC. 

My solution now is that placing the SV in the RT , and create the aliasing SV in the PC. Not sure this would be the correct way

[rwunderl]

That is a totally viable solution. There's also no reason you can't specify a remote database for logging the library to. Technically speaking, this should work fine too; however, I have seen in the past that logging to a database remote from the library sometimes results in data loss. I never did figure out why. The solutions were to either have a library local to the database with its variables aliased to the remote variables or to have the remote system write to the variables on the logging computer directly (and not host the remote variables at all). The biggest issue with the duplicate variables is that you have to manage multiple sets of the same variables, which can get frustrating when you're constantly changing things.

In any case, it sounds like you're on the right track with your solution. But to GerdW's point, you should probably not be using shared variables for communication, and only for single-point data (data that does not change more than a few times per second and it's not critical if a sample is missed).

You've mentioned PID controls, just keep in mind that NI does not recommend using shared variables for human safety or time-critical applications. I can't find a reference for this at the moment. If there's something important going on, use the FGPA or they do now sell functional safety modules if you want to get crazy about it. But at that point, you might just want to go with a PLC.

[pittlei]

once again, thank you for telling me to use the SPSV instead of the NSV.

However, I am trying to understand better how the NSV's property.

Here I attach my project test case for your reference.

I am trying to understand how the write and read works for NSV.  For the test case, I set the no buffer for the NSV and there is 100 ms delay between the read and write.  In this case, it seems to me I can read what I write for the this loop.

But if I can the delay to 10ms, it seems to me that I can not read what I write for this loop, but only for last loop.

That is telling me that the write and read are not stored in the same place, otherwise how come I am not getting what I was writing ?

then how long will be the networking publishing period for my attached case ? 

(I am coming from a CS background. It is difficult for me to understand the application API without reading the background code beneath)

[rwunderl]

---

@pittlei wrote:

once again, thank you for telling me to use the SPSV instead of the NSV.

---

I am NOT recommending Single Process Shared Variables (SPSVs), which are basically the same as project global variables. I am recommending you use the Shared Variable API (Data Communication>Shared Variable>Read/Write Variable) and not the "implicit shared variable nodes" (the big orange/blue/green variable boxes on the diagram) for variable access. That way, you can specify the variable path as a URL string instead of the variable on the diagram being tied to the project.

I am still using LabVIEW 2018 on this machine, so I cannot open your project. Refer to what I said about single-point data above. The Shared Variable Engine (SVE) is an OPC server; it manages the data in and out however an OPC server is supposed to manage it. I believe it has a minimum update period of 10 ms as noted in the NI page I referenced above.

Shared variable reads in your software return on the order of microseconds because they reference a local lookup table and do not require pinging out over the network for a result every time you want to read a variable. Again, this is a detail of how OPC works and is nothing to do with (or controlled by) your program. I had a program that read about a thousand variables in under a tenth of a second.

Now what the latency in the actual value of the variable is, that is up to the OPC engine and how it works internally. I have noticed that it sometimes can take 0.1~1.0 seconds to get a value update in a Write-Read situation as you have also noted. As I said before, shared variables are not for high-speed, lossless communications. You will require a more complicated solution if that is what you require. Maybe Network Streams or something.

[pittlei]

I just tested the read/write shared variable node you mentioned. However, I didn't notice any difference from the big NSV directly dragged from the project explorer. 

I will try to learn what is the network stream to see how it works. 

thanks