Please add Front panel Control value set with signaling method

[jj2]

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.

[X.]

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

[AristosQueue (NI)]

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.

[jj2]

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.

[X.]

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?

[donkdonk]

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.

[X.]

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.

[donkdonk]

@X,

[..] 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.

 

[donkdonk]

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.

 

[X.]

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

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:

[donkdonk]

@X,

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