#labview video

[vihigh-blog]

VI High 57 - How to Pass Data Between States in a LabVIEW State Machine - pt 2 

Last time we passed data between states with our data cluster. Now it's time to report the data using some simple string manipulation and dialog boxes. Next time we incorporate events!

Want to learn LabVIEW? We can help with Sixclear Lucid LabVIEW Fundamentals Training at http://sixclear.com/labviewtraining.

Follow us at all these fine destinations:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

(start transcription)

Ok we’re sharing the data between all states, so what, how do we use it? Well the first task we want to do is go to our notify section and notify the user of exactly what passed. So, in here, we have the data coming in, which of course is an instance of the type def, look at that glyph, so in the no error case we want to go do something, maybe just pop up a dialog box for the user telling them if something passed or failed. So let’s go ahead and unbundle this and I’ll pull out the “basic passed” and the “basic voltage.” Let’s keep it really easy and just send a message to the user. I’ll hold down ctrl, click and drag to create some space here because I’ll send a message to the user with my one-button dialog and we’ll make a message, a string message, create a constant off of this, detach it for now, “the basic test” and then we’ll concatenate on what happened with the select function, if it passed, we’ll make a copy of this click and drag with control, it it’s true, “passed,” we’ll want a space in there too, or “failed.” We’ll use our concatenate strings, another string “with a voltage of,” put some spaces in here so it renders correctly. Now of course the voltage coming out of here is a numeric but we’re reporting it as a string so we need to change that. There we go, number to fractional string, voltage comes in and out comes the value. Let’s test this little block of code. Look how easy LabVIEW will be to prototype and test, copy, ctrl-n for new VI, ctrl v, head to this and let’s say we have a voltage of 5.5, it passed, run it, the basic test passed with a voltage of 5.5, great! This may seem like a little too much data for us, so with our context help we can take a look at this and say that we probably just want a precision of 2, that’s better. Check the prototype, passes, that looks good we don’t need it anymore, we fixed it here and we wire that concatenate string into here just to notify the user. We could obviously go and do the same thing for the advanced test and clearly we can do far more than just send a dialog box. We can write to a file, a database, whatever, we’re just keeping it simple. 

So now the whole point is in another place, like the basic, test we actually go and fill that value. So in basic test “basic passed” will be false and “basic voltage” will be 2.6. So let’s go ahead and run it. Run it, basic test and we get “basic test failed with a voltage of 2.60,” great and back to idle. Now where else can we use this? Well clearly the advanced test we can fill in the same thing also in the error reporting. When it comes time to do the error it’s a good idea to maybe, in the error report, say what’s passed and failed and what the voltage values are to be able to do some troubleshooting after the system has shut down. 

Anything else we should know here? Well keep in mind that we made a type def of our states and of our data because now, if I ever go back and need to add more data that I need to pass between states I just put it in here. I don’t even have to change, in most cases, the coding because this pipeline now grows or shrinks with whatever I put in here and using the unbundle by name I can just take out the new items by name. So essential to use that type def in that data cluster. That’s all on state machines for now, remember this was one of your suggestions, we like those so keep them coming and keep coming back to sixclear.com/labview-training. Take our course online or come visit us at regional course or have us on site.

(end transcription)

[vihigh-blog]

VI High 56 - How to Pass Data Between States in a LabVIEW State Machine - pt 1 

We're almost finished with state machines, and this time we discuss how to pass data between states by making a type defined data cluster and using a shift register. We'll show how to notify the user of the test results as well.

Want to learn LabVIEW? We can help with Sixclear Lucid LabVIEW Fundamentals Training at http://sixclear.com/labviewtraining.

Follow us at all these fine destinations:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

(start transcription)

In our last episode we took a look at implementing error handling in our state machine and we asked a question at the end: if, for instance, I’m going to notify the user of whether a test passed, how does the notify VI know which test passed? It may be values for the test if the tests occur in other states. In other words, how do we get data between states? Within a state it’s pretty easy, we just pass the data to whatever handles it, but getting it from this state over to this state will require passing that data between loop iterations. Are your ears perking up? Because that’s what a shift register is for and that’s what we’re going to use. In this case let’s say I want to pass the data regarding the basic test from this state to the notify state. Well I’ll right click and create a shift register. Now what should I put in here? Well this “passed” is a boolean, so I could go and wire this boolean into here, but then what about the data for the advanced test? I can’t use the same shift register because that’ll be a different value so I’d have to create another one and then what if I also wanted the actual values for the test? Maybe some voltage values, maybe for both tests. Well now then I have four different shift registers sitting here and pulling them off, and as you can imagine as my application scales I’d have a bunch of these, that’s inconvenient. So what I really want is one shift register that holds all of those and so we’ll keep them in a cluster. We’ll go back here, get rid of this and instead the data is going to more closely reflect what’s in here. 

