LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

References vs Property Nodes in SubVIs

Highlighted

I have a question, I am sure there is a straightforward answer but I am a little bit confused.  For full disclosure, this is my first real project with LabVIEW, and I just saw it for the first time a couple months ago.

I currently have a program with one subVI, an automation loop.  I set it up and it works essentially as I want at the moment using references linked to RefNums in the subVI, which are passed to a For Loop in the subVI where they modify the Value property.  The subVI has no outputs in this set up, but modifies the front panel manual control states via this RefNum Value property. 

When I set it up like this, it works correctly.  In fact, it seems to still work correctly even when I disconnect the references from the subVI and rewire the terminals.

In trying to optimize, I thought it might be smoother and cleaner to just wire the subVI output arrays directly to Value property nodes in the top level front panel VI.  However, when I do this, the automation no longer runs.  I am a little confused, and could leave it as is since it works as I need it to, for now, but I was hoping to find out a little bit more about Property nodes and References as called from subVIs.

 

The two attached VIs currently work as desired.  They still work if I delete the references from the front panel.  However, if I delete the Array RefNums and Property nodes from the subVI, it no longer works.  Very curious as to why, as I believe it could be made more elegant.

Thanks for any feedback, and I apologize for any NI/LabVIEW faux pas!

Download All
0 Kudos
Message 1 of 10
(1,996 Views)
Highlighted

There is plenty of room to improve. Lots of unnecessary parts.This VI was written previously by someone else, yes? That person had no idea how to program properly using a state machine, so I guess this was a kind of alternative way to automatize the digital outputs. This is a design which you should abandon, and rewrite the application using a proper state machine where you can setup a output task sequence, and execute it. A Queued State Machine would be a good choice for this application. Actually in that case you do not need that subVI, you could use the Idle state of the state machine to "pre-configure" the required sequence to iterate through...Search for the keywords "state machine labview", and you will get some things to read.

 

Other problematic parts: in the main VI, you initialize and close HW resources at EVERY iterations! This is really bad, you should initialize your hardware once before the main While loop, and stop/close it once after the While loop. You should have only that "DAQmx Write.vi" inside the While loop.

 

If you have access to the Core 1-2 learning material, it could help a lot. Try to put together a state machine, and post back here when something is not clear. But take some time to learn the basic things like shift registers, the data flow principle in LV, etc...

0 Kudos
Message 2 of 10
(1,978 Views)
Highlighted

Thanks, I guess I will look into state machines.  It seemed a bit too much for what I was trying to do but it seems from what I've been reading that I may have to head down that path anyway.

To be honest I did base some of the VIs on some other skeletons but mostly it was me making the mess : )

And yes, you are right - I think I moved the DAQ tasks into the while loop at some point to move things around, and forgot to move them back out.  Thanks!

0 Kudos
Message 3 of 10
(1,920 Views)
Highlighted

I have been reading a little bit about state machines and queued state machines now, and I am a little hesitant.  It seems like state machines and queued state machines are mostly preferred for programs with many different states, usually captured in a case structure.  I do not think a case structure is really ideal for my application, as the number of steps and timing settings should be modifiable by the user from the front panel.  I feel like input arrays are most suitable for this.  I am actually not even entirely sure how/why I would set up a case structure for my application.

I will continue looking into state machines, but could you maybe clarify a little more as to what would make a state machine more suitable?  It could be there is a misunderstanding of the application purpose.

0 Kudos
Message 4 of 10
(1,909 Views)
Highlighted

@dzaks wrote:

I have been reading a little bit about state machines and queued state machines now, and I am a little hesitant.  It seems like state machines and queued state machines are mostly preferred for programs with many different states, usually captured in a case structure.  I do not think a case structure is really ideal for my application, as the number of steps and timing settings should be modifiable by the user from the front panel.  I feel like input arrays are most suitable for this.  I am actually not even entirely sure how/why I would set up a case structure for my application.

I will continue looking into state machines, but could you maybe clarify a little more as to what would make a state machine more suitable?  It could be there is a misunderstanding of the application purpose.


