LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Petru_Tarabuta

The Error Collector Node

Status: New

It would be useful if LabVIEW offered the option to use an Error Collector Node inside structures.

 

The Error Collector Node would collect or capture any/all unhandled errors that occurred inside the structure that the node is part of. If one or more unhandled errors occurred, the Error Collector Node would output the first error that occurred (in chronological error). If no errors occurred, the node would output "No Error".

 

The following annotated screenshot shows how the Error Collector Node would help reduce the number of error wire segments and of Merge Errors nodes.

Combined 1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

The following screenshot shows a second example. Notice that using the Error Collector Node would result in a significant reduction of block diagram items: 10 fewer wire segments and 1 fewer Merge Error Node. The reduction in block diagram items could be even larger if we consider that the other cases of the case structure (potentially dozens of cases) also benefit from the same Error Collector Node being placed on the border of the case structure.

Combined 2.png

 

 

 

 

 

 

 

 

 

 

 

 

The two screenshots above are examples created specifically for the purpose of posting this idea. The following screenshot is a real-world example (taken from production code) of a VI that could benefit from the Error Collector Node, which would remove the need for numerous error wire segments and Merge Error nodes.

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • The Error Collector Node was prototyped as a hexagonal output tunnel in the screenshots above. I would, of course, be happy if a different glyph or shape is chosen to represent this new type of tunnel.
  • Error Collector Node would essentially behave similarly to a localised Automatic Error Handling functionality. It would collect or capture any unhandled errors inside its area of responsibility (the structure), and would convert those errors back into "manually-handled" errors - i.e. errors than are passed downstream via an error wire.
  • The Error Collector Node would be useful especially in situations where many code branches execute in parallel as it eliminates the need for lots of Merge Error nodes.
  • The first two screenshots mention the words "approximately equivalent to". "Approximately" because, if multiple errors occur inside the structure, the Error Collector Node does not guarantee which of those errors are output in the same way that the Merge Errors node does. For example, in the first screenshot, if all three VIs (VI A, VI B, and VI C) experience an error, there is no guarantee as to which of those errors the Error Collector Node would output. The node would output the first error that occurred (in chronological order), so it would depend on which VI finished execution first. This could change from execution to execution, and from machine to machine. Whereas the right-hand-side version, which uses Merge Errors, would always output the error generated by VI A.
    • This would usually not be an issue in practice. If more determinism is needed, the programmer could, of course, fall back on manually wiring the errors to define an exact error behaviour.
  • It should be possible to add a maximum of one Error Collector Node to each structure: Flat Sequence Structures, Case Structures, For Loops, While Loops, etc.
  • It would be useful if the Error Collector Node could be used outside of structures (directly on the outermost region of a block diagram). Again, enforcing a maximum of one Error Collector Node per outer block diagram would make sense. The Error Collector Node would execute after all other block diagram nodes and structures (would be the last thing to execute). The output of the Error Collector node could then be fed directly to an "Error Out" block diagram terminal. This would remove the need to wire most error wires inside the VI, while ensuring that no error goes uncaptured.
  • If the Error Collector Node exist only as a structure output tunnel, and not as a stand-alone node outside of structures, then a better name for it might be the Error Collector Output Tunnel.
  • The behaviour of the Error Collector Node would be unaffected by Automatic Error Handling being enabled or disabled in that VI.
  • Using Error Collector Nodes would benefit programmers in the following ways:
    • Would reduce the amount of "click-work" that programmers currently need to do (the number of wire segments and Merge Error nodes that need to be created), while ensuring that all unhandled errors are captured.
    • Would reduce the amount of block diagram "clutter". This "clutter" is apparent in the third screenshot, which shows many criss-crossing error and DAQmx wires.
    • Would decrease the size on disk of VIs thanks to fewer block diagram items needing to be represented in the VI file. This would help towards making git repositories a little bit smaller, and loading VIs into memory a little bit quicker.
  • Informally, using Error Collector Nodes would sit in-between the strictness of manually wiring all error outputs, and the looseness of relying solely on Automatic Error Handling. The error handling gold-standard would remain manually wiring all error outputs, but using Error Collector Nodes might be "good enough" in many situations, if used judiciously.
4 Comments
raphschru
Active Participant

I think that would encourage beginners to produce more and more terrible code that does not follow simple principles like dataflow paradigm and code reuse.

 

About image 2:


Combined 2.png

 

 


Aside from the obvious race condition for who will report its error first, on the image on the left, the error inputs are not wired, which will not cause the same behavior as the image on the right. Most VIs do not execute in case of incoming error, so this is a reason to wire the error inputs/outputs explicitly.

 

About image 3:


1.png

 

 

 

 

 

 

 

 


If someone coded like this, I don't think adding a feature to save some error wiring would be beneficial. It is better to learn using basic structures like a For Loop, which would prevent having all this duplicate code.

 