Now right here we’ve kept the data pretty simple: numeric and boolean and we haven’t even been terribly consistent about the labels, so let’s change that. What we really want is an instance of a type definition in all cases, so I’ll right click on the border and make this a type def, and open up the type def, save it, keep the same prefix and choose “data.” Let’s make this a little prettier, expand this a bit. Let’s say the pieces of data we want are this: four simple pieces, this voltage for each test and then whether that test passed or failed. So we’ll call this “basic voltage” and this “basic passed.” A line across the top and make a copy. Ctrl and shift, keeps them on the same axis and we say “advanced voltage” and “advanced passed,” save that and we’ll look at the order of the controls 0, 1, 2, 3, that looks good to me. So now this is an instance of the type def and it got a little bigger so we’ll move it over a bit here, rearrange some things. This also should be an instance of the type def. We don’t want to make a new one of course we’re just going to right click on it and replace it with the one we just made that way it’s still connected up, it’s still in the block diagram, much easier. Pull this over here, line these up quickly, same here, gorgeous. Wait, not yet gorgeous, now, okay. So I’ll close that out, this now is an instance of that type def and of course we want it going into here, there we go, and now this will be an instance of the type def too. So I can create a constant at the beginning of runtime in order to re-initialize the values in that cluster, very nice. I can even put a label here, it’s good programming practice, we’ll just change it to “data” and make it a little smaller, we don’t need to see all of it and now any other cases that need to access that, we’ll just pull it from there. 

Now I’ll obviously need to go to the “advanced” and do the same thing as I did before. I’d pretty it up but in the light of time, that’s good enough. In we go, and out and finally the notify state, same thing. Obviously we still have this hollow tunnel so we’ll have to decide what to do in the other cases like “initialize” and “idle.” Well in “idle” we won’t have to worry because we’re not changing that data or even hauling it anywhere so I’ll just pass it directly through. So it’s in “initialize” or “error shutdown.” Both of these use the un-type def data so I won’t make you sit through that, I’ll go ahead and change that right now. Okay all done, all of these now have the updated type defs. So I’ll wire them in and out in all cases. Solid tunnel here means we have all cases taken care of. 

(end transcription)

[vihigh-blog]

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.

Follow us at all these fine destinations: http://facebook.com/sixclear http://twitter.com/#!/sixclear http://gplus.to/Sixclear

(start transcription)

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.

(end transcription)

[vihigh-blog]

VI High 54 - How to Implement an Error Handling Strategy in a State Machine 

We left off our discussion of state machines with VI High 50. We pick it up with this episode when we discuss potential ways to implement an error handling strategy with our state machine. We'll continue this topic in VI High 55.

Want to learn LabVIEW? We can help with Sixclear Lucid LabVIEW Fundamentals Training at http://sixclear.com/labviewtraining.

Follow us at all these fine destinations: http://facebook.com/sixclear http://twitter.com/#!/sixclear http://gplus.to/Sixclear

(start transcription)

In VI High 49 and 50 we talked about state machines. In 49 we planned it out with the state transition diagram and then in 50 we implemented it. At the end we said we would discuss error handling. The question is: what happens if any of these states has an error. Well, in the previous implementation there was no error handling, that’s bad. In this situation though, we’re going to have every state transition to this error shutdown state. The error shutdown case will handle the error, whatever it is, and then shutdown the application. 

Now, this is one possible implementation, however in many cases, we already have a shutdown case, in which case it may look something like this, where, in the case of an error we move to the error handling state and then to the shutdown case, but if we don’t have an error we just move to the shutdown case and then end. Now we have a lot of red arrows going all over the place, so for simplicity we oftentimes just do this and anything here with the red background automatically forwards to the error handler in the case that they have an error. However, we don’t have a separate shutdown case. It’s a pretty simple application and so we’ll just stick with this one. 

