Event Problems

[Munson1027]

Hi all,

I am controlling a microscope  After the microscope is initialized, I am using an event structure to capture user input (e.g., change objective), send the appropriate commands to the scope, and then read the position of the objective AND a number of other microscope components that change as a result of changing the objective.  These secondary changes are all triggered and processed in the microcontroller in the scope, I have almost no control over them, thus I read the state of all hardware anfter changing any hardware.  The front panel controls I am using is are menu rings and booleans (actually a cluster of menu rings and booleans).

When I change a control, the following sequence occurs:

1) The commands are sent to microscope and it begins to move

2) The front panel value of my control changes BACK to the old value

3) The microscope finishes moving and the "query microscope state" subVI executes

4) The value of all the controls is updated (using locals) to the final and correct values

So I didn't expect to see item 2, and I would like that behavior to go away.

In a sense this is not a true problem as my hardware executes the change as requested and at the END the front panel shows the right value, but some of the moves take a while (seconds) and it can be disorienting for the user to have the value of the control they just changed change back before changing again the the value they want.  I see the same behavior with some Booleans that control shutters.

So why does step 2 happen?  What can I do to keep it from happening?

FWIW I have configured the event to not lock the front panel because there are independent controls in a parallel loop that could require changing while the microscope executes its changes.

Thanks

Matt

[RavensFan]

I don't think we could even venture a guess without seeing your VI.

[Munson1027]

First, thank you for even reading my long, wordy, question even though my vi was not there.

Unfortunately, it would take a lot of work to be able to post the VI as some of the contents are protected by a non-disclosure I signed with the manufacturer, so allow me to attempt to completely abstract my question into the purely theoretical:

1) The controls on my front panel are changing when I do not expect them to

2) What can cause a front panel control change other than a) user action, b) writing to a local, c) writing to a property node, value (or value(signaling))?

None of the things listed are occurring at the time that I see my front panel change.

If there is still nothing that can be said without posting the VI, I will do the work to post one that contains only publicly available info.

Thanks

Matt

[Munson1027]

So I fixed it, but don't know WHY changing what I did solved the problem.

Within the event structure, a subVI is called that reads what the actual state of the hardware is, i.e., what the value of the controls on the front panel should read.

I was passing the value of the controls read off the frame of the event structure into that subVI and attaching that value to the "input cluster" terminal of a bundle by node, which is then written to an indicator cluster which returns a new value for the cluster to the main VI.

To fix the problem, I used a local from the subVI's output indicator for the "input cluster" of the bundle, and the behavior disappears.

I was under the impression that I subVI couldn't change the main program until after execution of the sub was complete and the values were returned.  Am I wrong about that?  I think that the rules are somewhat different when references are used to pass data in and out of subVIs, but I don't really understand references, so I am not using them.

Is there anyone out there that can clear up my general confusion?

And yes, of course this is the kind of thing that you NEVER could have determined without seeing my VI.  I will do better about posting VIs with my questions in the future.

Thanks

Matt

[Mark_Yedinak]

Now that you know what is happening can you post a simplified example illustrating what you were seeing. I can't quite follow your explanation and so can't really give you any feedback on why your change made a difference. Since you know what is happening it would seem easy to post a mock up of the code.

[johnsold]

Matt,

Can your "read the state of the hardware" subVI tell when the changes are complete?  If so, do not update the front panel until the change is finished.  You might also add a boolean indicator (or Grey Out the cluster) while the changes are in process to indicate to the user that something is happening at the microscope.

Often it is better to move lengthy or time consuming tasks outside the event structure.  It then becomes easier to isolate the User Interface from functional code.  The Producer/Consumer (Events) Design  Pattern shows how this can be done.

Lynn