Change the Clear Error primative's icon to reduce block diagram clutter

[Mark_Yedinak]

I would be nice if the Clear Error primative was modified so that it's icon was not the full subVI size, but rather smaller which would help to keep the block diagram neat and clean.

[David S.]

I have to agree with peos here. In fact, I think the VI's existence just clutters up the palettes, due to that fact that it's nearly equivalent to not drawing the error wire there. (Yes, you still need flow control, but in most cases you have another wire to handle that for you. In Mark's example, that's the reference wire.) If it were my call, I'd have it deprecated instead of changed.

[RavensFan]

I disagree that it is the same as not drawing the error wire.  If there is an error in the first VI, but no wire coming out, then you'll probably have a dialog box pop up depending on how the error handling settings are set in your LabVIEW environment.  With the wire going to the clear error primitive, the error is being explicitly handled and told to ignore.

And where here you have the reference wire defining the order of exectuion for these two VI's, there are situations where you may have no other errors and would use the error wire to define execution order.

While I don't use clear error very often, it is a useful VI and don't think it should be removed or deprecated.

[David S.]

Ravens Fan, don't fret over my opinion; I'm not in LV R&D and ultimately won't have any say over what's done with this VI. 🙂 I'm just trying to contribute to the Idea Exchange because I'd like to see it succeed in the long term as a place to hold dialogue about LV's features with the people who make them.

That said, my contribution to the dialogue is the same: I believe the error wire's purpose is not to control the order of execution, and if you have your error handling configured correctly you don't need a "Clear Errors" VI. 🙂

[Mark_Yedinak]

But David, sometimes the only data you have available to impart a data dependency is the error wire. Therefore there will be times the error should be cleared. In addition, part of normal error handling you would need to clear errors. This can easy be done with a Clear Errors primitive instead of dropping Error Cluster constant on the block diagram. There is a need for this primitive but there certainly isn't a need for it to have a full size icon.

[David S.]

...sometimes the only data you have available to impart a data dependency is the error wire.

Allow me to introduce you to the Sequence Structure. I don't believe it's been formally deprecated from the language yet.

[Mark_Yedinak]

David, I'm surprised to see a NI employee who is resistant to using data (yes, the error out is data) to control execution order. There are many reasons why using sequence structures are not recommended and I am not a big fan of using single frame sequence structures to control flow. I do if it is the only option available but I think it is ridiculous to do so if you have an error out and an error in which can be used. It is asinine to say there should be no native construct in the language that will allow me to clear an error. The presence of a clear error is a very clear indication that I have handled the error and my choice is to ignore it. Leaving it unwired is not. Was it left unwired by mistake and it should be processed or did the programmer mean to ignore it. Code should easily and clearly convey the intentions of the programmer.

One last comment. I am also surprised at your extremely condescending response. Even more so coming from an NI employee. Given that I am both a CLA and a LabVIEW Champion I think I am fully aware of the sequence structure.

[David S.]

Mark, none of my responses are meant to be condescending, just ironic or humorous. I'm sorry if the text of my reply gave you reason to feel offended; as Kurt Vonnegut said, "A joke is like building a mousetrap from scratch. You have to work pretty hard to make the thing snap when it is supposed to snap."

As I said earlier, I'm not a member of LV R&D, just another LV power user with an opinion that I'd like to share. That said, you asserted that you're "not a big fan of using single frame sequence structures to control flow", but that's exactly what they're for. Unless there are technological reasons not to use a syntax that's defined in the language, then it just comes down to personal preference. In that case, we're allowed to simply disagree over this. 

[vitoi]

How about keeping the current icon, just modifying it slighly to fit in a half / two-thirds height?

[paul_a_cardinale]

Here's my version.

[Darren]

Additional terminals were added to Clear Errors.vi in LabVIEW 2014. It will remain 32x32 in size to accommodate these new terminals, and potentially more terminals in the future.