front panel locks up

[PaulG.]

When this vi nears completion it reaches this part of the code and waits for a final comment and for the user to close panel so the iv will finish and close. About 50% of the time it works. When it doesn't the VI is totally locked up and I have to abort out. What would cause this FP to lock up and refuse input?

[GregFreeman]

Possible race condition with the stop local? I don't know if this would cause a front panel freeze though. Usually you can still push buttons, they just don't do anything.

[PaulG.]

Don't think so. The local isn't written until I get out of that loop. Everything seems to freeze right before I get to the loop.

[TCPlomp]

Not sure how this can happen, but one debugging technique is to add an indicator to the loop counter. (and add a +1 between the 'i'  and the indicate to see it's started the first run.

It might be that some of the inputs are not ready! (I heavily suspect the numeric array!)

You can try this by placing a breakpoint on every incoming wire, you should all the breakpoints before your freeze.

Another point to try is to set the timeout of the read queue to 100 ms, and remove the OpenG wait function.

That prevents you from loosing  messages! When there are more than 1 message per 100 ms. you might loose messages.

For instance:

T=0 ms : start loop

T=0 ms: Read Queue finishes

T=10 ms: Add message 1

T=30 ms: Add message 2

T=100 ms: Iteration 0 finishes

T=100 ms: Read queue finishes and returns message 1

T=120 ms: Add message 3

T=130 ms: Stop pushes

T=150 ms: Iteration 1 finishes

T=150 ms: Read queue finishes and returns message 2

T=200 ms: OpenG wait ends, Iteration 2 finishes, and terminates loop

So your queue has 1 message in backlog, and you had an additional 70 ms wait after the push of the stop button. (this varies between 50 and 100 ms.)

Ton

[PaulG.]

Tried your test Ton but it still locks up. I have another clue. This vi lets the operator close the FP while the test is running. This portion of the code opens the FP when the test is almost finished. If I leave the FP open it fails >50% of the time. It works a lot better (but not consistently) if I close the FP after I start the test and let the vi open the FP. As a workaround I tried adding a close front panel, wait 1000 ms then open FP. It's ugly but it works *better*, but not consistenly. This is a dog of a problem.

[TCPlomp]

So you are positive the while loop should be able to run?

How many loops does the loop run?

You have a reference to the VI, is that this vi?

Any errors?

I'm not sure, but is the OpenG wait VI made reentrant? (it might be waiting on finishing another instance).

Is ther an event loop in the VI? (perhaps checking the 'close FP'  event). Does the 'open FP' node cause an error on an allready open VI?

Does it happen in 'execution highlighting' as well?

Ton

[GregFreeman]

Does it lock up after or before pressing the stop button? If it's after you press finish, could it be that you are using the fp.close method even though you are using the open front panel property?

[Mark_Yedinak]

---

@TCPlomp wrote:

I'm not sure, but is the OpenG wait VI made reentrant? (it might be waiting on finishing another instance).

Ton

---

From my experience no, the OpenG wait is not reentrant.

Paul, why are you using the wait in the loop in the first place. Simply put the wait on the dequeue. If data is present it will grab it. If not, this will hold off the loop. Waiting on a queue does not use any CPU resources.

[Mads]

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

The code does look a bit unclean; the way it does not handle errors from the queue, that it has a 0 timeout but keeps on calling the concatinate regardless of the output, the fact that there is an array that goes in and out with shift registers even though no processing is done on it (unlike in a for-loop there is no risk of it getting emptied at the exit due to a zero-run e.g.)...but still, the part of the code that is shown on the picture does not reveal any obious reasons as far as I can see. If we had the VI and could debug it I'm sure the source could be found though...perhaps you could strip off everything you can without losing the freeze, and post it here?

[PaulG.]

Ton:

The while loop runs. I can see iterations counting. It counts until I abort it.

The ref is to this vi.

I've removed all OpenG waits just in case.

There are two event loops. One in the main. Another in a small parallel loop, event timeout -1. That is where the text is coming from that the queue is waiting on. I deselected "lock front panel .." no help.

It happens in highlight execution mode as well.

Greg:

It locks up before it gets to the loop.

MTO:

This is the way it was originally written. Just trying everything right now. The queue my get text data a number of times, the reason for the shift register. Everything else is just passed through.