Action Engine with Queue instead of USR

[jon_mcbee]

I have been reading this community nugget on action engines and was wondering if there is a reason for using uninitialized shift registers over queues?  This may just be my lack of understanding but it seems like you could create a FIFO buffer with queues that acts very much like an action engine.  If what I am saying doesnt make sense I would like to know because it will probably help me to understand AE's better.

Cheers!

[altenbach]

LabVIEW privides a very rich environment and there are always several similarly good ways to do things.

The advantage of an AE is the fact that it can have arbitrary functionality and do much more than just communicate data across structure- and VI boundaries. It would be simpistic to call an AE as basically a glorified 'FIFO buffer with queues".

Do you have an example on what you have in mind? 😉

[Gabi1]

well you could use a queue as an Ae, but even better: you can use a queue in an AE

the AE is not only a place to save data, but to treat it as well. imagine you try to make an analog ramp. as input data, you can have a cluster that give you the slope, initial and final value. in the next time you call the AE, instead of getting all the info, you might just need the actual analog value at the specific moment you call it.

so the AE, will use its stored parameters, and figure the value you need at this moment.
you can do even better, as the stored parameters can be changed at every iteration! no way you can do that with a queue.

disclaimer: you can have a queue, take the last element, and restore to last element, assuming no other vi is playing with your queue. but that is a high risk. you could also do it with a notifier that store your data, retrieve it, treat it, and reinsert it into your notifer. sorry, this is soooo unelegant!

[Ben]

Look at Aristos Queues post from 4-12-2007 for the example you are asking for.

I have not tried using queues yet but one reason that I would go with the USR's would be performance getting at parts of what is stored.

Example:

AE stores all values read from DAQ susb-system.

Clients of AE are only interested small subset of all readings.

By using USR I can index out of the USR.

If the USR was a Queue, I have to de-Q index and re-Q so that data was available for the next client of the AE.

I probably could avoid that issue by using one queue for each DAQ channel, but I have to admit, I have never tried that.

Ben

[jon_mcbee]

Thank you all for your replies.  My main reason for asking the question was to gain a better understanding of Action Engines, and possibly queues and shift registers as well.  I was initially thinking of using a queue in an action engine to replace a USR, if for no other reason than to see if I understood what was going on.  I dont have any code to back me up as I havent implemented anything.  I was also interested to see if there was an advantage or disadvantage performance wise to using a queue over a USR? Thank you again for all the replies!

Cheers

[Ben]

Under the right circumstance, the queue could outperform the USR because it can pass pointers (by reference) to data rather the data itself.

Ben

[Jarrod_S.]

Ben is onto one of the main potential advantages for using queues instead of USRs in an AE. It's not a one-size-fits-all deal by any means, but here it is:

If you use a queue in your AE to store your data rather than an USR, then you can pass the data stored in the queue out of the AE in-place (meaning, without making a copy). This allows you to operate on the data outside the AE without making a copy by checking it out (dequeuing in the AE) and then checking it back in (enqueuing in the AE).

Now, the valid point to make here is that allowing that usually defeats the purpose of an AE. Usually you want most all the actions for the data to be performed internally inside the AE. This allows you to control what happens to the data, and to serialize access to it.

Allowing users to check out the data and do whatever to it can have some problems associated with it, but you still maintain the serialization that regular AEs have, because only one instance of the data can be checked out at a time.

Personally, I have used single-element queues in AEs before. One instance was where I wanted to store named-data in a central repository, where I had operations such as Check Out, Check In, Add and Delete. The AE used an USR for a variant to store the data elements by name using variant properties. But if I just stored the data flat in the variant properties, then I would have had to make copies of it when I checked the data out to modify it. Instead, I store queue refererences in the variant properties, and act on those.

That's a big mix of different technologies, but the end result is an in-place method of achieving serialized access to named data stored in a global repository.

[jon_mcbee]

Thank you very much for the info Jarrod S.,  and all other posters.  I see how the advantage to using a queue can defeat the purpose of the AE.  I think I have a better understanding of AE's now.

Cheers

[Gabi1]

i miss something: one main purposes of my USR, is the protection of my data. one has to make a copy for utilisation outside.
with the queue, i can too easily have access to this data, change it and bring it back without my AE to know about it. how do you protect that? (hum... i already see applications where that might actually be very useful...)

very interresting. Thank you Jarrod!

[Ben]

I'd put the code that modifies your data inside the case for that action if at all possible.

Like...

De-Q

Process

Re-Q

Return to caller.

That way nothing can step on the data form an other thread.

Ben