Programatic Access to network published shared variable - Knowlege Nugget

[Ben]

---

@Wayne.C wrote:

Timmar,

I've been using action engines (AE)  to handle programatic access to NPSV's.  I use the Open and Verify Connection when the program first starts to get things rolling and then store the refnum.  This allows me to get all the overhead done first.  After that I use normal read/write.  Sometimes I have an AE per variable, sometimes I use the same AE to access many NPSV's and store an array of refnums.

---

When confronted with an app using SV's I use a similar approach but use the DataSocket functions to access the values.

Ben

[Wayne.C]

---

Ben wrote:

When confronted with an app using SV's I use a similar approach but use the DataSocket functions to access the values.

---

Just curious Ben,  what would you say are your top 2 or 3 reasons for not using SV's? 

....class is in session.

[Ben]

---

@Wayne.C wrote:

---

@Ben wrote:

When confronted with an app using SV's I use a similar approach but use the DataSocket functions to access the values.

---

Just curious Ben,  what would you say are your top 2 or 3 reasons for not using SV's? 

....class is in session.

---

1) "ctrl-e" does not work.

Spoiler

Since I do not have acces to the code my hands are tied when fixing bugs. My customers will not tolerate "well we will have to wait a year and hope the NI decided to fix it.

2) They do not scale well.

Spoiler

SVs require you goof with the project to clone more. Using VI served Action Engines let me deploy more remote systems where all I need to know is the IP address to add another.

3) Performance.

Spoiler

Even NI has stopped pushing them in high throughput situations. I have a customer that was very disapointed after learning he would have to redo his complete app using TCP/IP if he wanted to see all of his data.

4) Like Globals they are subject to possible race conditions and unlike globals they are subject to cross platform race conditions.

Spoiler

VI served AE's have served me will since LV 6i. They were "THE WAY" to interact with remote LV apps as per the RT course for LV 6i. They were and are a lie in that they do not and cannot not replace the VI served AEs.

Why I still support them in some of my applications?

For low-speed long term applications, the Historical Trends still work and save me having to rewire the data management functions blah blah blah. But then again, the nightmares I have been through trying to keep trending working in secure facilites are an experience I would not with on anyone. (maybe this should be reason #5?).

Ben

[Wayne.C]

Ben,

Thanks for the thoughtful insight.  I can see how SV's can become quite a nightmare.  In my case I'm dealing with RT-Targets that normally run standalone.  On occasion the techs need to connect to check a status or change a setting via a handfull of low throughput SV's.  Even though it can be a hog, I like being able to host the SVE on the RT Targets.  Using the programatic string access to SV's and .ini files has allowed me to make copies of RT Targets much easier.

I supose to use DataSockets I would need to set up a PC to act as a DataSocket Server for the lab.

[Jed394]

---

@Ben wrote:

---

2) They do not scale well.

Spoiler

SVs require you goof with the project to clone more. Using VI served Action Engines let me deploy more remote systems where all I need to know is the IP address to add another.

3) Performance.

Spoiler

Even NI has stopped pushing them in high throughput situations. I have a customer that was very disapointed after learning he would have to redo his complete app using TCP/IP if he wanted to see all of his data.

4) Like Globals they are subject to possible race conditions and unlike globals they are subject to cross platform race conditions.

Spoiler

VI served AE's have served me will since LV 6i. They were "THE WAY" to interact with remote LV apps as per the RT course for LV 6i. They were and are a lie in that they do not and cannot not replace the VI served AEs.

I've been using NSV and sometimes they feel like a hassel.  I had not heard of VI served AEs before.  Can you point to an example ben? Or are you simpling talking about and AE on host/rt that handels all communication.  Thanks

[Timmar]

Wayne C

I use exactly the same method,

I monitor error out as well, when it crashes (and it does) I re-connect/verify.

, 

[Timmar]

A big chunk of my work uses modbus, either serial or TCPIP,  NPSV's are the simplest way to access them.

I don't have a requirement for high throughput though,

If I was going NI to NI in a new project I would be seriosly looking at network streams.

At least thar are still supported by NI

[Wayne.C]

Ben,

Thanks for taking the time to put that together.  Very informative and interesting use of VI server to bridge platforms.

[Ben]

---

@Wayne.C wrote:

Ben,

Thanks for taking the time to put that together.  Very informative and interesting use of VI server to bridge platforms.

---

You are welcome.

Please notice that to add another node to be controlled from the Windows machine I only have to change the IP address and open a connection to the new node.

I have used this technique since LV 6i in many applications where dozens of machines are controlled or monitored at the same time.

Ben