window events infinite loop

[dgholstein]

Chris; we're being a little judgemental on the code, aren't we? 

With experience, the end user won't run into any problems running the code, when they're tuning, they press the button, when not, they release the button.  While not tuning, they have control over the VI to print and save data.  I'm open to better if you can suggest better.

   ...Dan

[TCPlomp]

Dan,

did you read my comment?
is this what is happening?

Wait this workflow isn't working:

-Tune=true event, locks the event structure
-Open event (can't execute, could lock the FP)

Running in execution highlighting will make this very clear, so what is the FP locking status of the other events.

Ton

(sorry for the bold)

[dgholstein]

---

Could you elaborate a little bit more on this.

What works, and what doesn't. (I don't fully understand 'event loop')

I assume event loop is one of the other events, does the other event finish? Is any of the events locking the FP?

On the shown code, after an error 1 additional run of the while loop will happen.

Wait this workflow isn't working:

-Tune=true event, locks the event structure
-Open event (can't execute, could lock the FP)

---

When I say event loop, I meant "Event Structure"

No, the FP is not being locked by anything, I can switch a value that doesn't involve anything else tied to the event structure and that works fine.

Tune = T; loops as it should.
Tune = F; stops as it should.

Tune = T AND (Event Structure event fired); infinite loop

[altenbach]

You seem to have a few subVIs in the innermost loop that (from the graphics) look like dialogs. It is possible one of those is opening behind the main VI and thus never completes.

[TCPlomp]

So some of the front-panel controls are locked and some don't?

Strange.

To put down the following workflow which works:

1. Tune=T (event)
2. Tune=F (an event is queued and immediatly executed)

What doesn't work is the following:

1. Tune=T (event)
2. Some other event structure event (an event is queued, but never executed), and parts of the FP are locked..

Only 'lock fp during execution' makes sense to me.

I would try to put the 'Tune' code in a separeat while loop, that would probably prevent this from happening.
What does execution highlighting tell you?

Ton

[dgholstein]

Chris; Nope, no dialogs withing these loops at all, just accessing instruments and updating an XY graph (through a reference).

BTW:  To all, running in highlight mode doesn't reveal any insight, the loop continues normally and FP actions are ineffective.

[RavensFan]

How many other events do you have in that event structure?  Are you sure all of them are set to not lock the front panel?  That setting must be set for each individual event in the event structure.

Since, the tune event is essentially a long running loop, it would probably be a good idea to separate that into its own while loop parallel to the event structure loop and communicate to that using a queue..

[Ben]

"BTW:  To all, running in highlight mode doesn't reveal any insight, the loop continues normally and FP actions are ineffective."

Dumb question (on my part)

Do you have one of your events set-up to return a True via the tunnel feeding the loop condition terminal?

Follow-up if yes

Is that event firing?

Ben

Edited to fix spelling error. I am too dumb to know how to spell dumb.

Message Edited by Ben on 05-28-2008 02:59 PM

[dgholstein]

Raven;  I think you've nailed it.  I've attached a very small example of my problem in the demo.vi, when I turn on FP locking on one event, it behaves badly, when FP locking is all off, I get expected results.

[dgholstein]

BTW:  I suspect I can use "Set Busy" within each event case where I do actually want to lock the FP (which I normally do anyway).