So what’s our path forward? Well, we’ll first ensure that all VIs in the application handle errors then we’ll add the error shutdown case to the Enum then make the error shutdown case in the state machine and then fix the other cases to transition to it with an error handler. So let’s do that. 

We’ll open up again our LabVIEW project containing the state machine and I got rid of that main that we created in VI High 50, don’t need it right now because this is the same. We stopped here so the first thing we’ll do is ensure all VIs handle errors. Well, we’ll go under the hood to the VIs and this is where we left it last time but appropriate error handling strategy, that we learned about in VI High 48, is to wrap any code in a case structure with the error cluster going to the case selector terminal. So we’ll do that, pull down a case selector terminal and wire the error cluster into it and through to the other side, flip over to the error case and just complete wiring the tunnels. Now in the no-error case we perform the test. In the error case we don’t and the state machine will go and decide what to do. 

Now, it’s important to note that failing a test is not an error because the application is designed to determine whether a device under test passes or fails. So it’s doing what it should do. An error would be if the application itself fails, maybe communication with the instrumentation fails or the user requests the application to do something that it can’t do. So those are errors, and we’ll jump out of here and see the other cases with the other VIs already have that implemented. 

So we’ve ensured our VIs handle the errors, now we’ll add to the Enum. That’s done simply enough by going to any instance of the type def, right clicking and opening it up, and we want to add an error shutdown case, and I’ll just add it here at the bottom. I’ll expand this a bit so I can see it, right click and add an item after: “error shutdown.” Save and close it and now all instances of the type def will have that error shutdown as well. Huge help using that type def. We always want to make sure that the Enum, going to our state machine, creates a type def or else we’d have to go and add that item to every instance of the type def, what a pain! 

So now we’ll make our error shutdown case, and we’ll just put it here after notify. I’ll right click, add case after, and the case structure will automatically assign the next case to the unassigned item in the type def enum. What’s going in this case? In keeping with the pattern I’ve already started, I’ll just have a VI that does the error shutdown. It will look a lot like some of the other VIs in here, probably a lot like advanced test notify. So I’ll pull that open, take advanced test, and make a copy of it, and change it to error shutdown, open it up, and we’ll want to make sure that this is in the project, so I’ll just pull it over here and we’ll definitely want to change the icon as well, so I’ll just open up the icon editor, and this is our error shutdown. We’ll actually have another VI later that does the error handling between cases. So we’ll just look for a glyph that’s “shutdown,” ok these are good, we’ll get rid of the old one, select it, delete key, and click and drag this on there. Ok, save that and close it and put this in here. We will fill in the blanks here -- or the hollow tunnels -- and we’ll end on this case since that’s what our state transition diagram tells us to do right here. So we’ll make this true and here it doesn’t really matter what we do here because we are going to end our application so we’ll just leave it at error shutdown. Of course, we need to supply an input to the tunnel so the VI can run and looking at the guts here of our error shutdown VI we’ll have some stuff in here that does that but it probably won’t reside in the no error case but in the error case or since it’s supposed to execute in an error and only in an error we can even get rid of this if we want, it’s up to us. For now, we’ll leave it as it is and then finally fix the other cases to transition with an error handler and this is a big part so we’ll do this next episode. In the meantime remember to checkout Sixclear.com for all your LabVIEW training needs.

(end transcription) 

[vihigh-blog]

VI High 50 - How to Implement a State Machine in LabVIEW

Last episode we were heavy in theory and looked at a demo, this time we're actually programming the state machine, complete with a type defined enum for the states.

You can also keep up with us at:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

Experience level: Basic

(start transcription)

Hey, I’ve been waiting for you. Ok, let’s get started.

In our last episode, we saw how the state machine addressed our simple lab test application and we showed the completed code. Now, let’s go ahead and build it. For simplicity’s sake, I’m going to keep it in the same LabVIEW project, so that I can use all these subVIs and just make a new main level VI.

Head to the block diagram, and let’s build the infrastructure for the state machine. As we said in the last episode, we’ll want a while loop with a case structure inside, a shift register, and we also want an enum constant, which is found in our numeric palette: Enum Constant.

