LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Terminals REQUIRED vs. RECOMMENDED - Exceptions

Solved!
Go to solution

LV2018 SP1

 

My latest project has benefited greatly from the setting that INPUT TERMINALS DEFAULT TO REQUIRED (Options - Front Panel - General).

 

I have noticed, though, that the ERROR IN cluster is an exception to this rule.

Any ERROR IN cluster that I wire to a terminal always defaults to RECOMMENDED, not required.  I can change it if I want, but its default is different.

 

This is a property of the cluster arrangement itself.  It's NOT a typedef.  

If I create my own cluster and put a STATUS checkbox, CODE control, and SOURCE control in it, then my custom thing also defaults to RECOMMENDED, not REQUIRED.

If I add some other item, remove one item, or re-order those items, the cluster then defaults to REQUIRED when I connect it (it's recognized as different).

 

 

 

My question is: "Where is this determined?"  Can I change this behavior?

Or more specifically, "Can I create my own controls that will disobey the default? "

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 8
(2,780 Views)

Interesting observation. I also noticed that behavior and thought it was odd. I didn't go as far as your investigations though. It has been like that for as long as I can remember.

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
0 Kudos
Message 2 of 8
(2,775 Views)
Solution
Accepted by CoastalMaineBird

@CoastalMaineBird wrote:

If I create my own cluster and put a STATUS checkbox, CODE control, and SOURCE control in it, then my custom thing also defaults to RECOMMENDED, not REQUIRED.


The names are not even a requirement.  You just need a Boolean, I32, and String in a cluster in that order and LabVIEW assumes it is an error cluster.  And, yes, the error cluster is treated special in many ways (wire directly to Boolean functions, yellow wire color, always set to recommended on the connector pane, etc) by the IDE.  As far as I can tell, this is hardcoded in the C/C++/C# code.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 8
(2,768 Views)

@crossrulz wrote:

@CoastalMaineBird wrote:

If I create my own cluster and put a STATUS checkbox, CODE control, and SOURCE control in it, then my custom thing also defaults to RECOMMENDED, not REQUIRED.


The names are not even a requirement.  You just need a Boolean, I32, and String in a cluster in that order and LabVIEW assumes it is an error cluster.  And, yes, the error cluster is treated special in many ways (wire directly to Boolean functions, yellow wire color, always set to recommended on the connector pane, etc) by the IDE.  As far as I can tell, this is hardcoded in the C/C++/C# code.


It's not totally hard-coded!  Just add this to your INI file:

 

funkyerrclustWire=False

 

And you're back to the pink error wire!

0 Kudos
Message 4 of 8
(2,733 Views)

That's a very interesting observation about making your own clusters with the error cluster elements. I always default my input terminals to required, but I've never wanted to make the error cluster required. I suppose if you were only one ever going to work on the code then it might not be too bad, but it would be confusing for someone else because I can't think of any built-in LV functions that require the error cluster to be wired.

0 Kudos
Message 5 of 8
(2,727 Views)

@Gregory wrote:

That's a very interesting observation about making your own clusters with the error cluster elements. I always default my input terminals to required, but I've never wanted to make the error cluster required. I suppose if you were only one ever going to work on the code then it might not be too bad, but it would be confusing for someone else because I can't think of any built-in LV functions that require the error cluster to be wired.


Well, the "Merge errors" node requires it to be wired!

 

In all VIs that I make, there is one time that I do require "error in" terminals to be Required... Error handling VIs!.

 

I mean, it's pretty silly to have VIs named "log error" or "Custom error pop-up" on your block diagram that don't have error wires leading to them...

Message 6 of 8
(2,721 Views)

@Kyle97330 wrote:

 

I mean, it's pretty silly to have VIs named "log error" or "Custom error pop-up" on your block diagram that don't have error wires leading to them...


But they are the vast minority of VIs you would create with an error in cluster. About 99.999% of the VIs I create with an error in (which is almost any VI that I create) do not require the error in to be wired and shouldn't require it either. For the 0.001% that should have a required error in connector pane I'm totally fine with having to go into the connector pane configuration and making those terminals to be required! 

 

@Kyle97330 wrote:



It's not totally hard-coded!  Just add this to your INI file:

 

funkyerrclustWire=False

 

And you're back to the pink error wire!

That's entirely cosmetics about the color. The special handling of { Boolean, I32, String } Clusters for error handling such as being possible to be wired to boolean inputs or case selector terminals and several more, is deeply engrained in the LabVIEW code base and can't be disabled by any INI file setting. In hindsight it is unfortunate that they choose to assign this special meaning entirely based on the data format alone instead of introducing a special data type for the error wire. With a special data type they would be much more at liberty to eventually change the internal format of the error cluster to something much more powerful, even a class could have been imaginable! With the situation as it is now that option is basically prohibited forever as there is to much legacy code this change would break.

Rolf Kalbermatter
My Blog
Message 7 of 8
(2,700 Views)

@rolfk wrote:  In hindsight it is unfortunate that they choose to assign this special meaning entirely based on the data format alone instead of introducing a special data type for the error wire. With a special data type they would be much more at liberty to eventually change the internal format of the error cluster to something much more powerful, even a class could have been imaginable!

Luckily NXG has a LabVIEW Error data type (can't remember the exact name at the top of my head) and a suite of VIs specifically for interacting with it.  So NXG is primed to make the switch to OOP sometime in the future.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 8
(2,589 Views)