LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Methods to break down large VI so that it runs faster

At this point, obviously I've used the type def to run my state machine, and "mechanically" I know how to do it.  But conceptually, I'm not exactly sure what I did by creating a type def.  How is a type def cluster differant from a regular cluster?
0 Kudos
Message 31 of 68
(1,274 Views)
A typedef defines the cluster throughout the application.  When you want to add a new element to the cluster you add it to the typedef control.  Now any control, indicator, or constant that is associated with that typedef gets updated automatically.  Any control, indicator, or constant that is not associated with a typedef would break because now you are trying to match two different datatypes and you would be forced to go through the application finding each error and manually updating each instance of the control, indicator, or constant to add the new element.
Message 32 of 68
(1,271 Views)
So given RavensFan's post, it doesn't sound like I'd want a "Super Cluster"?
0 Kudos
Message 33 of 68
(1,262 Views)

 

That's the beauty of a type def, all instances refer to the same file/typedef, so update the typedef and all is good to go.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 34 of 68
(1,259 Views)

No, I'm not saying anything bad about a supercluster.  And as Jeff said, making it a typedef makes a supercluster more manageable.

 

Remember that clusters can contain other clusters.  And a cluster can contain an enum.  All of these things can be typedefs.  So a TD cluster, containing another TD cluster, which contains an TD enum.  Now you are starting to talking about a supercluster.  If you decide you need to add another item inside your enum, all you have to do is edit the typedefed .ctl file for that enum and add.  Now all instances of that enum, all instances of the cluster containing that enum, all instances of the cluster containing that cluster will all automatically be updated.

Message 35 of 68
(1,255 Views)

OK,

 

So the new VI is 1000 times improved over my starting point.  1000 might be an understatement.  FP is still a little laggy, although it probably isnt the FP, it's probably the operations inside.

 

Either way, before I post the code, with the hope of getting any last pointers from you guys, I need to go through my handy style guide checklist.  I'm still working on good habits, so I have documentation, "Required/Recommended/Optional" terminal choices, and default values.

 

After getting through the rest of it, it pains me to say I can not remember how to set default values to controls and booleans.  

 

I see plenty of threads asking how to make current values default during run, but I just want to set some basic values for all runs. Any help?

Message 36 of 68
(1,240 Views)

Type in the default value you want.  Right click on control and Make Current Value default.  Save the VI.

 

 

To do it for all controls in the VI at once, Edit menu, Make Current Values default.

 

Message 37 of 68
(1,237 Views)

To set default values for your front panel controls, do the following:

 

From the front panel, right-click on the control.

 

Choose "Data Operations".

 

Choose "Make current value default".

 

That should do it!

 

Oddly enough, I can't find a property node that allows you to do this programmatically (or an invoke node either, for that matter).  There seem to be property nodes for almost everything else, but not one that lets you set the default value of the control.

 

Maybe I'm missing it?

 

Anyway, that's how you do it from the front panel.

 

Ah, Ravens Fan beat me to it!

Message Edited by DianeS on 03-12-2010 03:49 PM
Message 38 of 68
(1,236 Views)

There is a VI method node for setting all of the values to default.

 

There is also a property node for individual controls for creating its default value, but it requires scripting.

 

Neither of these can be run while the VI is running, which means another VI has to do the work on the non-running VI.  (Note, I used This VI reference, but that was just to make sure the class of the property node was a VI.)

 

 

Neither of these would be convenient to use in normal LabVIEW program, so I would just to things manually from the front panel.  If you were writing VI's to create or modify other VI's, then these tools could come in handy.

Message Edited by Ravens Fan on 03-12-2010 05:07 PM
Message 39 of 68
(1,232 Views)
I knew about the method for setting all front panel controls to default, but obviously I didn't know about the one for individual controls.  Thanks!  That might come in handy for me some day...
Message 40 of 68
(1,227 Views)