LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Race conditions with UI thread


@Florian.Ludwig wrote:

Hi all,

 

I'm having a hard time reproducing the error as it happens only very sporadically. I could only do it once since yesterday. But then it kept throwing the error until I stopped the programm.

Since then I have restarted the program numerous times in an effort to reproduce the error to no avail. I can't really test if any measures make it show more or less that way.

 

The principal error pattern remains the same whenever the error shows:

The instruction inside a sub-vi (in this case an invoke node to display its frontpanel) is not finished but the sub-vi "claims" it is by delivering data to its outputs, therefore triggering other code downstream to execute. If that code is expecting finished execution of the sub-vi there will be trouble.

 

Is there a way to make sure the code inside a sub-vi is completely executed (even the parts running in the UI thread) before it signals "I'm done" to the rest of the code?

If there was a simple switch, or even a workaound that needs to be placed in the sub-vi in question that would help me tremendously.

 

Best regards

Florian


I guess you can add a FP.state-property to check/wait until it defacto has opened, or simply add a 100ms wait.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 11 of 14
(481 Views)

Thanks,

 

that FP.state check will probably solve this specific issue. I will probably go with that or Norberts suggestion of putting the invoke node in the mani vi.

It wouldn't have solved the issue with the x-y graph though.

A general solution for this kind of problem would be nice.

 

The more I think about it the more I feel that the way this is implemented by NI violates dataflow.

 

Best regards

Florian

0 Kudos
Message 12 of 14
(476 Views)

Update:

 

I found a way to reliably reproduce the error in my original app. I just close the fp of the sub-vi programmatically downstream.

Mashing the Button to open it fast enough will produce the error quickly.

So I could finally test the following.

 

Checking for FP.status in a while loop inside the sub-vi until ok: doesn't help Smiley Surprised

Opening the sub-vi's FP in caller: doesn't help

Aligning LabVIEW.exe to one core only: doesn't seem to change the number of clicks needed to produce the error.

 

Will try to condense this into an example now.

 

Best regards

Florian

0 Kudos
Message 13 of 14
(467 Views)

Update:

 


Florian.Ludwig wrote:

 

I found a way to reliably reproduce the error in my original app.


No I didn't.

I made a mistake in my attempt to reproduce the issue - sorry.

 

I'm still working on it.

 

Best regards

Florian

0 Kudos
Message 14 of 14
(424 Views)