I’m going to right click on it, and I’m going to make this a type def. Avery good idea to always make a type def of the enum constant controlling the states of our state machine. So I just go to Make Type Def, like that. Right click, open the type def, and I’ll save it as ‘states type def’. And I’ll right click and edit the items in here. So I’ll write the states here. Enter between each one, and then hit ‘OK’. And I can drop them down and see the five states that I created. Save the type def, close it, and now this little glyph in the upper left indicates that it’s a type def. And the tip strip also tells me that. Very handy. Thanks LabVIEW.

So wire this into the shift register, and from the shift register, into the case selection terminal of the case structure. And the first two cases have been assigned: Init and Idle. So we’ll first go to our Init state, which is our default, and from here, I’ll go my project and I’ll just pull out the Initialize subVI. And then I want to make a copy of my enum, which contains my states, and wire that to the right shift register. And choose the next state, which in this case is Idle.

We also want to have that status on the front panel, which I’ve done nothing with so far, so let’s put that down. A string indicator. ‘Status’. And we want our two Booleans, one of which is an OK button, which we’ll rename to ‘Basic Test’. Double click on the Boolean text and write the same thing. And then we want a stop button. Now both of these I can remove the labels, and I’m gonna make one of them bigger, and then highlight them both, and make them the same width and height, and align them across the top, and smash them together. Move them over like that. There we go. That is a beautiful user interface.

Head back to my block diagram. Take ‘Status’ outside of the case structure but still inside the while loop so each case can update the status. Get a string constant and write Init in here. Wire it to the status. We’ll go to our next state: Idle.

In Idle, we’re seeing if the user clicked on the Basic Test and the stop button. So the stop button we can just wire out to the case selector terminal. Okay. And we can also, on our hollow tunnel, right click and use the default if I’m wired because the default in all cases will be ‘False’, which means it won’t stop the loop because the Idle case is the only state where we’re actually checking to see if the user has clicked the stop button. So that works well.

A case structure, and in it, or rather inside of it, not to be confusing, if it’s Basic Test, True, we go to Advanced Test. If, on the other hand, it’s False, we just stay in the Idle state. ‘Idle’. On to our next state.

Add a case after, and we have our Basic Test. Let’s grab our Basic Test subVI, and we used the data coming out of here with an Unbundle by Name to get whether that test is passed. And we use a select function. Incidentally, I could have used a select function here as well. Two ways of doing that.

Make another copy of the enum. Wire it in here. If the test passes, we go onto Advanced Test. And I just realized I made a little error. This should be Basic Test. Thanks for catching that, Brian. There we go.

Advanced Test, if the test passes. If the test fails, we notify the user. Cue the tunnel, move this whole thing down because we like straight wires. ‘Basic Test’. And finally, add the last case, Advanced Test, grab the Advanced Test subVI, and we don’t actually take the data out of this one. We just perform it and then always go to the Notify. ‘Advanced Test’.

Back to Notify, or to Notify, and we make our final case. And once we’ve notified, we go back to the Idle state. We also want to include some timing in here. How fast are we moving between states? Now, there’s a few ways we can do this, but we’re doing this really simply, so I’m just going to use a Wait Function and say it takes one second per state. Now there are better ways to do this: employing execution timing and software control timing, which we can talk about later. But for now, we have our five cases, which are states, and we’ll go run it.

I run it, and we first go to the Initialize state, and on to Idle, where we’re waiting. I click on Basic Test, we go to Basic Test, then back to Notify, which means the test fails. Now how do I know that? Well, obviously we had a False here, to come out of Notify, but if I go into Basic Test, we’ll see that it’s actually really simple, nothing much on the block diagram, and the data out is a pass to False. So that will always come out as False passing the test.

Now, it’s a good idea to test the functionality of a pass as well, so that’s pretty easy. I can just go to this block diagram of Basic Test and use a Bundle by Name. Go to the Boolean, which is whether it’s passed, and write a ‘True’. Okay.

Now let’s run it, Basic Test, on to Advanced Test, and back to Notify, and back to Idle. Perfect. Now we’ve gone over a lot here, from the infrastructure of a state machine, to programming this particular lab test application. But there’s a lot we didn’t go over, like the Notify state, what we’ll notify the user of. If both tests pass, if one test fails and the other passed, how does it know that?

Well, we can take a look at that in future episodes when we take a look at error handling, and passing the data between states. So come on back next time, and also, check out our full LabVIEW course, of which this is an excerpt, at sixclear.com/labview-training.

