LV2 style globals with call-by-reference VIs

[Neil.Pate]

Thanks for your ideas Ben, I did have a look at the thread link you sent me, but am still unsure of one thing. Do I need a set method for every element of my cluster? Maybe phrasing this differently, is it a bad idea to have a single LV2 global for all my shared variables (with a single cluster holding all the values). If I do use a single LV2 with a single cluster, then I will need individiaul set functions for every element? So perhaps its better to not use a single LV2, but rather have multiple LV2s????

I wait with bated breath for your guru-like response

[Ben]

Hi Neil,

"So perhaps its better to not use a single LV2, but rather have multiple LV2s".

Short answer, Yes!

Super Cluster are a bad idea. Not only for the reason you mentioned but also becuase you;

1) introduce a single bottle-kneck.

2) duplicating the data produces extra dat copies.

When I design data structures for an application I "sorta" try to design a de-normalized database (see the normalization link in this link)

http://searchoracle.techtarget.com/sDefinition/0,,sid41_gci895554,00.html

In laymans terms (the only ones I have) I only put data elements together that are related. This allows parallel opeartions to take place without getting in each others way and keeps each action engine as simple as possible.

I am interested in learning how others approach this phase of the application architectures. Most of what I know about this work was learned by "growing up" in the IT world.

Anyone else have any insights they would like to share?

Ben

[SachaE]

Hi,

  just to add my 2 cents worth - action engines are a great way to encapsulate functionality and data storage, and if the data happens to all be realted, then there's nothing wrong in having a couple of inputs to the action engine (so one to say set / get / clear and another to say element one/two/three/all   etc) or having one longer enum with those specifics in.

Ultimately it's about efficiency of code and readability / maintainability. If you have lots of vi's which are performing the same kind of functionality, then you could bring them into one vi, and use enums and flags to say which item you're dealing with, so you've made an architecture that is functionality described, or you work by the actual object type (such as file or hardware interface etc) whereby you would have separate open's.
It's usually the latter that you want to use simply because that's how National Instruments has broken up their shipping vi's, and then all the code becomes a lot more readable.

So ultimately, if all your data is related, then just modify your action engine to allow for that, and if not, then separate the items out.

Just to add another option into the fray - you could also use a queue to store information.

Given the access times benchmark we quote on the LabVIEW Advanced course :
In LV 8.0 with a 3.2GHz Intel P4 HT enables, XP SP2, 1GB Ram on a read of 1MByte of data

Global 0.00027s
Single process shared variable 0.00053s
Functional Global 0.00175s
Single element queue 0.000281s

Whilst transferring 1MB of data isn't that common for static data (usually the state of something) you can see how the queue is quite fast, and also makes sure that the data is quite protected.

The obvious issue is that you have to preview the queue element each time so you don't remove it from the queue if you want to hold onto the information it contains, or read it out, and then write it back. Also, when you go to write it, make sure you clear it out first jsut to be 100% sure that you're not queueing up information somewhere.

Thanks

Sacha Emery
National Instruments (UK)

[Neil.Pate]

Thanks Sacha,

Queues (that word is horrible to spell!, I will call them Qs from now on!) seem very interesting as a data storage mechanism. I use them at the moment in my design pattern (producer/consumer state machine).

Regarding their implementation in replacing LV2s, I have a question: to share data using an LV2 its really easy I just place the LV2 VI on the block diagram where every it is needed, how is this achieved using Qs (specifically referring to VIs that are run using OpenFP/RunVI methods). Do I have to have a Reference control in my spawned VI and then use the SetControlValue method to pass the Q reference into it?

neil

[tst]

---

@nrp wrote:

Regarding their implementation in replacing LV2s, I have a question: to share data using an LV2 its really easy I just place the LV2 VI on the block diagram where every it is needed, how is this achieved using Qs (specifically referring to VIs that are run using OpenFP/RunVI methods). Do I have to have a Reference control in my spawned VI and then use the SetControlValue method to pass the Q reference into it?

---

You can give your queue a name. Then, using Obtain Queue with that name will create the queue the first time you call it and will return a reference to the obtained queue on every subsequent call. That way you don't have to pass the reference, but you can obtain it.
Note that the queue reference is only valid as long as the first VI calling it remains in memory, so if you're using dynamic calls make sure the first VI calling the queue remains in memory until the program is over.

[Neil.Pate]

That is truely excellent! I had not realised the power of the obtain Q function.

Gents, thanks for all your superb advice.