09-14-2015 09:46 AM
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.
Solved! Go to Solution.
09-14-2015 09:53 AM
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.
09-14-2015 10:30 AM
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!
09-14-2015 10:31 AM - edited 09-14-2015 10:35 AM
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> ---'
09-14-2015 10:47 AM - edited 09-14-2015 10:48 AM
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)
09-14-2015 10:47 AM
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?
09-14-2015 10:49 AM
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.
09-14-2015 10:52 AM
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.
09-14-2015 11:00 AM
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.
09-14-2015 11:00 AM
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.