Skip navigation

Community

Sixclear's Blog

2 Posts tagged with the disable tag
0

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


 

(start transcription)


“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. “


(end transcription)


Originally posted at: http://blog.sixclear.com/post/2393205652/disable-vi-in-state-machine

and: http://blog.sixclear.com/post/2403912348/disable-vi-in-state-machine2

0

In this episode of VI High, we don't let up on our previous topic of intuitivity, we continue to take a look at conditionally enabling and disabling LabVIEW front panel objects.

 

This time around, we go a step further and use references and refnums to create a Disable VI specifically made to enable and disable objects on the front panel of calling VIs. We can use this VI in the future in all kinds of applications. Valuable.

 

Experience Level: Basic

 

This is a small part of the full content in the Sixclear Lucid LabVIEW Fundamentals Training (formerly Sixclear LabVIEW Fundamentals) course. The full course also has a more excited narrator.

 

 

(start transcription)

“In our last episode we learned about intuitivity and disabling and enabling front panel objects with property nodes. As we see here, these front panel objects being enabled or disabled with these property nodes. At the end I asked if there exists an easy way to modularize what I’ve done and access the same disable property on all these objects without creating separate property nodes for each object each time I enable and disable. That’s what we really want and that’s what we’ll do now.

First we’ll look at how we previously accessed the disable property: through these implicitly linked property nodes. Why are they called that? To differentiate them from explicitly linked property nodes. Well what’s that? I can create an explicitly linked property node by simply pulling up a generic property node, this property node can display the properties of any object, it just needs to be pointed to that object. We do that by creating a reference to an object. Let’s do that. We’ll copy these controls to a new VI. Ctrl+N is a shortcut. I’ll right-click on Acquisition Rate and choose create»reference. Now, I’ll pull up that same generic property node and wire the reference into the Reference input. Now I’ve exposed all the same properties of the object with this explictly linked property node as I had with this implicitly linked property node. The object is the Acquisition Rate Control. This property node is explicit because I used this reference to explicitly point it to a particular object, and has the added benefit of not needing a parental advisory.

So why would we want to be so explicit? Let’s examine. There are many reasons. A common reason is to have a single property node access the same property of multiple objects. We have a perfect need for an explicitly linked property node in our current Test.vi as these 3 implicitly linked property nodes here and here are accessing the disabled property on 3 different front panel objects, these three. If I want to use one generic property node on these other two objects I’ll need to create references for those. How can I have this same property node access these references? Simple, create an array and auto-index it into a For Loop. Now choose the disabled property, change to write, move this over, create a constant. Now if I pull up my front panel, and put this on highlight execution, I can watch as one by one, I will disable each object. Take off highlight execution, enable them, run them, they’re all enabled. Perfect.

 

“Going back to test.vi. I need to essentially do the same thing in 2 places: disabling here and enabling here. Rather than make a copy of this block of code twice, we know that this is a perfect case for a subVI. So I’ll make this new VI into a subVI. To be able to control whether I enable or disable, I’ll pull this constant outside of the loop and also create an error cluster going in and going out. Wire these back up, and disable indexing because I don’t want to have an array of error clusters. This is the section I want to make into a subVI, so I’ll just select it and go to Edit»create SubVI. I’ll look at the block diagram of this new subVI. Let’s clean it up with the block diagram cleanup. And I have this array of incoming references which corresponds to an array of refnums or reference numbers on the front panel. This accepts an array of incoming references from a calling VI. Let’s save this. I’ll call it disable and give it a nice icon. There’s a glyph already waiting for me. Lovely. Now I’ll drop disable.vi in place of these existing property nodes and connect everything. But first we’ll fix the connector pane, to the 4x2x2x4. Back on test.vi, I’ll make this array of references. Simply copy this.

 

Now I’ll see that my test.vi behaves exactly as it did before. I can run it, edit these controls, when I click on run test, the test is running and I can’t edit these controls, until the test is finished and they’ve been re-enabled. Disable VI is now a very handy subVI to be able to use in future applications. We’ll take a look at that in part B of this video.”


(end transcription)

 

Originally posted at http://blog.sixclear.com/post/2316387059/propertynodesubvi