Community Nugget 4/08/2007 Action Engines

[James_R]

Ben you say to avoid "superclusters"

how big is a supercluster?

what about an array of 15 clusters and each cluster can hold up to 13 fields? is that too big?

Message Edited by James R on 04-20-2007 09:14 AM

[Ben]

James asked

"

how big is a supercluster?

what about an array of 15 clusters and each cluster can hold up to 13 fields? is that too big?

"

Excellent questions!

I have to admit that what qualifies as a super cluster has and will change with time.

Lets start with an easy definition.

Prior to LV 8.0, the size of the type descriptor for all controls was limited to 64K bytes. If you went over that, the VI would break.

So the easy definition says anything over 32K is approaching super-cluster status.

Another way of lokking at it invloves the realtionships between the elements in the cluster. If the cluster components are NOT interelated and can be acted on without concern for the other members, you may want to break the fields up into seperate clusters.

These are my quick thought on this questions and I am interested in how others view this question.

Ben

Message Edited by Ben on 04-20-2007 09:34 AM

[AristosQueue (NI)]

> So the easy definition says anything over 32K
> is approaching super-cluster status.

Let's be very clear here... anything whose *type descriptor* was over 32K was approaching super-cluster status.

An array of a cluster of an int32 could have 100,000 elements. The size of the data would be well over 32K. But the type descriptor would be less than 100 bytes. When Ben talks about "super cluster" he's talking about the size of the cluster's type descriptor, as shown in his picture.

With LV8.0, this size limitation is largely obsolete.  Type descriptors are handled in an entirely different way in LV8.0 and further, specifically to remove this upper bound.

[Ben]

Thank you Aristos!

Yes,

"Let's be very clear here... anything whose *type descriptor* was over 32K was approaching super-cluster status."

Ben

[squidmixer]

Can anyone tell me why placing input controls only into the case that would use them would impact the performance of the FG/AE? I have been doing this instinctively when I added various cases other than read/write to my functional globals.  I'd like to know why it's wrong.

Thanks,

Kevin Pratt

[altenbach]

Kevin, the releveant discussion about terminal placement is in a different thread:

http://forums.ni.com/ni/board/message?board.id=170&message.id=191622

Maybe you should read it first, then post over there if there are remaining questions. 🙂

TIP: There are explanations from highly regarded NI insiders such as Darren and Greg McKaskle, so focus primarily on their answers. 🙂

[tst]

For some completeness, here's what Ben's example would look like using GOOP.

If you'll remember, Ben included the following image in reply 2:

He then offered this alternative:

The GOOP version of this would look like this:

As you can see, the code is relatively similar, but it has a few important differences:

• Instead of the actions, you get VIs, which has some advantages - you don't get a lot of code in a single VI,
  you don't get a long list of actions, you don't have to recompile all the VIs if you want to add an action, etc.
• Each VI has different inputs. These inputs can be required, which makes your code safer and more powerful.
• Instead of having to create separate actions for each bit, you can create a single VI for toggling and call it multiple times.
• If you want to create another pump, all you need to do is call the Create VI again, and you get a references to a new pump.

The key to making this work is simple:
The VIs share a cluster of data. When a VI wants to modify this cluster (like the toggle VI), it requests a lock.
As soon as the cluster is available it locks it and now it can modify it and unlock it, so that any other VI wanting to use it can do so.
This guarantees that all the functions work on the same data.

For example, this is what the toggle VI looks like:

There are several GOOP implementations available, mostly using the same basic concept with slightly different implementations.
They all have wizards for creating the basic VIs you need. In this case I used dqGOOP, but any of the others would work as well.

I'm sure that with the built-in LabVOOP, you can also do this in a similar fashion (although for parallel operation, you would need a wrapper),
but I don't work with 8.x, so this is what I'm showing.

Attached is the example shown in the example above

[Ben]

Thank you for this example Yair!

And in the event Stephan does not spot this update, let me also thank you in his behalf.

Ben

[Ben]

This thread on LAVA discusses sharing an Action Engine across projects in both the development and runtime environments. Potentially extendable to cross-plattform opeartion.

Ben

[StevenA]

Ben, thanks for such a great nugget. (older thread but quality does not tire)