(end transcription)

[vihigh-blog]

VI High 49 - How to Use State Programming and State Machines in LabVIEW

Last time around we asked for ideas on our next series. A bunch of folks signalled louder than Gilligan's Island castaways during a flyby: State Machines. We're glad to drop relief bundles of wisdom on state vs. sequential programming, state transition diagrams, and state machine infrastructure.

You can also keep up with us at:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

Experience level: Basic

(start transcription)

Hey, I’ve been waiting for you. Ok, let’s get started.

Last time around we asked for ideas on our next series. A bunch of folks signalled louder than Gilligan's Island castaways during a flyby: State Machines. We're glad to drop relief bundles of wisdom on state vs. sequential programming, state transition diagrams, and state machine infrastructure.When we ended our File I/O and API Error Handling section, we asked, “what do you want to hear about next?” And you said ‘State Machines’. So here we go.

Now suppose we want to perform a couple of lab tests: a basic test, an advanced test, and then notify the user. How can we program this? Well, it could look like this, where we have four separate subVIs connected by the error clusters, and data being passed between subVIs. We can generalize these steps into states. By definition, ‘A state is a unique configuration of information in a program; it generally performs a test or satisfies a condition’.

Now, we could program this application sequentially, but then we would always need to go in the same order. But what if we wanted to change the order on the fly during runtime? Or stop the code at any time instead of waiting until the end? Or repeat the same step multiple times? Or execute some code only if a certain condition is met? Now, these are difficult or impossible to do with sequential programming, but all really easy with state programming.

We start state programming with a state transition diagram, or state diagram. It represents states and transitions between them. By definition, a transition is a condition that is satisfied when moving between states. Let’s take a look here at that lab test application.

We start here, and we go to the ‘Initialize’ state, and then moving on to the ‘Idle’ state. In the ‘Idle’ state, we’re waiting on the user to do something. The user has two options: either click on ‘Basic Test’ or ‘Stop’. If ‘Basic Test’ is clicked, we go and perform ‘Basic Test’. If that test passes, we go on to the ‘Advanced Test’. But if the test fails, we go to ‘Notify’. If we go onto ‘Advanced Test’, then we’ll always go to ‘Notify’ when we’re finished, and then we always go back to ‘Idle’. And the user can then either click on ‘Basic Test’ again or click the ‘Stop’ button and stop the application.

We always begin in this design phase, and then we go and implement in LabVIEW code with the state machine. So let’s look at it.

I’ll hit the ‘Run’ button, and we see we’ve gone from ‘Initialize’ to ‘Idle’, and if I click on ‘Basic Test’, we move to the ‘Basic Test’, and then ‘Notify’, because it looks like the ‘Basic Test’ failed. Let’s see how this is implemented on the block diagram.

Here’s the infrastructure of a state machine. We have a while loop, with a case structure inside, a shift register with the output of the shift register going to the case selector terminal of the case structure, and we also have this, which is an enum constant.

So to begin with, we initialize the first state of the state machine. In this case, ‘Initialize’. ‘Initialize’ passes in here, and we choose the initialized state, where we are executing the code for ‘Initialize’. When we’re finished, the state machine tells us where we’ll go next: in this case: ‘Idle’. ‘Idle’ will go out of this case to the right shift register; we iterate the loop; and the next iteration, it comes out of the left shift register, and the enum chooses the next state, which is ‘Idle’.

In ‘Idle’, as we see, we’re polling the ‘Basic Test’ Boolean and the ‘Stop’ Boolean. Now in both cases, you see we’re also updating the status on the front panel, so the user knows what state we’re in. Just with a string, ‘Idle’ or ‘Initialize’.

Now, if the user in the ‘Idle’ state does not click on the ‘Basic Test’ button, then we stay in the ‘Idle’ state. ‘Idle’ goes out to the right shift register; iterate, comes out the left; we stay here, and check again. We’re also polling that ‘Stop’ button to see if it’s been pressed. If, on the other hand, the user clicks on the ‘Basic Test’ button, we go to ‘Basic Test’. Goes into the right shift register; comes out the left; and we call the ‘Basic Test’ subVI. As we saw in our state transition diagram, in ‘Basic Test’, we’re checking to see if the test has passed: pass or fail.

