[Greg McKaskle]

The write-ups are actually correct. Most VIs have an error in and error out and it is the error in is generally used in this way.

Lets make a small program where you have VIs A, B, and C. A calls B and then C. If you wire the error between the output of A and input of B, and the output of B and input of C, you have "chained" the errors. Lets say that B produces an error each time it is called. So A executed normally and passes no-error to B. B executes but returns an error. That error is passed to C. Generally, C is not supposed to operate when an error is passed to it.

If you do not want the execution of C to be conditional on the error of B, don't wire the error from B to C. Or clear the error between B and C.

The use case for the error chaining is when you want to have code skipped when an error occurs.

For FRC, this could be used to make a servo update conditional on whether a sensor was read properly. It can be used to make a motor update conditional on whether the image processing succeeded.

There is another feature of errors. When an unwired error occurs, the editor for desktop can catch it and put up a dialog telling the developer about it. This can be turned off in the Properties dialog. For FRC, the equivalent is that the error is piped to the DS and shown in the Diagnostic/Messages.

The error cluster from error code can indeed be used to make the cluster. The part that may not work as well until we update it is registering the error codes with the DS back on the laptop. In the meantime, you can put anything you like in the string.

Greg McKaskle