I’m curious if anyone has implemented error clusters in their Labview projects beyond what comes with the FRC framework.
I deal with Industrial machine programming frequently, and want to implement an error and warning system similar to what we use.
For instance, on the driver station diagnostic window we see errors generated. I’d like to be able to add customized warnings and errors. For instance:
Shooter not up to speed in expected time
Velocity overshoot over expected limit
Excessive deviation from requested heading
I’ve spent some time reading about the implementation of error clusters in Labview, but the explanations leave a whole lot to be desired. For instance, they mention that after throwing a warning, all VI’s afterwards will not execute. Hardly what we want on a robot.
So, can anyone give a primer on how to implement error reporting using Error Clusters that can be applied to our robots?
The error cluster datatype is basically a fancier error code with a Boolean indicating if it is an error or not, an integer code to define the error, and a string to describe the source of the error. When an error occurs, the information is passed or sorta thrown forward to dependent code until some code clears it.
This works similar to try/catch, but the try block is defined not by a range of lines of code, but rather by the flow of the error I/O wire. Blocks that share the same error I/O are in the same try block. The catch happens when a the error chain breaks and is handled, displayed, or cleared. Unlike throwing an exception to the catch block, the error I/O is propagated via wire, allowing downstream blocks to produce appropriate outputs, shut things down, etc. In reality, there will sometimes be mini-catch sections that operate a bit of code and then the primary one that will finally clear it by not propagating it further. Also, the downstream code may not be linear, and the error may propagate to parallel branches each with its own handlers.
To add FRC specific error codes, there would ideally be an example showing how. And in fact, there may even need to be a few additional things added so that it is simple to extend the error codes. This is a good request. I’ll capture it and see if we can get to it.
In the meantime, the basics are that if you write a VI to control an arm, and an arm update cannot be carried out, it can return an error by setting the Boolean and set the code to something meaningful to you. You can also put any text you like into the source string. Provided downstream code doesn’t clear it, the error will show up in the Diagnostics. Let me know if you see otherwise or have other questions.
The online write-ups make it sound like if you set an error, the next VI that the error cluster enters doesn’t run at all.
If I’m clear, that’s not the case in the FRC framework as long as you pass the error out of your SubVI. Which makes this an ideal system to send warning and faults to the diagnostic window.
Am I reading most of the write-ups correctly that suggest you can add your own error code in a SubVI by using the:
Error Cluster From Error Code.vi
And it will show up in the diagnostic window the same way normal errors do?
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.
In most (or maybe all) of the WPI Robotics library VIs is a big case structure connected to the error input. The real code is in the false case (to execute if there isn’t an error being passed in). The true case is basically empty. This is what the online write-ups are describing.
Am I right in believing (I don’t have it in front of me) that error out is a global and we can write to it in multiple locations in a VI, say teleop?
I ask because if we don’t want to wire one VI to the next because it would stop execution, can we simply wire each VI error out to a copy of the error cluster?
Greg, what are the chances that user error codes will print to the driver station diagnostic window if added to the error cluster? None at all?