VI High 58: How to Make Your State Machine Event-Based

We’ve been focusing a lot on state machines over the last few episodes, but we followed a polling scheme. This episode, learn how to make the state machine event-driven.

Need some LabVIEW training? Swing by http://sixclear.com/labviewtraining and check out Sixclear Lucid LabVIEW Fundamentals Training.

And keep up with us here:

http://facebook.com/sixclear

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

http://gplus.to/Sixclear

(start transcription)

Now, some of you may have already asked, “Brian, what are you doing using a polling structure when you should be using an event-driven structure?” I know. I get it. Don’t worry. Don’t worry. We’re discussing it now.

This application is very simple. Really, we have two buttons. Basic Test and Stop. And when the state machine goes to the state, that’s where it takes the data and only there. So this application will be better served with an event structure in the idle case rather than this polling scheme. And we’ll implement that event structure in a second, but first we should ask, “Is it always wrong? Should we never use a polling scheme like this?” And the answer is there are definite cases where the polling scheme does work. The classic reason is that you have data coming in at a constant stream, so you need to poll data. So, perhaps you’re connected to an instrument, like an oscilloscope or some network that’s constantly giving you data. And you need to go at a certain pace in order to get data from that. So, maybe I’m going 100 times a second and pulling data off of an oscilloscope. And then I pipe that into the data pipeline and take care of it in other cases. In that case, since I’m already polling over and over again in a loop, it would make sense to go ahead and poll these simple buttons as well. However, in this case, I don’t. All the data is actually being taken in the cases here and here. So, let’s fix it and improve it as well.

Right now, we only go to basic test and stop. But let’s say that I also want the option of going to advance test. Pretty simple. I’ll make a copy of this, and I’ll call it “Advanced Test.” Of course, that’s just the Boolean text, I need to go to the label, too. Ok. We’ll align these to the left and smash them together. Very pleasing. So now, I’ll get rid of this case structure. Don’t need it. And instead, I’ll put down an event structure. And configure the first event, which will be the basic test. A value change is good. Ok. Put the basic test terminal in here since it’s a latch action Boolean. We always want to have those in the event structure. And, of course, we’ll go to the basic test.

Now, we can take advantage of what we just did and right-click and duplicate this event case. In so doing, it creates an extra basic test, but we’ll delete that. And instead, I’ll choose advanced test. Get rid of this. Choose advanced test and bring this terminal in here. And the last, which we won’t duplicate, will be stop. Because remember, our user can stop it from right here. In which case, we won’t actually go to the next state, so I don’t have to put anything here. Now, do we need this? Well, that depends. Do I need that for the other cases? In other words, do I need to wait for 10 milliseconds between these cases? Typically no, so I’ll get rid of it.

Now there’s one other thing we need to take care of. It’s a little tricky, and we haven’t had to deal with it before because all of our cases executed so quickly. The initialize in both the tests happen very quickly. But the problem stems from the fact that the status is being updated at the end of this case. So, when we initialize, for instance, we say initialize and tell the users that status really after we’ve initialized. But because it happened so quickly, we get away with it. However, once we move to an event-driven scheme, we’re going to see in our idle case that we’ll move to the idle case, but we won’t execute it. We’ll just wait here. So, the status will be whatever the last case executed. And really that’s the case with all of them. Status doesn’t say basic test until basic test is actually finished. Now, we’ve kept it quick and simple so far, so we haven’t really had to deal with it. But we should take a look now at a few ways of doing that. A clean and professional way would be to have multiple loops. So, one loop would handle our tests. Another loop would handle our user interface. Once we go down that road, we should ask ourselves how many other loops we should have. And that would lead us to a producer-consumer or queued-message handler type of architecture. So, we may not want to do that. Not that they’re very difficult, but they are the next step up in complexity. What we really want is to have this status be updated at the beginning of the case for all cases. The quick and simple way of doing it is just to make a local variable of it. A property node would also work if we’re going to be editing some other properties. But if we’re just editing the value, it’s not recommended because it requires a thread swap.

