LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

no connection "required" for VI outputs?

I am by no means telling you that it's a bad idea. My biggest problem with required outputs, should someone set them that way, is the same as Steve's comment in the idea you linked to, and that is that it impacts trying to debug code while developing. I have been coding LabVIEW for a lot of years, and have written thousands of VIs, and I have yet to see a situation where I had to have an output to be required. Given that, I can't really get all that excited about the idea. However, I'm sure there are many who will support it, regardless of whether they are Knights or not.

 

In terms of the error clusters being mandatory, I'm not sure what you are referring to but if you're saying that I have to put error clusters on all my VIs then I would strongly disagree with this statement. Why does a utility function that's used to format numeric values to nice hex-formatted strings need to be saddled with error clusters? What possible use would they serve there? None, as far as I can see. Furthermore, it would force me to make a larger VI icon than what would really be necessary.

0 Kudos
Message 21 of 34
(809 Views)

Fair enough. Some people have found the need for this feature, but that might be for bad reasons (from someone else's point of view).

 

As far as error clusters, I was pushing the example to extremes. However, I was only referring to functions already having error clusters. I was not asking to put error clusters everywhere! And if this the function you are referring to:

 

ScreenHunter_002.jpg

 

I would agree that there is no obvious need for an error cluster in it. However, I don't see how adding an error cluster to it would require making the VI icon larger than it already is... 🙂

0 Kudos
Message 22 of 34
(796 Views)

I was actually referring to custom VIs where you make the icon smaller, like to fit the single input/output ones.

0 Kudos
Message 23 of 34
(789 Views)

@X. wrote:

Interesting... Is this just your interpretation of the broken wire or is it actually a message from the Error List? Anyhow, even if all the LV Knights would tell me mandatory outputs are a bad thing, I have encountered a few cases where it would have saved me a lot of debugging time. I would even go as far as to argue that Error clusters should be mandatory by default (that, for one, would force me to be a bit more systematic :-).


 

Re: LVOOP error

 

I don't have a machine up to grab a screen shot. The indication of an error is a broken run arrow and an error message. It is LV equivelent of a "dangling participle". Like I wrote earlier it is a unique use case that LV R&D never concidered as possible or useful.

 

Re: all of the kings hourse and all the kings men...

Knight of NI only signifies we have run the gauntlet of a long posting trail and have lived to post more.

 

Re Saved debugging time

You have me curious. What ws the situation that leads you to request this option? I must confess I have not been able to imagine a situation were a non-connected output was not trivial to find. Please help me get past the mental block of "is it plugged in?".

 

Curious,

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 24 of 34
(779 Views)

@Ben: I am confused: broken wire or broken run arrow?

 

The thread is beginning to be too long for me to even remember what I said or not in it. But the case I remember is when a VI outputs two identical data types (call these outputs A and B). Suppose that I connect A to some follow up VI input A and although I intended to connect output B to the follow up VI input B, in a jittery move, I inadvertently connect output A to input B. If the wires are laid out in a sufficiently obfuscating way, I will not SEE the problem, and the only way I will detect that there is one is when the results I am expecting are not what I get. Backtracking and figuring out that this is due to me feeding A to both A and B can take time. Having a warning letting me know that "hey, you got output B unconnected and you are probably going to mess up your downstream results by ignoring it" would be useful.

 

In the more general case of the error cluster, I could imagine, say, that a VI may output results in all cases, but they could be garbage in some cases. I would then want the user to check this first (this would be indicated in the error cluster) instead of proceeding with garbage in. Of  course I could design my VI such that when the results are garbage, I replace the output values by some code-breaking values (NaN, negative values for things that will throw the computation off if the value are negative, etc), but that's not elegant. I often encounter this situation when, after some experiment with a VI, I realize that there are pathological cases, and I add an output that informs me of these cases. I would want the code using this Vi to, if not break, send me a warning that there are instances of the Vi that have this new (important) output variable not connected in some diagrams (and thus probably resulting in bad results).

 

 

Message 25 of 34
(769 Views)

@X. wrote:

@Ben: I am confused: broken wire or broken run arrow?

 

...

 

 Having a warning letting me know that "hey, you got output B unconnected and you are probably going to mess up your downstream results by ignoring it" would be useful.

 

... 

 


 

Broken run arrow. No broken wire.

 

Thank you for explaining the situation driving your request. I can offer no work-around so I guess there is a valid use for this request.

 

Thank you!

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 26 of 34
(769 Views)

You're welcome. I guess I will promote this thread to a suggestion then...

 

BTW, another common use case is when using instruments (must be relevant to NI's core business somehow). You clearly want to check the result of attempting to initialize a DAQ task. Currently, the user can very well leave all error clusters disconnected (and in doing so will of course fail to gracefully abort tasks, etc). I am VERY surprised that NI doesn't feel the need to request users to connect all error clusters...

0 Kudos
Message 27 of 34
(765 Views)

@X. wrote:

You're welcome. I guess I will promote this thread to a suggestion then...

 

BTW, another common use case is when using instruments (must be relevant to NI's core business somehow). You clearly want to check the result of attempting to initialize a DAQ task. Currently, the user can very well leave all error clusters disconnected (and in doing so will of course fail to gracefully abort tasks, etc). I am VERY surprised that NI doesn't feel the need to request users to connect all error clusters...


 

Automatic error handling has that situation covered. In that case your suggested requirement to wire the output could acually act counter to Auto Error handling ... for despearte noobs.

 

Imagine if the error out was required. A noob drops the function wires inputs but still has an broken arrow since error out not wired. If the noob does not understand error handling they may resort to just wiring the error cluste to the edge of a seq structure just to fix the run arrow. Now that the error is wired to something it will no longer trigger the auto-error and the error would be the same as what you described but with no error dialog.

 

Just doing my sounding board thing,

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 28 of 34
(759 Views)

I see that as a seat belt kind of thing. Taking Supershuttles to and from the airport in the past, and either not fully awake or completely jet-lagged, I have sometimes inserted the buckle in the wrong slot making it totally inefficient. I could have sued the company for making this kind of error possible, but I mostly should have blamed myself for being stupid. If people want to connect mandatory outputs to dummy sequence structures, that's their right. But then they will not come to me and complain that their results are non sensical...

 

PS: in some cases the seat belts were not functioning, so I COULD have sued the company. But honestly I have better things to do.

0 Kudos
Message 29 of 34
(750 Views)

Imagine you are at the other end of the phone line when the noob calls in.

 

Would you rather be exaplining a pop-up message means or talking them through digging and probing.

 

The erro in you face approach is probably less costly to support.

 

Take care,

 

Ben

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