Hi Dave,
The only way to programmatically create a shared
variable in LabVIEW is to use an add-on module called the LabVIEW DSC
Module (Datalogging and Supervisory Control). This module greatly
enhances LabVIEW's ability to dynamically operate on network-published
data. It includes functionality for creating shared variables
dynamically, deploying them, as well as binding them to any number of
I/O servers such as FieldPoint devices and OPC Servers. Without the
LabVIEW DSC Module, you must statically create shared variables as you
edit your VI. And, when you create an executable, you can choose the 'Enhanced DSC Support Option'.
That being said, however, there are lots of
good options that you have simply using LabVIEW if you don't
necessarily want network-published data.
The first implementation I
would recommend would be to use a single-element Queue. A Queue is a
software FIFO (First In First Out) buffer that stores data. There are
four basic queue operations:
1. Obtain Queue: get a reference to a new or existing queue. Specify the name and datatype of the queue.
2. Enqueue Element: write a value to the queue.
3. Dequeue Element: take the oldest element out of the queue and output its data.
4. Release Queue: destroys the queue and releases the storage in memory.
The
idea here would be to use a single-element queue. If you are not
interested in buffering your data, but rather just having globally
shared data that you can create dynamically, then you only need one
element in the queue. You can access your data two ways: by passing
around an existing queue reference to dequeue or enqueue elements as
needed, or by calling ... Obtain Queue from anywhere in your program and specifying the name
of the queue to get a new reference to it. Refer to the example
attached below and the tutorial for more information on this option.
You can also search for the term queue in the Example Finder (from
LabVIEW: Help >> Find Examples) for general use cases.
The
next idea I would mention is to use a functional global to store your
data. A functional global is actually a VI like any other, but it uses
uninitialized shift registers on a while loop to store data. Generally
a functional global has a while loop set to run only once (so that we
can take advantage of the shift registers) and multiple cases that can
execute inside the loop. You could, for instance, have a Read case and
a Write case for accessing your data. You could also have any other
number of cases. The reason these are called functional globals is that
you can have other cases that not only return your stored data, but
operate on it as well. You could, for example, have a Return RMS case
that averages the data before returning it.
Generally,
functional global VIs are set to be non-reentrant, meaning that you
access the same instance of the VI no matter how many times it appears
on the block diagram. In your case, this wouldn't help, because you
want to programmatically instantiate global storage. This can be done
by dynamically calling the VI using VI Server multiple times and
passing those separate references around. You can then run these
separate instances to get or set data using the Call By Reference Node.
Again, refer to the tutorial linked below for more information and an
example of this.
These ideas should get you going. If you
want general advice on how to proceed, I would recommend the queue
method. If all you want to do is store data and not operate on it as
well, then the functional global method will add unneeded overhead and
complexity. In general, however, functional globals are fantastic means
of storing global data.
Here
is the link to the tutorial I've been talking about. Specifically,
refer to the section called Methods for Large Data Storage.
http://zone.ni.com/devzone/conceptd.nsf/webmain/6a56c174eaba7bbd86256e58005d9712
Please
let me know if you have any questions whatsoever about any of these
topics, or if you would like to discuss the LabVIEW DSC Module in
further detail. Thanks
and have a nice day!
