VI High 55: How to Implement an Error Handling Strategy in a State Machine - pt 2
As promised, we continue programming our state machine by adding error handling into each state and then testing the completed code.
Want to learn LabVIEW? We can help with Sixclear Lucid LabVIEW Fundamentals Training at http://sixclear.com/labviewtraining.
Welcome back to implementing error handling with our state machine. In our last episode we did these first three, now we’ll do the last. We’ll flip open our application and the first thing we need to do is actually use the error cluster between these VIs, because as we flip through and see these VIs they’re just kind of sitting by themselves out there but using the error cluster would be a smart thing to do. So let’s do that.
So what we can imagine are some error cluster rails kind of going right along here throughout the entire application, and it’s a good idea to have them use shift registers on either side since there are some states that handle errors and some that don’t, and it’s just good programming practice. So I’ll add a shift register here, obviously the shift register is black because it’s unassigned, it doesn’t yet know what it’s a shift register of. So I’ll wire the error cluster into the right side and it becomes the color of the error cluster. So I’ll initialize the error cluster by right clicking and creating a constant. Notice I can’t create that constant until the shift register knows that it contains error clusters. I can leave it like this or I can make it a little bit smaller by “view cluster as icon,” however you like, and then wire this into here. We know that we’ll be checking for errors in every state.
So how do we check for errors? Well we’ll want to look at the error cluster and then change the transition from where we normally go to the error shutdown case. There are a couple ways of doing this, let’s move this out and use a select function. It’s polymorphic so it can accept this error cluster coming in so if there is an error that has occurred here then there will be a true boolean in here which means whatever is in here will pass out. So first off the select function is still defaulting to doubles, so we’ll change that. Now I wired the idle value into the false input because that will be what we transition to if there’s no error. In other words: false for no error, in the case of an error: error shutdown. Whatever you want to do to make it pretty that’s ok with me. In summary if no error occurs a false will come in here and we do what we normally do. If an error has occured we go to the error shutdown case.
Now we’re going to be doing this for every state so I could go and copy and paste this little chunk of code over there but we’re better LabVIEW programmers than that. We know this is an excellent use case for a subVI and the thing that will change in every state is what comes in. So I’ll move this outside, highlight the rest of this and go to Edit»Create SubVI. Now this is definitely an error handler. We’ll clean up this block of code and we’ll save it as “Error Handler.” Now the convention for most error handlers is to actually have the error cluster in and out of both sides, so let’s do that. We can of course change the SubVI we just made with an error out, align these across the top, always like to make it look good, and we haven’t changed what’s in the error cluster so I can just do that and clean it up again. Well that’s a little better. Assign that error out and down here, just like that, move this down so it’s in line, that’s pretty, and of course change the icon, double click, select the old, delete it, make a border, error, in this case, just error. This will be different than the other one we made, the error shutdown, and close it. Now we would normally go and document all these inputs and outputs on the VI, but for time’s sake, we’ll skip it, which we’re all used to because that’s what we do when we run out of time on our projects, sigh. Let’s make this presentable now and head to the next VI.
Now in the idle state we’re not looking at errors or generating any new ones so I can just pass this right through here and move on to the basic test. In basic test we’ll pull this over here and pull out from our project the error handler and it’s pretty easy now, just wire up that error cluster and the states go in, and the states go out, reminding ourselves we’ll transition to the error shutdown if an error occurs. Move onto advanced test and we’ll do exactly the same thing, straight wires. Now we won’t need to put that error handler in here since this is our error shutdown case and we’re done. Let’s save it, ctrl-s, and let’s run and test it.
So as before we can run it, click on basic test, we do our basic test, on to advanced test, on to notify, back to idle. That’s very good no error there. We know that it passed the basic test because it’s passing a true out here. If we stop our VI, go to false, run it again and do basic test, then we go basic test to notify because we failed the test, ok that’s correct too. Now how do we test the error handling portion? Well, we need to inject an error. So let’s pretend that an error occurred in the basic test VI. So what should happen is we never go onto advanced test but rather right onto error shutdown. How do we inject an error here? Pretty easy, we’ll just put it in here. We’ll do something similar to what we did here. Let’s give it some space to work with, move this up, bundle by name and the status, which is what we’re looking at, will be true. Ok so now what should happen is we’ll go idle, basic test, and then onto error shutdown and the VI stops just as we designed it.
Well we’re finished for this episode but there’s still more we can talk about. In fact next time we’re going to look at creating a data pipeline between different states so that common data can be pulled out of there so that, for instance, the notify section can know what it’s notifying the user of, that’s helpful. By the way we do these courses live you know, we can come to your company or you can join us at a regional course. Just go to sixclear.com/regionals that’s just a location that we pick out and you show up and we talk LabVIEW for a week. Maybe I’ll be there, I’m much more palatable in person. See you soon, hopefully.