Side note: Try previewing your messages before posting as they often contain lots of exceeding line breaks.

 

Regards,

Raphaël.

Petru_Tarabuta
Active Participant

"I think that would encourage beginners to produce more and more terrible code that does not follow simple principles like dataflow paradigm and code reuse." - I am all for following dataflow too. I am also for reducing the number of clicks we, as LabVIEW programmers, need to perform. This is towards the (lofty) goal of us - LabVIEW programmers - being as efficient as a text-based programmer from the point of view of writing and editing lots and lots of code quickly.

 

"Aside from the obvious race condition for who will report its error first" - The Error Collector Node would be useful in situation where you don't care exactly which error is reported first. In screenshot 2 the error could come from one of the "DAQmx Create Virtual Channel" VIs. Do we care exactly which VI created the error? Perhaps yes, perhaps no. What we mostly care about is whether an error occurred (which should be a rare occurrence) or not.

 

Sorry it I'm reading it the wrong way but your comment suggests I wasn't aware that a race condition exists. It should have been clear that I had thought about this point from the bullet point that begins like this: "The first two screenshots mention the words "approximately equivalent to". "Approximately" because, if multiple errors occur inside the structure, the Error Collector Node does not guarantee which of those errors are output in the same way that the Merge Errors node does..."

 

"Most VIs do not execute in case of incoming error, so this is a reason to wire the error inputs/outputs explicitly." - Fully agree. That's why manually wiring the error inputs and outputs will remain the gold-standard way of propagating and handling errors. The last bullet point expresses the same: "Using Error Collector Nodes would sit in-between the strictness of manually wiring all error outputs, and the looseness of relying solely on Automatic Error Handling."

 

"If someone coded like this, I don't think adding a feature to save some error wiring would be beneficial. It is better to learn using basic structures like a For Loop, which would prevent having all this duplicate code." - Haha. Sorry, but you sound patronising. The programmer who wrote that code was a proficient and experienced LabVIEW programmer. It is not seen in the screenshot, but at the top of the screen all the DAQmx virtual channel wires went into a Bundle By Name node that formed a typedef cluster. Each typedef cluster field name represented the informative name of a channel. IMO the code shown in that screenshot is more readable and more flexible (easier to change) than if using a for loop. Think of it from this perspective: If coding in a text language, each parallel branch of Get DAQmx Physical Channel.vi, DAQmx Create Virtual Channel.vi and bundling the output reference into a structure or object would have probably been done in a single line of code. The text function would then consist of 24 lines of code that initialise the 24 digital output lines. Simple, clear, more self-documenting than using a loop.

 

I agree that the diagram looks complicated and even slightly untidy. But IMO this is a consequence of LabVIEW making it necessary to criss-cross so many wires, rather than a consequence of bad design. In other words, I agree that LabVIEW sometimes pushes us into less self-documenting implementations (using for loops when it is not strictly needed) simply to create "pretty" diagrams, and to save ourselves the hassle of wiring interminable amounts of wires.

 

"Side note: Try previewing your messages before posting as they often contain lots of exceeding line breaks." - I always preview before I post. On my screen - Dell S2722QC 4K monitor set to 3840 x 2160 resolution and 150% scaling - the post is displayed with not a single excessive line break. The two screenshots below show how I see the post. However, I too noticed that on a different screen - a laptop screen specifically - the posts look different. I don't quite know how to fix this, and not sure whether a post can be made to "look good" on all screen sizes.

 

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.png

 

 

 

raphschru
Active Participant

"Sorry if I'm reading it the wrong way but your comment suggests I wasn't aware that a race condition exists."

I was aware you were aware of the race condition, I just felt that it had to be emphasized because your proposed idea do not encourage beginners being aware of these problematics and embracing the "gold-standard" as you call it.

 

"Sorry, but you sound patronising. The programmer who wrote that code was a proficient and experienced LabVIEW programmer..."

Sorry that was not my intention, but I maintain that tons of duplicated code is never a good solution. What if instead of 24 channels, you want 64? The following code may be more appropriate:

raphschru_2-1725355311100.png

But even then, maybe storing everything in a cluster is not the best choice...

 

"I always preview before I post. On my screen - Dell S2722QC 4K monitor set to 3840 x 2160 resolution and 150% scaling - the post is displayed with not a single excessive line break."

This is what I see on a 1920*1080 monitor with Chrome, at 100% zoom:

 

raphschru_3-1725356623586.png

 

raphschru_4-1725356657409.png

 

Actually all your recents posts about error handling containing at least one image look like this.

So I guess it's the NI forum that does not render spaces correctly then.

 

Regards,

Raphaël.

Petru_Tarabuta
Active Participant

Thanks for the detailed reply and screenshots.