07-30-2010 05:16 PM
Once the device is selected the utility panel will execute that whole set of commands. Even though it executes all those commands, it only displays the output of one: the getDeviceId command. Why does it execute all those commands? The VI was probably never finished. You could use the utility panel, but you'd be better off just creating your own panel to issue the commands you want "on demand". You just need to use the subVIs. Way back in reply #10 I showed you a simple example. Attached is an event-structure based example that you can expand on.
07-30-2010 05:20 PM
You can probe the wire coming from the shift register to see the values in the array. You could also put an indicator on the front panel (with the associated terminal inside the while loop) to see the array at any moment. Either way, it will probably be processed too fast for you to see what is happening unless you add a delay to the while loop or you run with execution highlighting as I suggested in an earlier post.
I think this is intended as an example of how to use the library functions, which is why it executes some commands without displaying the results.
As for editing the array, you can see that several cases write new values to that array. For example, look in the processEvents case. When the "Write Command" button is pushed (the "raw_cmd" value change event), it puts two commands in the array: "rawCmd" (to execute the command) and "processEvents" (to go back to waiting for an event after the command completes). Say you want a button to execute a specific command, you would add the button to the front panel, add a new event case for that button, and build an array containing the command you want to execute and processEvents to return to the event processing case (if you don't do that, the program will terminate after executing the command, because it stops when the array is empty).
07-30-2010 05:23 PM
One quick observation - this VI needs a call to openDeviceReference following the call to the device selection panel.
07-30-2010 06:15 PM
Thanks smercurio_fc, I'll take a look at that on Monday (no LabVIEW at home lol). And I think you're right, these VI's all have a "not fully cooked" feel to them.
And thanks again nathand. But by "edit the array" I mean how would I go about removing states? Now that I comprehend how the VI works, I was thinking I could just remove all the states I don't need, and add a new state which would drive the motor in the manner I (eventually) intend to - that is, based on thermocouple feedback.
That way, the program would be sure to process all the requisite events in the proper order (device selector, initiate, power on, etc). Also there is one command that they did not include - EO=1 - before the motor will run, so I would need to add this to the array as well.
07-30-2010 06:58 PM
@Samweis wrote:
And thanks again nathand. But by "edit the array" I mean how would I go about removing states? Now that I comprehend how the VI works, I was thinking I could just remove all the states I don't need, and add a new state which would drive the motor in the manner I (eventually) intend to - that is, based on thermocouple feedback.
That way, the program would be sure to process all the requisite events in the proper order (device selector, initiate, power on, etc). Also there is one command that they did not include - EO=1 - before the motor will run, so I would need to add this to the array as well.
Right-click on the array element, choose Data Operations -> Delete Element. For a basic question like that you might find that experimenting gets you the answer much faster than posting on the forum and waiting for a response. Same menu lets you add a new element to the middle of the array; to add a new element at the end, just expand the array (or set the index) so you can see the end, then fill in a value.
To add a command, you'll want to modify the enumeration "commands.ctl" to add the new command, then add a case for it to the case structure.
08-02-2010 03:33 PM - edited 08-02-2010 03:35 PM
Yeah I realized it was a dumb question right after I asked it lol.
What I'm getting at is the following: How do I view the order of states? If I select the pull-down menu they are in alphabetical order. However when I run with execution highlighting enabled, they are not processed in this order. It starts with "initialize" (obviously) which pushes it into "getDeviceList" and from there I'm a little confused. "getDeviceList" contains an array of states which are processed in order, somehow, I'm assuming? (see screenshot8 attached)
What's more, at some point it seems to enter the following loop: getTemperatue - getPosition - getStatus - processEvents - updatePanelItems... (I'm guessing this is driven by the array in the "processEvents state) with any manually entered command processed in the "processEvents" state pushing it to the "rawCmd" state (and then back to "processEvents").
In short, I'm having trouble visualizing the sequencing of events and how each is triggered. I do not have the "State Diagram Toolkit" (or whatever it's called now) installed.
As a follow-up question: Why are there separate states for "getIdleCurrent", "getAcceleration" etc?? If these were in an array, they would be passed to command_center.vi one-by-one, yes? Wouldn't it be advantageous then to combine all these states into one?
Thanks again.
08-02-2010 03:47 PM
The order in which the commands are listed in the case structure is irrelevant. Commands are processed in array order, first to last (the 0 constant wired to Delete From Array indicates that the first element - the one with index 0 - should be removed). In an array constant, such as shown in your screenshot8, the first element is at the top and the last element is at the bottom. The getDeviceList command loads an array of commands, which are removed from the array and processed one at a time, until it reaches processEvents, where it waits for the user to do something. When the user enters a command, it handles it as you've described, executing the rawCmd and then returning to processEvents.
I can't answer your follow-up question, that's a design decision by the author of the VI.
08-02-2010 06:37 PM
Okay so you probably are thinking I just asked the same question like three times. Sorry if it seems that way, maybe I'm not good at vocalizing my questions; but I am learning and you all have been very helpful 🙂
Why am I getting this error?
I've read this document, and I have used quotations, but still the selector value is in red.
http://zone.ni.com/reference/en-XX/help/371361B-01/lverror/sel_values_wrong_type/
It appears as though only certain values are allowed, as if it's connected to an array or something?
That is, I can name it "getMotorStatus" but not "getPowerStatus"
Thanks
08-02-2010 06:44 PM
The data type connected to the selector is an enumeration, specifically "commands.ctl" so only values that are in that enumeration are valid in the case structure. I'm not sure why getPwrStatus isn't valid since that seems to be in the enumeration (unless you've modified it), but try deleting the quotes around it.
08-02-2010 08:33 PM
You are confusing the two enumerations. One enumeration is for the names of the states. This one drives the case structure. This enumeration has no "getPwrStatus". The other enumeration is for the list of commands. This has the "getPwrStatus". If you want a state "getPwrStatus" then you have to update the utility_actions.ctl typedef.