Multi instance of function global

[JeffOverton]

If you drop an Open VI Reference, hover your mouse over it, and press Ctrl-H (for context help) you'll get a popup window explaining where things go.  The Refnum constant goes into "type specifier VI Refnum" and option 8 is one of the choices for "options"

right now you have your type specifier wired to the VI Path, which is supposed to be the path to the specific VI you want to open

also preallocate memory is only an option in 8.5

and finally, in this specific instance, .vit and reentrancy are going to be almost identical.  that is ordinarily not the case, but this time is an exception.

Message Edited by JeffOverton on 06-06-2008 11:46 AM

[alex.]

I tried both vit and reentrancy, they work well. so far cannot tell the difference. Hope I am right that  "preallocate memory" is the default setting in 8.2.1 when reentrancy is anabled.

Now will start working on, only worry about the memory release and performance.

Thanks a lot

[DFGray]

I know I am coming to the party late, but I would recommend a single-element queue approach over the functional global in this situation.  Each instance allocates its own queue and reuses the same functions.

You can find examples of the single-element queue approach (and the dynamically allocated functional global approach) in the tutorial Managing Large Data Sets in LabVIEW.  The single-element queue approach typically outperforms the functional global, especially for larger data sets.  See Reference Objects in LabVIEW - LabVIEW 8.5 Update for some benchmarks and more examples.  Let us know if you need more help.

[alex.]

Hi DFGray, I am trying to get the meaning of the singel element of queue, but still not get its idea then. May you give a brief intro of how it works. Thanks.

[DFGray]

The single-element queue is a queue which was initialized so the maximum number of elements is one.  It is as close as LabVIEW gets to a data pointer.  The way it works is the following:

Initialization
The queue is initialized to have a maximum of one element.  The initialization should include loading a default set of data into the queue.  So after initialization, the queue has a single element containing a default set of data.

Read
To read a piece of data from the queue, dequeue the element, wire the data (or subset of it if it is an array or cluster - use the in place structure for best memory use, if you can) to your output, then enqueue the original data.  You must enqueue the original data or the queue will have no data.  While reading, no one else can access the queue because it will be empty.  You can use a preview queue to get around the multiple readers issue, but I have never found this necessary and it can easily lead to misuse.

Write
To write a piece of data, dequeue the element, overwrite all or a portion of it, and enqueue the changed element.  Once again, the data is protected from multiple read/writes because other users cannot dequeue something that is not there.  They will wait until the queue once again has data.

Cleanup
Use a force destroy on the queue when finalizing.  This will make all items still waiting on it to exit with an error and default data.  Typically, you will have no code waiting on the queue when you quit, but this is a failsafe to avoid a hang.

During reads and writes, avoid passing an error into the enqueue if the dequeue was successful.  This will cause a hang the next time some other portion of the code tries to read the queue, since there will be nothing there.  Typically, do not chain errors through the dequeue/enqueue, although you may want to combine them at the end of your VIs.

See the examples mentioned above for code samples.