LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to know if a wire is connected to a control (in the case of subVI)?

Solved!
Go to solution
Highlighted

Hello,

 

I would know if it is possible to know if a wire (in the caller VI) is connected to the subVI control ,or not.

- There is any function to test a control to know if it is wired in the caller VI, or not ?

OR

- Do I test control defaults values and determine if a wire is connected ?

 

I hope my question is understandable 😃

 

Rob

Message 1 of 30
(3,447 Views)
Highlighted

Hi

I am not sure if this is of any help. But if click on a connector in the connector pane. You can specify some options. I often use the "is required" option for important input data. If a connector of this type is not wired. An error and a broken arrow will be the result. The VI will not run before the problem is corrected.

 

Message Edited by Coq rouge on 05-04-2009 10:51 AM


Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
0 Kudos
Message 2 of 30
(3,442 Views)
Highlighted

Thx,

 

Ok, I set my conector to "Optionnal" : there is a way to know if a wire is connected to a wire ( in the caller VI). The option required does'nt resolve the problem.

 

Any other ideas ?

 

 

Thanks

Rob

Message 3 of 30
(3,440 Views)
Highlighted

Rob,

 

I am not aware of any way to tell directly whether a control is wired when the VI is called.  If there is a value of the input which can never be generated by the caller, make that the default  value and check to see what value is on the terminal when the VI is called.  If default, then unwired.

 

Why do you need this capability?  Is the VI used in multiple places and the control wired in some but not others?

 

Lynn 

Message 4 of 30
(3,417 Views)
Highlighted

johnsold wrote:

Rob,

...

 

Why do you need this capability?  Is the VI used in multiple places and the control wired in some but not others?

 

Lynn 


Good Q Lynn!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 30
(3,409 Views)
Highlighted

I've needed to know this because in one of my VI's, the first time it is run there are certain values (Potentially different across runs).  Then after the first time I use the last values the user selected. 

 

I used the method of having an illegal default value and comparing the inputs to the defaults, as was suggested.

Message Edited by elset191 on 05-04-2009 08:59 AM
--
Tim Elsey
LabVIEW 2010, 2012
Certified LabVIEW Architect
Message 6 of 30
(3,404 Views)
Highlighted

Consider also the First Call? primitive connected to a case structure inside your VI.  This may be a more robust means of detecting what you want to know.

 

Lynn 

Message 7 of 30
(3,410 Views)
Highlighted

Hi Tim,

 

In the post mortem discusion of one of my Nugets Jim Kring offered a wonderful idea that I have since adopted. In that discussion we were dealing with the quesion of using "required" on all of out inputs but in the case of a an Action Engine where different inputs were required in different actions, there seemed to be a catch-22 in that we could not expect the use of of our AE to propvide all inputs for all actions.

 

Jim's suggestion was (as I understood it) to create a wrapper VI for each call to the AE. The Wrapper would be developed by the developer of teh AE since they knew what the AE needed in each action. The wrpaare would only have inputs for those values used by that particular action and it would provided constants for all of the required inputs of the AE.

 

This gives AE's a kind of LVOOP look and feel because the AE becomes a "core" method that is only accesable by memebers of the same library while all of the wrappers (one for each action) become public methods that in-turn call the AE the right way.

 

Using thios approach I never find myself wondering if an input was wired because I know it has to be wired.

 

Just trying to help,

 

Ben

Message Edited by Ben on 05-04-2009 09:17 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 30
(3,409 Views)
Highlighted
Ben, if you are going to that much trouble, you are better off using single-element queues than action engines.  This essentially eliminates the maintenance on the action engine and distributes it among the accessors/functions, where it is easier to handle and much more scalable.  It is more object-oriented, which is why I prefer it.  It is also faster and more efficient when it matters (large data sets).  I use action engines when I don't want to write a lot of accessor functions (e.g. an error stack/propagation mechanism).
This account is no longer active. Contact ShadesOfGray for current posts and information.
Message 9 of 30
(3,370 Views)
Highlighted

HI Dr Gray!

 

I am slowly moving that direction (changing old habits is like trying to turn a battleship) but when I read threads like Garys on LAVA I hold course and keep the wheel fixed.

 

I benchmark each code construct one by one to convince myself I am not lettting a non-optimal pattern into my collection.

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 10 of 30
(3,366 Views)