front panel locks up

[JÞB]

a few questions.

1) what does the Open G function after fp.open do?

2) is the vi wired to fp.open set to run when opened?  is it Modal?

3) probe the queue reference- is it destroyed? (hey you might want to add a error handler in the loop to make sure the fp-close method executes.)

4) fp.open property is not recommened why not use the fp.open method (which ignores "run when opened" and a few other vi properties)?

[Mark_Yedinak]

---

@Mads wrote:

The OpenG wait function is reentrant, if it had not been I would call it a bug.

---

That was not the experience I had recently. I had multiple OpenG waits which should have run in parallel however they did not. One of the calls waited for the other to complete before running. I didn't investigate it much further and I was not able to look at the BD to see what was going on. I didn't spend much time investigating it though and probably should in case it is a bug.

[TCPlomp]

One thing might happen:

You toggle the boolean during the 100 ms wait, in a parellel loop you change the control to 'false'  in the next run the boolean is false again.

It's either something like that or a serious bug in LabVIEW, but without the actual VI I can't tell.

Have you tried removing the while loop and rebuild the loop from scratch, or a force recompile? (make a back up of the old VI, NI will be interested.)

The OpenG VI resizes the diagram to the largest decoration. (see here)

Ton

[Darin.K]

What is stopping the two Event Loops?

[PaulG.]

What I have so far that is still not working.

The vi is set to open default mode. I tried Modal no effect.
The queue is present inside the loop.
Changed the open fp to method. No effect.
The stop button is set to latch when released.
I rebuilt the loop from scrathc. No effect.
The 2nd event loop is stopped by the "stop" local just outside this loop.

[Darin.K]

Still one thing I can't wrap my brain around.  I believe you said that the second event loop has a timeout of -1, what event fires to allow the stop local to be read and stop the loop?

[PaulG.]

---

@Darin.K wrote:

Still one thing I can't wrap my brain around.  I believe you said that the second event loop has a timeout of -1, what event fires to allow the stop local to be read and stop the loop?

---

Now that you mention it I can't wrap my head around it either. I had it set to 1000 ms. I set it to -1 recently just to try anything. But in fact that loop will never stop if it's set to -1 and supposed to be stopped by the local "stop". No matter. The vi closes and the ref gets deleted at the end of the vi.

[PaulG.]

Just an FYI on this problem. I fixed it. It was a timing/race condition. There was a shared variable from the PLC triggering an event structure via Value(Sgnl) property. It was waiting for an input at this portion of the code while it was trying to service the event at the same time. Really hard to find since at all locks up at once. Thanks everyone anyways for your help.

[Darin.K]

Wow, a sporadic, difficult to spot bug that apparently took over a month to track down turns out to be a race condition.  First time for everything.... 

[PaulG.]

Indeed it was a real bear to find. And the PLC behavior isn't very consistent. There was plenty of work getting done, however while I was tracking this down since it was so intermittent.