LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Please add Front panel Control value set with signaling method

Status: New

Currently there is a method for setting the control value of another VI via the Control Value Set Method. But there is no set with signaling method which allows control of VI's which react to changes on front panel controls. This makes it hard to automate VI's that are using front panel control events. There is a tedious work around to get references to control on the front panel and then use value signaling method . It would be very useful to just have one additonal method that does the signaling in additon to setting the value of the control.



Trusted Enthusiast
Trusted Enthusiast

Of course you can, but it takes a bit more work. Is this what you are calling tedious?


Set Control Value (Signaling) Example.png

Proven Zealot

X: There's no need to close control references. Ever. It's a no-op.

However, your close of the VI Reference needs to happen after all the rest of the interaction.


Response to X.

Yes this is exactly what I do now as a workaround  but it clutters the diagrams instead of just having a single method call Val(Sgnl) by name.

By the way , VI path has to be handled in a special way also for a clone vi - pass string to it instead of a VI path.

Trusted Enthusiast
Trusted Enthusiast

But then, I would argue that having the Visible Property accessible directly as an Invoke Node method would be pretty handy...

Seriously though, maybe a User Event would be more appropriate than a Value Change Event to trigger whatever you want to trigger on that clone?


In addition to X.

Some time ago I made a subvi that handles both val (sgl) by ref and val by name.


Our use case is that, in our research lab, we now can automate already existing vi's.

We have a general "automation vi" that reads (from excel) a seqeuence of button states and values to be pressed and set.

This automation vi uses the described methods to control another vi.


Very convenient in a research environment where things may change by the minute and you are experimenter as well as labview developer.

(Note: the non-static nature of our research makes us do all our measurements in the development environment).


Also not clear to me why 'value' and 'value (sgnl)' are not both available in the invoke node.



val(sign) by ref and val by name.JPG

Trusted Enthusiast
Trusted Enthusiast

Interesting. I was under the impression (based on the first Invoke Node) that Latched Boolean could not be actioned programmatically...

This being said, for automation (aka scripting), I would personally rather send sets of instruction to a state machine via a queue, the state machine being also actionable from buttons and such on the VI FP.



[..] that Latched Boolean could not be actioned programmatically

Yes, you can, using the invoke node. However, not when used to fire an event in an event structure. As fas as I know, the latter is the only limitation for the vi server mechanism to action controls programmatically (and probably for good reason, intrinsically impossible).


[..] I would personally rather send sets of instruction to a state machine via a queue, the state machine being also actionable from buttons and such on the VI FP.

Yes, probably a good programing practice and nice solution.


Our use case is to programmatically activate EXISTING target vi's controls (without the need to alter the target vi). However, you also want to be able to activate the target's vi controls manually, or change the instruction set while the program is running. And you want to be able to use any target vi, also those not intended to receive sets of instructions.

As said, our solution is very convenient in a research environment. And I don't see a good argument against it.


To give you an impression, I show our automation vi front panel.

The instruction set or sequence action is prepared in excel and saved as a csv file.

This file is read by the automation vi (FP shown here) and will activate the target vi (or VI-to-Control).


Once you have it, no need for further programming, just make your sequence action list in excel and run your automation vi.

The only exception (unfortunately), as said before, is that for firing a latched BOOLEAN IN AN EVENT STRUCTURE you need to modify the target vi (vi-to-control) to make it non-latching and "de-press" the button programmatically yourselve.


 LabVIEW automation.JPG



Programmatically firing a LATCHED BOOLEAN IN AN EVENT STRUCTURE is possible after all, I found out here .

I changed my automation vi accordingly and up to now it works perfectly.


Here a snippet of my updated version.



 programmatically fire latched boolean in event structure.png


Trusted Enthusiast
Trusted Enthusiast

Interestingly, you can pass a true or false value and this will trigger an event regardless, as illustrated in this simple VI:


Test Latch Boolean.png


Run the VI, select a "Boolean Value" of your choice, click on the "Latch Boolean with Value" and observe the response.


The diagram of the subVI is a slightly simplified version of yours:


Change Control with String.png




Thanks for the response!

and your contribution.


However I am not sure I understand your point.

[.. ] you can pass a true or false value and this will trigger an event regardless [..]

regardless what?

Do you mean that it always triggers the event, even if the Control Value = FALSE?

That indeed is interesting (and pointed out by Altenbach in the thread I referred to in my previous post (here) ).