Multiple independent error "streams"? Good or bad idea?

[DoctorAutomatic]

I'm working on a project that involves running through a file with a list of commands/procedures that are to be performed on a "widget". The easiest way to imagine this is to imagine a non-linear manufacturing facility where raw blocks are the units to be operated on and they can go to various machines for various steps along the way to becoming the finished product.

So there's a main coordinator that will be handling when machines are available and sending the commands to move items to a machine and telling the machines to start their job and waiting for the machine drivers to notify when done/error/whatever.

In my mind there are two, maybe 3, levels of errors. Traditionally, I think of the error functions in labview as relating to Labview errors (problems with the software). In this project, it's quite possible to receive errors from a machine (say you tell the machine to run a program, like a CNC program, but lets the file isn't found). I would want that handled differently, likely logged differently, than a software error. For instance, I would not want lots of sections of code bypassed in this instance the way a lot of code is bypassed with error/no error case structures.

So would have two separate error "streams"? Should I use something other than the typical labviLa error cluster even though the cluster is adequate for the level of information that would be needed?

Am I thinking of this all wrong? Is there a better way to handle this on the same wires as software related errors?

[tobriant]

I don't see anything fundamentally wrong with running multiple error clusters if you would like to log them differently.

If you wanted to log any specific errors immediately, but wanted to continue programmatic flow instead of ending the VI upon encountering the error, you could unbundle the error cluster and make a case structure for that specific error and then log it to a .txt file.

If you're worried about LabVIEW not being able to properly handle the errors being thrown by different pieces of hardware, you could also write your own custom error codes.  This would imply that the standard LabVIEW error cluster would be enough to handle your use case.

I could definitely use a small sample of code to see what you're talking about just so I have an easier time visualizing this.

[RTSLVU]

Why not define your own error codes and messages and use the same error cluster? Then based on the error code you decide how to log them

[CFER_STS]

It sounds like your application is a good candidate for central error handling.  When I do this, I only use a single error wire through each loop, but at the end of the loop, I enqueue the error in a queue created for the purpose, and then clear it for the next iteration.  In the error handling loop, I dequeue any incoming errors, add them to an error array maintained in a shift register, remove duplicates, and order by priority.  Then you can ignore or act on specific errors as necessary.

Also, are you familiar with the Structured Error Handling Library?

https://forums.ni.com/t5/Reference-Design-Content/Structured-Error-Handler-SEH-Library/ta-p/3495302

[DoctorAutomatic]

Thanks to both of you. You both bring up things I hadn't considered. Now I have some more thinking to do.

I'm struggling on how to discern between errors that are bad enough that I'd want to completely halt all further processes versus certain circumstances where it should be nothing more than a warning and/or give the operator the option to retry/ignore.

[CFER_STS]

You filter by error code. In addition to all of the defined error codes built into LabVIEW functions, LabVIEW permits user error codes within the ranges -8999 to -8000, 5000 to 9999, and 500,000 to 599,999.  That should be plenty for anyone.

When I build an application, I might assign a block of codes to one particular process, such as 5100s for acquisition, 5200s for analysis, 5300s for logging to disk, etc. This is where the SEH library is useful, because you can assign an action (such as calling a VI) to a range of codes, instead of having to handle them individually.