Initialisation of all control data via event structure at start-up

[cmcqueen1975]

I am developing a VI to manually control a device. It needs to send messages over a network to control the device according to various controls on the VI.

I've got an event structure that handles changes to the controls.

It works fine when I change controls when it's running. But when I first start the VI, the device is not updated with whatever are the initial values of the controls. At start-up, I would like it to essentially run through every event handler once, to send out the network messages for the initial state of every control.

I thought I could do this by looping over all the controls in the VI, and reading the Value property and then writing to "Value (signal)" property. But that gets an error for any latching boolean controls that are present.

The attached VI shows what I tried to do. The block at the top tries to generate an event for every control, ensuring each control updates its associated output with whatever its initial state is. Unfortunately, it gets an error due to the latching stop button. If you delete this block block, it runs okay, except the outputs aren't set to whatever the initial value of the inputs might be. Each output is not set until the user first modifies the associated input value.

Any ideas on what is the best way to achieve what I'm trying?

[mikeporter]

Why are you want to fire the stop button? Wouldn't that stop the VI you are trying to initialize?

Mike...

[cmcqueen1975]

I don't want to fire the stop button. Nor would the attached code fire it, since it writes the same value it reads (assuming the stop button isn't pressed before the user even starts the VI). However the stop button is, it so happens, a "latched" boolean control which means it can't be programmatically read. Nor could any other "latched" boolean control.

What I'm trying to do is find a simple way to run the event structure handler once for every control at start-up, to act on the initial state of each control.

See the attached files -- that's what I eventually settled on. The added complication I found is that tabbed controls must be explicitly recursed into in order to "trigger" each of the controls within the tabbed control. Is this a good way to do it, or would I be better off pursuing a different strategy?

[jdpowell]

Personally, I avoid these problems by never using "latched" booleans, just "switches".

[smercurio_fc]

Nothing wrong with latched Booleans...

You are correct in that the "Value(Signaling)" property does not work for latched Booleans. This is by design. Actually, there is a way to read/write the state of latched Booleans, but it's a private property, so it's not documented or supported by NI, and may be unstable or not even appear in future versions of LabVIEW. You can head over to the LAVA forums if you feel adventurous.

I don't know the architecture of your overall program, but you may want to consider creating a producer-consumer architecture. With this the producer responds to events by adding a state to a queue. The consumer executes these states to do the actual operation behind that event. Thus, you can have an "init" state that simply calls your VI to handle all the non-latching Boolean controls, and then simply append the states that handle value changes for the latched Booleans rather than trying to use the "Value(Signaling)" property which you can't use.