Boolean Remote Control Example Design

[Brian Wells, Space Research Institute]

LabView Developers:
This is an interesting timing problem I ran into while implementing a remote user interface using VI server. The example code contains the correct code along with the incorrect version of the code that at first attempt looked like it a good solution.

The objective is to control a data storage trigger on a local user interface for remote data acquisition. On the remote machine the trigger is reset after the specified sample time is exceeded. At any time, on either machine reselecting the trigger Boolean control ends the data storage.
The problem arose while trying to get the user interface to update the local trigger Boolean control to the state of the remote Boolean control without overriding c
hanges made by the user.

If you have any comments regarding different ways to implement this program I would appreciate any comments and suggestions from other developers. I am working with LV6.0 so I cannot use event structures. My solution uses shift registers, which unfortunately tends to clutter up the block diagram.
Sincerely,
Brian Wells
Research Assistant III
Space Research Institute
Auburn University, AL 36830
334-844-5967

[Trager]

What I would do is change your paradigm a little. Have a boolean indicator that shows whether or not you're supposed to be storing data, and give the user a control that toggles that state.

Alternatively, depending on your latency, you give the user a control that sets the desired state, along with an indicator that shows the current actual state.

Seems to me there are several ways to workaround the problem if you aren't bound to a single control/indicator.

[Brian Wells, Space Research Institute]

You mentioned that I could use a boolean indicator that can be toggled by the user. How would you link the RemoteTrigControl.vi boolean control to the TimedTrig.vi boolean indicator? Please clarify.

I haven't explored the posibility of using a Datasocket. This might yeild a cleaner solution.
Brian Wells