Let’s fix it. In my idle case, I’ll right-click and create a local variable of that status. And to ensure that it runs before this does, I’ll need to create some space first. And then move this here. Now floating this over here to the left of this does not ensure that it will go first. So, we’ll need some dataflow to make sure that this definitely goes first. A sequence frame will work. There we go. Now, that fixes that case. We’d have to do that for every other case as well: copy and paste that over. So, of course, ears pricking up, we should use a SubVI. But what am I making a SubVI of? Well, it should just be this really. And if I make a SubVI, I wouldn’t have to use this janky flat sequence structure. I could instead, put error clusters and pop it right on this error wire. So, let’s do that instead.

Right-click. Remove that sequence and just click once on the border. Edit. Create SubVI. And there we go. Go into the SubVI, we see that under the hood, we are using a property node. So what I said earlier about the thread swap still does apply. So, it’s up to you. In most cases if we’re not calling these property nodes a lot, this is ok. In other words, not calling them repeatedly in the loop over and over, so that we generate a lot of thread swaps. This, however, totally permissible. We said that we wanted those error clusters, so let’s put those in. Assign those and change our icon. You’re getting pretty good at this by now. And what we’re really doing is handling the UI, the user interface. So we’ll just say “UI,” and we’ll jump over to glyphs. An image of the front panel is actually pretty useful. So, I’ll just grab that. Ok. And save it as UI Handler. And put it on the error wire. Oops. It looks like I actually have an error in instead of an error out. Easily changed. We just right-click and change to an indicator. Now the complexity could grow because we’re using the user interface in each case. And we could also stand to use it at the beginning and in other places as well, but you get the idea. This is a valid use case of it. A very simple one, but this could also address a lot of other things on our user interface. For now, we’ll keep it simple. And to go put this somewhere else, I’ll just do one of the other cases, maybe the initialize. And we’ll go pull it out of here. And we’ll want that same reference that we had last time, so let’s just go grab it. We’ll leave a copy out there because we’ll use it again. Eventually we’ll go and change that in all cases and I can just pull the status really anywhere because it doesn’t need to be here anymore. So, I’ll just get rid of this, and I’ll go fix any other cases like I did here. You don’t have to watch.

All right. All fixed up. We can see that in every case, we’re updating the status. So, let’s go ahead and run it. Back to the front panel, hit the basic test, and remember the last episode we had programmed the basic test to fail with the voltage of 2.6. That sounds good, and we’ll jump back to the idle state. What about advanced? Well, look at this. The basic test failed with a voltage of 2.6. That clearly can’t be right. What went wrong? Well, going back to our idle state, this is the place where we go after all of our tests are done. Basic test, advanced test, notify, back to idle. Here we should be clearing out any past data. So, let’s do that. Clear out past data which is carried right here. So, let’s just delete that and make a fresh copy of it over here. Create a constant. We’ll make it a little smaller. View it as an icon. Let’s check that again. Ok. Advanced test. It says failed with a voltage of 0. Now, that’s right because we haven’t actually put anything into the data in our advanced test. So with the default being a false, the test failed.

Stopping it goes back. Just double check and put in a value for the advanced test. We’ll say it passed with a value of 10.1 and wire this out. Save and close it. Now remember that we need to go back to our notify SubVI, and I haven’t handled any reporting here for the advanced, but it’s a bit complicated because the advanced test is conditional. It only executes if the basic test passes and then now in our event structure implementation, it can execute without the basic test, so all that logic would have to be programmed in here, which we won’t do right now. Instead, we’ll just go ahead and test this. The advanced test will just say that it fails with a 0 since there’s no real reporting. So basic test, we get the notification. Advanced test, we get the notification as well. Again, it says basic test because we haven’t programmed the notify VI. And stop works. Ok. That does it for state machines. You can probably imagine me making some shameless plug for our online and in person training. So, if you’re thinking of that, we’ve done our job.

(end transcription)

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)

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)

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)

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) 