So, coming from ‘Basic Test’ will be data here indicating whether the test has passed or not. If the test passed, ‘Advanced Test’ passes out of our select function and chooses the next state. If we fail, we go to ‘Notify, just as we see in our state transition diagram. Pass: go to ‘Advanced Test’. Fail: go to ‘Notify’.

Going to ‘Advanced Test’, we see we just perform that test and always go to ‘Notify’. In the ‘Notify’, we just call the ‘Notify’ subVI. And back to ‘Idle’, where we wait on our user to tell us what to do next.

That’s our overview of state machines, and this particular lab test application addressed with a state machine. Next time, we’re going to actually build the state machine to do this. And just to note, this state machine section is taken right out of our Lucid LabVIEW Fundamentals 1 course; right at the end, in application programming.

To find out more about the course, go to sixclear.com/labview-training.

(end transcription)

[vihigh-blog]

VI High 48 - How to Use the Error Cluster to Control Execution Order and Dataflow in LabVIEW

This is final episode in our error handling series. We talk about using the error cluster, not only to handle errors, but also to control execution order on the calling VI. If you have suggestions on new topics, just contact us!

You can also keep up with us at:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

Experience level: Basic

(start transcription)

Hey, I’ve been waiting for you. Ok, let’s get started.

Last episode, we looked at making an error handler by conditionally executing code based on an error and then making a subVI out of that. Here it is. And we contrasted that with the default action of most native LabVIEW VIs and functions which is to only execute their code in the case of ‘No Error’. And I also said that in a lot of cases, we may want to execute code regardless of an error. So, in this case, if I wanted to change this ‘Compare Two Paths’ to a VI that executed regardless of an error, it’s pretty simple. I can just right-click and ‘Remove the Case Structure’. I’ll delete the stuff in the error case, since there’s nothing really in there, and there we go. But we still like to keep the error cluster going through because we can use it to control the program flow on the calling VI, which is the File IO.

Now, of course, I’m not going to save this, the changes I made. I’ll delete it from here, so I don’t forget that. But if we have an ‘error in’ and ‘error out’ on the VI, regardless of if we use it under the hood, it’s still very valuable to control the data flow. Now what do I mean? Well, you can go back to VI High 9 and 10 for a full discussion on error flow, but in brief review, a node is any block diagram object connected by wires that performs an operation when called by LabVIEW and a node executes when data at all inputs is received, and data is supplied at outputs when the node finishes execution.

Now, that’s valuable because any VI or function that has the error cluster as an input won’t execute until it receives the error cluster from the previously executing VI. Which means that the execution order of this chain of functions occurs because each function is waiting on the inputs from the previously executed function. And even if we didn’t have the file reference to share between these, the error cluster still acts as an excellent way of deciding which goes first.

And that’s especially valuable between different sets of functions which don’t share other types of inputs. These functions obviously share the file reference, but what if I wanted to open up a file, and then also go and do some DAQmx programming? Well, no problem. I can make sure that the DAQmx programming starts after the File IO programming by just using the same error cluster. There we go.

The error cluster is the grand unifying input and output for most VIs and functions. So across APIs, modules, toolkits, and drivers that you use, the error cluster can be used to control that execution order. Even if we don’t use it under the hood to actually handle errors. So bottom line, whenever you see the error cluster available, link it up. You can almost never go wrong.

That completes our discussion on error handling. Hope you liked it. We’ll start something new. Want to suggest something? Go ahead and just comment on any episode, or subscribe to us and send us a message. We’d love to hear from you. Thanks!

(end transcription)

[vihigh-blog]

VI High 47 - Learn How to Create Error Handlers and Implement Error Handling in LabVIEW

In this episode, we see how to conditionally execute code based on an error. We do it in a single VI, but then also make a subVI of the new code and create an error handler. We see how native LabVIEW VIs and functions handle errors under the hood, and then chat about best practices for error handling.

You can also keep up with us at:

http://facebook.com/sixclear

http://twitter.com/#!/sixclear

http://gplus.to/Sixclear

Experience level: Basic

(start transcription) In our last episode, we looked at the error handler. And also what happens when a standard LabVIEW VI or function sees an incoming error. It just passes it along while not executing its default action. Today, we’ll use that error cluster to gain even more control over our application. Let’s say I want to do this. If an error occurred, I want a big LED to go off on the front panel alerting me to the error. So I’ll grab an LED; let’s make it square. I’ll make it bigger, go to the properties, and change my color. ‘On’ will be bright red. ‘Off’ will be a muted kind of red. There we go.

