LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

variables without indicators and controls

Solved!
Go to solution
Highlighted

Okay...these are probably dumb questions, but I'm still learning Labview, so please be patient with me...

 

How do you recommend creating the cluster bundle? Bundling existing controls and indicators, or creating a cluster constant as a prototype?...or perhaps something else I haven't thought of...?

 

If bundling controls and indicators, how do you bundle an indicator? It seems fairly obvious to me how to bundle a control by name, but since an indicator is an input, you can't wire an indicator input to the input of a Bundle By Name function...

 

If you create a cluster constant, then the prototype has to be manually updated every time a new control, indicator or passed parameter is added to the program, correct? What if the control or indicator label changes...wouldn't that also have be changed in the cluster constant? Seems like changing this in two places may introduce human error, which brings us back around to the benefit of doing it this way...local variables stay linked to their associated control or indicator, and update automatically.

0 Kudos
Message 31 of 35
(354 Views)
Highlighted

@R.Gibson wrote:

Okay...these are probably dumb questions, but I'm still learning Labview, so please be patient with me...

 


 

How do you recommend creating the cluster bundle? Bundling existing controls and indicators, or creating a cluster constant as a prototype?...or perhaps something else I haven't thought of...?

 

Usually how I do it is quick and dirty.  I make a cluster constant, make constants from the terminals and put them in the cluster constant.  I then make a typedef out of the cluster constant... Which actually answers a few questions of yours below...

 


 

If bundling controls and indicators, how do you bundle an indicator? It seems fairly obvious to me how to bundle a control by name, but since an indicator is an input, you can't wire an indicator input to the input of a Bundle By Name function...

 

When you make a new control - in this case, I made a typedef'd cluster - it will become a control or an indicator, whichever was the first thing you put in there.  From then on, anything you put in there gets converted accordingly, so you never end up with a mixture of controls and indicators.  When you drop the cluster control onto the front panel, you can determine if it should be a control or indicator by setting it in the right-click menu.  More on the importance of a typedef below...

 


 

If you create a cluster constant, then the prototype has to be manually updated every time a new control, indicator or passed parameter is added to the program, correct? What if the control or indicator label changes...wouldn't that also have be changed in the cluster constant? Seems like changing this in two places may introduce human error, which brings us back around to the benefit of doing it this way...local variables stay linked to their associated control or indicator, and update automatically.

 

If you've made the control a typedef, like I did in the above example, all you do is add the new control to the typedef and all the instances of that typedef get update automatically.  I mean all instances.  Even instances in another VI.  Let's see your local variable perform that trick.  😉


 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 32 of 35
(338 Views)
Highlighted

Judging from the questions you are asking, I really think you can benefit from Unit 1 - Getting Started.  You've learned the practical side of LabVIEW but you don't really know - or understand why - "best practices" are really the best practices.

And if you are serious about implementing LabVIEW solutions on a large scale, that is only the tip of the iceberg.

 

One more thing.  You have to understand that you are relatively unformed in your LabVIEW practices, and people here really want to see you succeed!  Some of the responses may seem a little gruff, but it's really just a passion to see our forum friends be the best LabVIEW programmers they can be.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 33 of 35
(331 Views)
Highlighted

Great advice. Thanks! 🙂

0 Kudos
Message 34 of 35
(327 Views)
Highlighted

@billko wrote:

If you've made the control a typedef, like I did in the above example, all you do is add the new control to the typedef and all the instances of that typedef get update automatically.  I mean all instances.  Even instances in another VI.  Let's see your local variable perform that trick.  😉


Of course if the control/indicator that is being used as a variable is a typedef, and that same typedef is used in the other VI's, all instances WILL update automatically.


0 Kudos
Message 35 of 35
(299 Views)