VI High turned 3 today! Thanks to everyone for 3 years of LabVIEW lovin’!

VI High turned 3 today! Thanks to everyone for 3 years of LabVIEW lovin’!

VI High 53: Automatically Selecting NI Software for Installers in LabVIEW 2013 

We do LabVIEW training. When going over installers, we’re always asked “why doesn’t LabVIEW just automatically add the necessary drivers for whatever the code does?” Get ready to smile, now it does.

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 LabVIEW 2013 installers have changed for the better. Let’s take a look at this very simple Acquire and Analyze vi. We’re doing a simple hardware timed DAQ operation and doing some analysis on it, obviously the DAQmx driver is being used. Now I built this into a project and already created an executable from it. Now when it’s time for me to build the installer, previously I would walk through my categories over here on the left, put the executable in the folder I want and then proceeding down the categories I may choose a few other things and I come to the Additional Installers tab. Now previously, before LabVIEW 2013, I’d need to look at all the potential drivers and runtime engines that could be included in my installer and I’d have to know under the hood what my application is relying on, so that when it gets on this target computer it doesn’t break. 

Now we teach LabVIEW and people always ask “well why doesn’t the LabVIEW just know that?” Well, now it does. As you can see there’s a checkbox Automatically Select Recommended Installers and we see what’s been selected is the NI LabVIEW runtime engine 2013 and NI DAQmx Core Runtime 9.8. Now since my application is using DAQmx that totally makes sense. If I were using some other type of driver maybe NI-VISA it would be automatically included here as well. Now if I’d like I can uncheck that and go as before and choose what I’d like to include but this, far easier. 

Now you could justifiably ask, should I always just keep Automatically Select Recommended Installers checked? And the answer is, possibly, but remember that if you do bundle in together these runtime engines and drivers that your installer gets bigger. So if you know that your target computer — where the executable will be running — already has these runtime engines or drivers on it, then you wouldn’t need to go and put them together in the installer, but if you don’t know that, be safe and put them in there.

(end transcription)

VI High 52: Bookmarks and Attaching Comments in LabVIEW 2013

Now we can attach comments to block diagram objects, as well as hashtag bookmarks so we can keep track of places in our code we want to come back to. Come take a look!

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 LabVIEW 2013 there are some truly stellar new features involving commenting on the block diagram. Now let’s take a look at this event inspector VI we were just working with and let’s say I want to put a comment on this Register for Events node. Well I can just say here “register events” and if I hover near it, I see that to the lower right there’s an arrow. So I can click and drag and then select an object now to which this is linked. So if I move this guy around or move this around, of course it still points to that, and if I block diagram clean up everything we’re still pointing to that, very handy. I’ll undo that a couple times.

Also new in LabVIEW 2013 is bookmarking on the block diagram. So for instance I’m a LabVIEW developer so a lot of times I’ll be working all day developing LabVIEW, being really happy and then at the end of the day I’ll notice a bunch of things that I still need to do and I’ll close out for the day but I don’t want to forget those things. So this new feature in LabVIEW allows me to bookmark these things to come back to them. So for instance maybe I have a bookmark called “fix this.” As you can see the hashtag in front automatically prompts LabVIEW to bold this and then maybe after the bookmark I type what it is: “timing on 2nd loop.” Now I can leave it like that or of course I can attach it to the loop, that’s always handy. Maybe I also want to bookmark this entire structure: right click»visible items»subdiagram label in the same bookmark: “fix this.” Now why is that handy? Well now I can go to view»bookmark manager and I can see all the bookmarks that show up under “fix this” and where they are. So I can double click and it will take me precisely to that place so I can do whatever I need to do. Maybe I’m doing code review with someone else and I can have a hashtag saying “review this.” Plenty of options available with the bookmark manager. 

(end transcription)

VI High 51: Event Inspector Window, Flushing Event Queue, & User Event Priority in LabVIEW 2013

