What do Error In and Error Out do for me and do I need them? I understand they can help control which code starts first, but I thought the DevRefs would take care of that.
I’m also concerned about the safety VIs, I don’t know how to use them, or even if I need to use them. I’m also clueless when in comes to the error-in and error-out functions.
So when you are writing LabVIEW code, you really want to make sure you don’t have race conditions. A race condition is where one piece of code ‘races’ with another to see which executes first. To prevent that, you can use the Error in/out. This way, it has to use an order and you know absolutely how things are going to run. It is also helpful to put an indicator somewhere connecting to an error out in case something is erroring out. It is just another debugging tool.
I haven’t used the safety VIs yet in my code, but they are used inside other of the WPI VIs
The primary use of error I/O is to declare what to do with errors. If a function can’t complete, or runs into an issue with hardware or parameters, the error out will describe the error.
Error In is used for chaining errors. Error chaining is the LV way of saying that code is to be skipped if there is an error. If a node gets an error and is chained to four blocks, the next four blocks see the error and typically skip over their operation. A common exception is that Close blocks will operate anyway.
If you are familiar with exception handling in other languages, the error chaining is the dataflow version of throwing an exception. The difference is that the exception is thrown forward instead of back. This cooperates with making sure wires always have values, and it allows for the exceptions handling code to be defined for each block.
The fact that error handling also happens to be useful for sequencing is an added benefit, but you may in fact want to clear out the error if you want some code to run even if an error was produced upstream.
Greg McKaskle