Now, here’s my terminal. How do I make it go off in the case of an error? Well, an error cluster is a cluster first of all, so we can always unbundle the contents of a cluster. I’ll go to my Cluster, Class, and Variant palette and pull out Unbundle By Name. I’ll just put it over here and wire the error cluster into the Unbundle By Name. I get out the status. I can also access the code or source, but status is what I want. It’s the green Boolean. Yes or no an error has occurred. So I’ll just wire that in there. So, let’s try it.

I’ll run it. Yes, the error occurred. Let’s double check and put a zero in here, so that there’s no error. Run it. Indeed, no error occurs. Okay. Let’s go a step further. Let’s say I want a custom dialog box to pop up whenever an error has occurred. How would I do that? Well, a custom dialog box is found over here. Maybe this One Button Dialog; that’ll work. So how do I get this to execute in the case of an error? Well, I’ll probably need a case structure. So let’s collapse this down a bit, get it all in one screen.

And I can get rid of this Boolean, and I’ll need a message. There we go. Appropriate gravitas. So I’ll pull this guy over here, and if I want him to run in the case of an error, you’ve got it. Just a case structure. And wire the status right into here. Let’s try it. Once again, I’m going to run it without an error. No dialog box. With the error, -2. There’s the dialog box.

We can go a step further here and just use the polymorphic nature of our case structure and not even have to unbundle this. I can delete this, wire this right into the case selector terminal, and look what happens. I get two cases: ‘No Error’ and ‘Error’. Now, you see that LabVIEW actually took the default case as ‘No Error’, but I want this to pop up in the case of an ‘Error’, so I can right click on it: “Make This Case Error”. There we go. Straighten that wire out a bit, and that’ll behave the same way.

Now, we did something very simple, just this dialog box, but you can imagine, I can now put anything in here. Maybe I need to flip a relay to turn something off in the case of an error. I’ll just put it in there. Maybe I’m originally communicating with a certain port on my computer, and I get an error saying that it’s in use. In here could be the code to change that port and try something new. In essence, we’re branching off from our default operation and doing something different in the case of an error. Now, what if I were to go and make just a SubVI of this, so that this code executes whenever an error has occurred in a variety of situations, maybe not just right here.

Well, a quick and easy way to make this a subVI, click and drag to select all of this, then go to ‘Edit’, ‘Create SubVI’. And there we go. There’s our new SubVI. I open it up. The error cluster of course is assigned, and on the block diagram, there’s our code. Does this work just as well? Sure does.

And now, I can go and take this SubVI and use it wherever I want. So what I’ve just created is an error handler. The code in here will execute in the case of an error, but only in the case of an error. That’s what we want. I mentioned earlier, though, that native LabVIEW VIs and functions don’t execute their default action whenever they see an incoming error, which is of course the opposite of what’s happening here. So let’s actually take a look at a default LabVIEW VI and see what’s happening under the hood. We don’t have to look far. We can go back to our Advanced File Functions palette, and I’ll grab this Compare Two Paths VI. So I’ll double-click, open up its front panel, and go to its block diagram. Let’s take a look.

The very first thing that happens when this VI executes is it looks at the incoming error cluster from the previously executed VI. If no error has occurred, as we see here, we execute everything this VI does, which is Compare Two Paths. But if it sees an incoming error, then it flips over to the error case, and, in essence, nothing occurs. Now, of course this VI executes, but it doesn’t execute its default action. It just passes that error along to the error out, so that the next VI that’s called in the chain will see that error as well. Now, this is a good practice for when we’re building our own VIs. If we’re going to make a subVI of it, and it should only execute in the case of no incoming error, we just wrap the entire code with a case structure and wire in the error cluster and out the other side. But in the case of an error handler, which should execute only in the case of an error, then we want our code in the error case.

And there may be some other VIs that execute their code regardless of an error, in which case on their block diagram, we may not see this case structure at all. But we would typically still see an ‘error in’ and ‘error out’ control data flow on the calling VI. What do I mean by that? Well, we’ll talk about that next time.

So subscribe to us on YouTube, and you’ll know exactly when that’s posted. See you then!

(end transcription)