LabVIEW 2013 came out a little while ago and there are some pleasing improvements to event handling, come take a look at them!

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 LabVIEW 2013, there are some eventful updates to the event structure. One big thing that’s been added, and simple to look at, is the new mouse wheel event. So for instance, in this numeric control, if I were to click inside and move my mouse wheel, I can increment it or decrement as the case may be. Now in LabVIEW 2013 I can generate an event off of that. So as you see over here, there is a mouse wheel event off a numeric control under the mouse section, what’s happening? So each time I go and change the value of that numeric control with the mouse wheel I’ll change this LED: “wheeling.” It’ll be on and off basically looking at whatever the previous value was. 

What else is new in Events? Well a big thing is the Event Inspector Window. If I right click on the border, select Event Inspector Window, I pull up this window where first I can see unhandled events in the event queue and then all events that have already been executed. So let’s go ahead and run this, but first let’s take a look at the events we will generate. There’s that mouse wheel event, also a Mouse Enter on the milliseconds to wait control right here. So any time I pass my mouse over this that will generate an event, changing the value of the stop button, and then also there’s a user event. Now the user event, as you can see, has been configured, it’s been created here and then registered to this event structure, and that’s going to this other loop which is just going to be running continuously once a second, and once a second it will be generating this user event. This input, the priority, we’ll talk about a little later. 

Now of course there are more robust architectures than this, but this is more illustrative or illustrative, either one is true. So let’s pop open our Event Inspector Window and run this. So I run it, and nothing’s happening right now because the user event isn’t actually being triggered until I click on the Check Threshold boolean. So it’s not running yet, but let’s generate some other events. Again, passing my mouse over this will generate and as you can see that’s showing up down in the event log. Clicking inside my numeric control and then moving my mouse wheel will of course generate an event and I can see that wheeling LED turning on and off. You notice that we have a wait which is not typical with an event structure but we put it in there in order to slow down the loop so we can see unhandled events. So let’s do that. I will increase the milliseconds to wait to 1000 and now as I’m generating events you can see that some of them show up here in the unhandled events, because the loop is going kind of slowly and not catching up, and it works its way through the backlog, if there is one. Now I’ll stop it for a second, and to better view the results of this demo I’m going to turn off Front Panel Locking, and you can see a checkbox just below that which says “limit maximum instances of this event in the event queue,” and I can limit that to one instance. Well, that can be very handy because if we flip back now to our Event Inspector Window and then run this and queue up a bunch of events you see that each time that loop iterates it gets rid of all the extra ones. Now I pushed the stop button in the meantime but I restarted it. And flushing the event queue can be very handy especially for tracking events which happen continuously like mouses moving around, maybe we’re drawing something and we don’t really care what the mouse has done, we care what the last value is so we can go and take that and do some calculations on it. And there’s actually a new LabVIEW primitive, or function, that will go and do that for us right here, Flush Event Queue, and we can do that on command when we want. 

So what else is new? Well there’s now a way to set event priority when we use user events. So it’s right here and you can see that right now it’s normal priority. I’ll go ahead and turn this loop on by clicking on the check threshold button and run it and I’m going to clear all the previous stuff and let it run for a second and you can see that the user events are firing up here as handled events. Of course if I generate other events they’ll show up as well. So what’s happening in this loop, the lower loop, is that once a second we look at the value in this front panel numeric and we see if it’s above 100. If it is, we generate a user event which will turn on this LED down here, “over limit.” Now you can imagine that in a real world situation, going over a threshold could be a bad thing or at least something we want to notify our user of. The problem is, if we have a bunch of other events up here unhandled, then that over threshold event would have to wait until the end of the line to be handled, until now. As you can see there is a priority input, so I’ll stop the VI and go change this from normal priority to high priority. Bring back the event inspector window, run it, and generate a bunch of events and we can see that whenever that user event fires, it jumps to the top of the queue. And of course if I do go over 100, the next time it’s handled we get the over limit warning. That’s pretty handy stuff and very valuable for debugging and developing larger event-based applications in LabVIEW.

(end transcription)

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)