Network Shared Variable wiring topology question

[rkmadse]

Wondering which one of the three loops (made up loops just for this question) you would use in your code. I have heard mention of not wanting to overwhelm the shared variable engine by having parallel reads/writes of NSVs.  Also an explanation behind why you would choose one over another is great.

Thanks,

Kellen

[altenbach]

I probably would use a single one, containing an array of booleans. 🙂

[Bob_Schor]

Seven or eight years ago, before I abandoned Network Shared Variables except for the most trivial and unimportant of tasks, I adopted the "serpentine pattern" (your third), which was the NI-suggested one, and it did have the fewest problems in execution (but I still stopped using these things).

Bob Schor

[altenbach · Accepted solution]

Well, the tree options are not equivalent. For example the middle one is only appropriate if you don't care about errors. Do you?

That leaves the top and bottom. Accessing a network shared variable is using a single shared resource, but I am not sure exactly how it is implemented on the network layer. If multiple request can be sent, each waiting for a response, your top example will be faster while the bottom version forces serialization where each response needs to come back before the next request can be sent out. On a fast local network it will probably make no difference but if there is a slow link to a very remote device, it might.

TOP (in any order):

Request 1 ... response 1

          Request 3 ... response 3

                    Request 2 ... response 2

-------------------------time----------------->

                             ...

BOTTOM (Forced sequential order):

Request 1 ... response 1       Request 3 ... response 3         Request 2 ... response 2

---------------------------time----------------------------------------------------------------------------->

The above might, or might not be correct. We really don't know how it is implemented under the hood and how the compiler schedules these things. Can you point to a thread where "overwhelming the shared variable engine" is discussed? I would guess that becomes more relevant with large data structures, but I would think that the implementation is robust.

Does the loop really need to run at full bore, potentially saturating the network? I assume that your real application has some reasonable wait in the loop. Since you are just updating the front panel indicators, it does not need to be faster than your eyes. 😉

[rkmadse]

Bob, 

Thanks for the response! I appreciate the feedback. 

When you left NSV in the dust where did you go? Network Streams? The majority of the test stations we built have some stuff running in RT, and some on the host and then the NSV's communicate button pushes and other things back and forth but I hate NSVs and would love a different way to accomplish that. 

--Kellen

[rkmadse]

altenbach, 

I appreciate your feedback and help. I would for sure in practice put them in an array but just wanted to make the point of having several NSVs all updating in a loop and how to accomplish that (with the best suggested practice). I haven't seen any specific thread regarding having the NSV Engine overwhelmed but have heard that kicked around a few times here where I work. I frankly hate the look of the serpentine serial method, just doesn't jive with the rest of everything so my preference is something like Example 1 but I just didn't want to be doing something that was bad practice.

In our recommended applications at work (stuff we have been doing for a while), we take the NSVs and update them periodically in a "housekeeping" loop, and they update to local variables that are then used in the RT VI. I'm not sure the benefit of doing it this way but it was the way I was taught to do it. 

Would love to have a better solution than NSVs honestly because I have had many problems with them over time. 

--Kellen

[Ben]

---

@rkmadse wrote:

....

Would love to have a better solution than NSVs honestly because I have had many problems with them over time. 

--Kellen

---

I was advised by an NI insider back in about LV 8.x to avoid NSVs.

If your update rates are low (1 per second or so) you can serve an Action Engine via VI server (which was THE WAY to do it back in 6.1 of RT)

or

Roll-our own using TCP. They can be as fast as your network and once you write it, you can re-use the net time.

Both of those methods avoid having muck about with define the SVs in the project and if implemented correctly, will let you define info shared dynamically.

It is your call.

Have fun!

Ben

[rkmadse]

If you remember any threads or examples that do what you have stated:

---

Roll-our own using TCP.

That would be awesome!

Thanks!

--Kellen

[Bob_Schor]

When I abandoned NSV, I adopted Network Streams.  I'm using them to this day, very happy with them.

Bob Schor

[rkmadse]

I have used streams as well and thought they worked well. I think my biggest problem with the streams was the setup and tear down and having to check the connection on both sides etc. I think if I just encapsulated better and set things up that it would take up less space (square inches) on the block diagram and I'd like streams better. I'll have to keep looking at that as a better solution to NSV. 

--Kellen