You are in a misunderstanding. You compare an apple to an elephant. State machines are not only Case structures, and why do you compare arrays to state machines? Does not make sense. Try to dig into state machines a bit more and you will find them how powerful they are for your application. A state machine is just perfect to handle user interactions, and even more. Just to give an oversimplified example of a Queued State Machine:

  1. Idle state (the user can pre-configure required steps/actions to execute with timing parameters)
  2. Init HW and start executing preconfigured steps (here you can initialize your DAQmx HW, and inject the array of required actions into the Queue of the state machine)
  3. Execute HW actions/steps as required (this state is called via the waiting elements in the Queue)
  4. Release HW and move to Idle (When the execution of state 2 finished, the SM releases the DAQmx HW, and moves back to the Idle state)
  5. Abort actual sequence: when the user clicks on the "Abort" button, Enqueue the Abort command in the front of the Queue --> "Priority command" (Since you broke up your sequence into small steps in state 3., it is fast and easy to abort your procedure at any time)

You could use a Producer/consumer (Events) design pattern, where your Queued State Machine "lives" in the consumer While loop.

0 Kudos
Message 5 of 10
(1,903 Views)
Highlighted

I see.  I guess just the steps you are describing seem more confusing to me than what I have, but I will continue looking into these queued state machines.

However, I think even in a state machine structure I will wind up with the same question where I need to write the configured valve states from the automatic loop to the front panel array controls using a property node.  So my question at that point would be the same, why do I need to use a reference connected to the Value property node instead of just writing to the Value property node in a read state directly?

 

Also, I am not sure what you mean by release HW - just to be clear, I have to write continously to any given single valve at least every 100 ms loop.  So while I can open the channel and close the channel outside the while loop, the write function must remain inside the while loop, I believe.

0 Kudos
Message 6 of 10
(1,895 Views)
Highlighted

@dzaks wrote:

I see.  I guess just the steps you are describing seem more confusing to me than what I have, but I will continue looking into these queued state machines.

However, I think even in a state machine structure I will wind up with the same question where I need to write the configured valve states from the automatic loop to the front panel array controls using a property node.  So my question at that point would be the same, why do I need to use a reference connected to the Value property node instead of just writing to the Value property node in a read state directly?

 

Also, I am not sure what you mean by release HW - just to be clear, I have to write continously to any given single valve at least every 100 ms loop.  So while I can open the channel and close the channel outside the while loop, the write function must remain inside the while loop, I believe.


You just do not need that extra subVI you call it "automatic loop". You can have those control arrays in your main VI, where the user can pre-config a "recipe", and launch the sequence to execute. This way is more simple than that strange subVI usage via property nodes...

 

About the "release HW": this was just an example, if you need to output signals permanently, of course you do not need such step, only when you stop the whole application...

0 Kudos
Message 7 of 10
(1,893 Views)
Highlighted

Your Automation VI (or any VI) only sends out information on outputs once it's finished. You're right in that it's a better choice/design to send data through inputs and outputs in general.

I can't open your code, but general thoughts:

In a state machine you'll have some Measure-state. If you want Front panel controls to update, this state must be fast and update the indicators (e.g. through the outputs of a sub-vi), then return/continue with the same state until done, after which you'll go to Write Result or similar. It basically sounds like your Automation VI does it all, including updating indicators. Unwrap it. Then you're basically home free. 🙂

See my attached file as inspiration.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 10
(1,880 Views)
Highlighted

So, still pretty confused about State Machines and QSM in their application here.  I adapted the VI to a QSM this afternoon, and it is basically having the same problem that I had about 2 weeks ago when my original VI had the for loop wrapped in a case structure - I cannot figure out a way to write to the hardware channel during the for loop, so I don't get the individual steps in the for loop, only the output from the final step.

I did update my VI + sub-VI to get rid of my sub VI, and now I just have two while loops running concurrently and everything is running more or less correctly in one VI.

I have attached both the Queued State Machine VI and the non-state machine VI.  Essentially the non-state machine VI functionality is what I am after - if someone could compare the two and let me know if there's a good way to optimize it for state machine architecture or what I am missing, that would be great.  I'm sure it's a big mess.

the QSM seems not to work when I mouse click on the front control, which is interesting.

Download All
0 Kudos
Message 9 of 10
(1,812 Views)
Highlighted

Hi Dzaks,

 

I looked through your code, and I may have found the culprit for your front panel locking up- Event Structures have a setting where they can prevent Front Panel interactions until the event handling is finished. This article has more information about it, but I'd bet that this is that this is why your Front Panel is locking up.

Kathryn K.
Technical Support Engineer
National Instruments
http://ni.com/support
Message 10 of 10
(1,782 Views)