LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to control the value of a shared variable at start of vi

Solved!
Go to solution

Hi all,

 

In short: How can I ensure the values of shared variables when a vi starts?

 

I have two vi's.

One is a main vi from which I control a boolean shared variable 'Run DAQ'.

The other is a vi with a while loop that 'polls' for the 'Run DAQ' shared variable which is wired to a Case Structure. If the case is false it does nothing, if it is true is runs some simple DAQ IO within a while loop.

To be sure that at the very start of the vi the 'Run DAQ' shared variable is set to false (no matter what 'state' the shared variable was left in before the vi started) I write a boolean constant to this shared variable 'Run DAQ' outside of the main while loop.

 

Now my question: how can it be that the Case structure can enter into the 'True' state even when the main vi is not running and there is thus no way the shared variable can be written to. I know that the shared variables are kept in memory but that is why I write it to False at the beginning of the vi.

Even when I read the shared variable first before changing it with a False constant the second instance of the shared variable that is wired to the Case structure is reading True.
It seems to me that the shared variables do not follow the LabView 'law' of dependence and are updated outside of the normal flow of the vi.

 

Thanks for your time and advise on this.

0 Kudos
Message 1 of 10
(4,905 Views)

The many problems of shared variables.  Write to it and immediately read and you get a different result.  Why?  Because the value is not actually updated until it is published in the shared variable server.  And the data is not sent to the engine until either so much data is ready to be sent or a timeout happens.

 

So how to get around this?  Use a loop immediately after writing that just reads the shared variable and stops when the read value matches the written value.  Preferably, you should have some kind of wait inside of this loop and you might want to make it a FOR loop so that it does not run indefinately on you.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 10
(4,899 Views)

Thanks crossrulz for the fast response.

 

Good to have a better insight and a work around solution; still it seems rather cumbersome. I only have about 10 shared variables but already the code gets messy in trying to  avoid these querks. 

Anyone knows another way around this?

I forgot to mention in my initial post that I am running LV11. I have just tried it on another PC with LV2015 and this problem does not occur on that PC.

The infinite joy of 'discovery'  with LabView!

0 Kudos
Message 3 of 10
(4,880 Views)

To add to crossrulz' post:

If you have the DSC Module, you can set an initial value for network published shared variables.

 


@JackT wrote:

Thanks crossrulz for the fast response.

 

Good to have a better insight and a work around solution; still it seems rather cumbersome. I only have about 10 shared variables but already the code gets messy in trying to  avoid these querks. 

Anyone knows another way around this?

I forgot to mention in my initial post that I am running LV11. I have just tried it on another PC with LV2015 and this problem does not occur on that PC.

The infinite joy of 'discovery'  with LabView!


 

This is the way it's done (writing and polling until match), unfortunately. Without this initial loop, you're just allowing a race condition. If it works on your 2015 PC, maybe that PC is just faster.

If it's getting messy, use subVIs to encapsulate the initializing, reading, and writing for the variables.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


Message 4 of 10
(4,875 Views)

I also wonder if you need to use shared variables at all? Are both VIs running on the same PC or are they across a network? If they're on the same PC, are they seperate executables or not? There is probably a way you can modify your application architecture which means you don't need to use them at all!

 

What shared variables are good for is publishing data to multiple locations over the network where you can have multiple applications/targets reading the latest value of the data. I wouldn't use them for any sort of synchronisation (e.g. starting/stopping a process such as a DAQ task)


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 5 of 10
(4,856 Views)

Thanks James.Morris

 

Good to learn about the initial value. I was surprised not to find something like that from the start but it is because I do not have the DSC module installed.

I will look into that and implement the 'polling till match' if that is the accepted way to work with shared variables.

 

Out of interest I have the flush shared variables utility (the shared variables are network shared) in my vi but it does not seem to have any effect.

How do I best implement/use this? Is there a timeout  or buffe size to observe for this utility?

 

0 Kudos
Message 6 of 10
(4,854 Views)
Solution
Accepted by JackT

JackT wrote:

Anyone knows another way around this?


Yeah.  Don't use them.

 

If you are not publishing accross a network, just use a normal Global Variable or use a Queue, User Event, Notifer to send commands telling loops to update their values.

 

If going across a network, then I recommend Network Streams to send commands/data back and forth with the updates.  The more I have used shared variables, the more I hate them.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 10
(4,847 Views)

Hi Sam_Sharp

 

Thank you for your question and remarks. I am currently testing the vi's on the same PC but the aim is to communicate from the main vi to another vi (actually a build exe.) on an embedded PC that will be connected over a SHDSL network. The cable is about 1500m long with limited bandwidth so the idea is to send date from the embedded PC to the main vi on the surface as effciently as possible using the shared variables.

 

 

0 Kudos
Message 8 of 10
(4,844 Views)

Hi again crossrulz.

 

I have not come across Network Streams. I will look into that.

Too bad the shared variable are not that easy to work with as it seems like a great solution at first.

I have only used them for a few days and already feel there is too much uncertainty with them for stable code.

At one point I had a control that was linked to a shared variable changing even when the particular while loop that the control was in was not running....

As they don't seem to follow LV logic I find it hard to know what to expect with them.

0 Kudos
Message 9 of 10
(4,837 Views)

Yeah, it's it's just a 1-to-1 connection, use Network Streams as Crossrulz suggested or TCP/IP to transfer the data. With network streams you get a lossless connection so you won't lose any data and it's an efficient/fast way of doing it.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 10 of 10
(4,835 Views)