LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 4/08/2007 Action Engines

Solved!
Go to solution
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

- James

Using LV 2012 on Windows 7 64 bit
Message 51 of 161
(10,736 Views)
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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 52 of 161
(10,723 Views)
> 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.
Message 53 of 161
(10,708 Views)
Thank you Aristos!
 
Yes,
 
"Let's be very clear here... anything whose *type descriptor* was over 32K was approaching super-cluster status."
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 54 of 161
(10,697 Views)

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

0 Kudos
Message 55 of 161
(10,243 Views)

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. 🙂

Message 56 of 161
(10,248 Views)

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


___________________
Try to take over the world!
Download All
Message 57 of 161
(9,917 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 58 of 161
(9,893 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 59 of 161
(9,492 Views)
Ben, thanks for such a great nugget. (older thread but quality does not tire) Smiley Happy
SteveA
CLD

-------------------------------------
FPGA/RT/PDA/TP/DSC
-------------------------------------
Message 60 of 161
(9,251 Views)