09-09-2018 12:27 AM
@billko wrote:
@crossrulz wrote:
@MogaRaghu wrote:
@billko wrote:
STOP RIGHT THERE. Don't use variables of any kind to shuttle data back and forth between anything in LabVIEW. Just don't.
OK will not.
Appears there is some other way to move the data around ...
Would you please let me know how else the data reaches where it is supposed to ?
Across a network? I just TCP/IP with the STM library. Another option is to use Network Streams. This creates a message based communication which I have found to be A LOT more reliable and faster than using Network Published Shared Variables.
Within an application? Well, that depends on a lot of factors. If you just want to know the latest value of something with no regard of when it was updated and only one place is updating it, then a simple Global Variable will do the job quite well. But for the other 99% of the situations, I use Queues and User Events to send messages and streamed data around.
I knew someone would bring up using globals in just that way - I use them a lot that way myself - but I don't really consider that "shuttling values back and forth". I rarely update a global after its first initialization because I use them mostly to hold values read in from some kind of configuration file. I like globals mainly from a development perspective because you don't have to go rooting around in all your subVIs trying to figure out where that constant you need to change is located. Plus, if a parameter changes, you only need to change the config file. If the config file isn't part of the software release, you don't have to release another software build.
On the other hand, using globals to bring in "live" values are a dangerous thing if you aren't very careful.
Yes thanks for the reminder on the Global's shortcomings. Till its convenience for a specific task as you described is understood, it will always be the cousin of the GoTo statement in C.
09-09-2018 12:37 AM
@Jeff.P.Bohrer
Action Engines …. Functional Globals ? Yes I used to be a big fan of them till in one project using 3 USB DAQ cards ( 6216 + 6001 + 6001 ) they refused to work the way they were supposed leaving the SubVIs starving for data. I am sure I goofed up somewhere in the coding but that also is unlikely as I have all FGs as Sub VIs which have been used in many projects. Anyway just tired of trying to solve the issue, switched to Queues which worked spot on in the same project.
As to reading hardware data in MAIN, I just create all required DAQMx tasks and Read / Write inside of a single while loop that is set to run at the required sampling rate … typically 20 to 50mS. Apart from the different buttons for the user to choose the required SUB VI ( via an Event structure) nothing else happens in Main.
Many such codes are running for years very stably.
09-10-2018 11:43 AM
@MogaRaghu wrote:Yes thanks for the reminder on the Global's shortcomings. Till its convenience for a specific task as you described is understood, it will always be the cousin of the GoTo statement in C.
Are Global Variables Truly Evil?