Shared Variables and global Variables

[justgene]

Hi I have a project that tests a flow battery, takes data and puts it in a file.  The problem I'm seeing is that the data isn't all getting from one vi to the data file in a second vi using shared variables and global variables, (some is but others are not!) .  In the analog inputs.vi I get data process it and connect it to a global variable.  In the multi-point UI.vi (the main display user interface vi) I connect it to a numeric display and to the section where I add it to a data file.  But here is where I get an error.  the data in the analog input vi is good but the data passed by the global variable is not I can show the flowing pix and I have attached a zip of my project.  I am using LV 2014 and a NI sbRIO board.

In the first picture it shows how I get the data from a channel on the sbRIO board

The second picture shown a global variable as the input to a data file - there are other things going on too

The third picture is a snapshot of my project.

I hope I have provided enough input, my question is why would the data be OK in one vi but not in another?  When I probe a data line of a global variable in one vi the data is good, but a probe after the global variable in a different vi does not read the same data?

I know I doing something wrong but what is it???

analog input vistore the data user interface vi

a snapshot of the project

[Bob_Schor]

I remember when Shared Variables were introduced -- it sounded very exciting and a neat way to transfer data in LabVIEW-RT.  It never (for me) worked "as advertised".  More recently, I started using Network Streams for passing data and communications between Host and Target -- much better, reliable, fast.  I actually introduced a few Shared Variables for slowly-changing Status information, but after about 3 days of testing, took them back out.

I haven't done much with sbRIOs.  I have taken a class or two with them, and recall seeing Shared Variables mentioned again, but I just don't trust them (based on my own experience).  I'm sure others have had better luck than I.

Bob Schor

[wiebe@CARYA]

Pretty much the same for me, Bob.

I'd only use SV when there's no other way. GB, never, although there are some corner cases where they are not pure evil.

[crossrulz]

I actually go so far as to say that Network Published Shared Variables are evil.  They are SLOW, introduce all kinds of weird race conditions, and hard codes a dependency.

My preference for sending data between a PC and RT system (sbRIO, cRIO, etc) is the STM library using TCP/IP.  It is simple and efficient.  And with TCP, your data is guaranteed to be read (assuming you have a decent connection).  So in this case, you just use Build Array to put all of your data into an array followed by Flatten Into String and then the STM Write.  On the PC side, you just do the read, use Unflatten From String to get your array of data, and then do whatever it is you need to do with that data (log, display, etc).

You can follow a similar process using Network Streams.

[wiebe@CARYA]

Then there are tons of projects where a VI server connection to the cRIO suffices. But that only works well when the current values are required (e.g. no history\buffering). Not sure if I'd use it now, but years ago that was the default solution.

[justgene]

First thanks for your help!

So I get the sense that sharing variables between VIs in a project using shared  or global variables is not a good thing.

I am not familiar with the STM library (I am not a new LV user but I am a old casual user).  Could you point out a place that I could learn how to use, or see examples of, passing variables between VI's in a project using the STM write?

I see how I could get data in my Analog Inputs VI and make an array as opposed to my set of global variables.  I will search to find STM Lib and Network Streams.  I hope it doesn't require a major rewrite.

Thanks again

Gene

[crossrulz]

---

@justgene wrote:

I am not familiar with the STM library (I am not a new LV user but I am a old casual user).  Could you point out a place that I could learn how to use, or see examples of, passing variables between VI's in a project using the STM write?

---

The library is available in VI Package Manger.  Here is another link to it: Simple Messaging (STM) Reference Library

The idea is that you send messages back and forth to tell the other system to update values (stored in global variables, DVRs, shift registers, etc).

[justgene]

Thanks! I am looking through this stuff now

[justgene]

Hi and thanks for your time and help!  I looked at the STM and loaded it with VI package manager.  For expedience I simply removed the analog input vi and placed the code into the main user interface this works.  In the future I need to understand this.  To my mind this is a big issue! To be able to share data from various VIs and be readily available to other VIs in the project.

I would like to see an example of sharing variable data between various VIs in a single project.  I do not understand why placing data in a variable inside one vi wouldn't just be available to another.  That said I can understand if these variables had multiple writers, but this is not the case here.  Assigning a variable with a value that is periodically updated seems susceptible to errors using "old data" but updating data and using it when needed is the whole point of many architectures, yes?  Perhaps this is why I'm having these difficulties?

Gene

[crossrulz]

---

@justgene wrote:

I would like to see an example of sharing variable data between various VIs in a single project.  I do not understand why placing data in a variable inside one vi wouldn't just be available to another.

---

Because you are talking about communicating across TARGETS.  Each target is its own computer and application.  It is not just a simple write variable at that point.  If going the Network Published Shared Variables, you have to make sure one of the targets is the variable server and has deployed them in order for other targets to use it.  But even then, I have found NPSVs to just be a major pain since they are SLOW and I have seen nothing but very strange race conditions from them.  I have had to do so many work-arounds to get them to work that it was actually A LOT simpler to do my own TCP/IP messaging (using STM).

I have not messed around with NXG, but it has a "Tag Library" that is supposed to be able to do what you are looking for.  But I have not messed around with NXG, so I am not going to promise anything with it.