In this episode, we finish up our discussion of using the Disable subVI by examining how it should be placed in a state machine. We explore how our basic state machine works and where the Disable VI would first disable and then re-enable controls. We then explain alternate programming methods, such as using event structures and type defs, depending on how complex and maintainable our application should be.
We recommend you take a look at the Enhance User Interface Usability through Disabling and Enabling LabVIEW Front Panel Objects episode of VI High if you're just starting to take a look at this topic (make sure to click through and watch part 2 of 2 as well).
That episode then leads to How to Use Property Nodes in SubVIs through Use of LabVIEW Control References and Refnums. Again, you'll need to take a look at part 2 of 2 for that episode too.
After that, you're ready for this:
Experience Level: Intermediate
“This is part B and it’s more at the intermediate level. Are you ready? We’ll examine using the disable VI in a state machine and some considerations for state machine usage. Let’s take a look at a state transition diagram. I start and go to the Begin state, which could also be called my Idle state. From here, I can go one of three places. To the Basic Test, by clicking the Launch button, to the Advanced Test, but clicking on the Advanced button, or I can end, by clicking on the Stop button, that’s implied. If I go to the Basic Test you see that I always go to Advanced Test and then back to Begin. And if I go straight to Advanced Test, I’ll just go back to begin. If nothing is pressed, I remain in the Begin state. Let’s run my state machine first. I’ll click on the run button, when I launch I go to Basic Test, then Advanced Test and back to Begin. If I click on Advanced, I go right to Advanced and back to begin. And stopping, means I stop. And here’s my block diagram, showing the infrastructure of a state machine. 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. Typically, we also see this enum constant. I’ve already created the array of controls that we’re going to selectively enable and disable. Let’s review the logic of this state machine. Here’s my Begin state, and in my begin state I’m constantly polling my Launch button every 50ms to see if it’s been pressed. If it has been pressed, we go to the Basic Test, if it’s not we check to see that the Advanced button has been pressed. If it has, we go to Advanced Test. If not, we stay in the Begin state. If we go to the Basic Test state, we perform the Basic Test and move on to the Advanced Test. The Advanced Test is remarkably similar. We perform the Advanced Test and move back to the Begin state.
Now let’s suppose I have the same requirement as I had previously that these controls on my front panel be disabled when the test begins and re-enabled when the test finishes. Where shall I put that disable VI in my state machine? It makes sense that I would place it either after the Launch button had been pressed, and after the Advanced button had been pressed. And again, after the Advanced Test has finished executing. There are a few ways of executing this, we’ll execute first the simpler method, and then later explore a more modularized, maintainable solution.
We’ll take our disable VI and place it in here. Take my array of controls, and pass it right in, move this over and we’ll essentially do the same thing, Ctrl+C, if this Advanced button had been pressed. Rather than this Select function, it makes more sense to have another case structure. We’ll need a bit more space. So I’ll hold down Ctrl, click and drag, to create some space. Ctrl+V to put my disable VI in the correct place. Another Ctrl+click drag. Move to my other case, and remain in the Begin state. When it’s time to reenable the controls. I’ll go here to my Advanced Test, and just put the disable VI in here and enable instead of disable. We’ve kept this state machine simple, so we have not employed any error handling. So we’re not using the error cluster, typically a bad idea, except for instructive videos, where we make a concerted effort to remain simple. However, to enforce execution order I will connect the error cluster from here to here so that the disable VI executes after the test. And now we’ll go to my front panel and run my VI. When I haven’t launched anything, I can manipulate my controls. But when I do launch, I can’t, until the test is finished and they’ve been re-enabled. Perfect.
As I mentioned, we went with a simpler path, for implementing these disable VIs. I added these Disable VIs within the Advanced Test and the Begin states, assuming that I would never have another state in between clicking on one of these test buttons and then disabling the controls. Also that I would always re-enable after the Advanced Test. However, I may have needs in the future to modify my application and then those assumptions may no longer by true. Therefore, in a better modularized application, it would be wise to have enable and disable in their own states, that way I can change the order of states around without editing other states. That’s just smarter, but I would have needed to add those enable and disable items to this enum, and that enum definitely should have been type defined, otherwise called a type def. I would add separate enable and disable states in the state machine. Again, I didn’t do that, just to be simple. Additionally, this very simple state machine is relying entirely on user interface actions to drive the direction of the state machine, so it would have been better to place an event structure in the Begin state. But again, you probably guessed the reason I didn’t do that, the answer is simple. “
Originally posted at: http://blog.sixclear.com/post/2393205652/disable-vi-in-state-machine