Failed to run parallel path when using call library function node in LV2009

[Rob65]

I have a problem with two parallel paths not being run in parallel on LabView 2009.

See the image below.

This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.

The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.

This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.

Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.

Is there some limit on parallel threads that is different in 2009 than in other versions ?

Or is there some other problem in 2009 that might cause this problem ?

My labview version is 9.0f3 (32-bit).

Regards,

Rob

[ThiCop]

Hello Rob,

Is it possible to share the VI (and its subVI's)?

This will allow me to do some tests at my side.

My first guess (without testing it) would be that the problem is with the sequence structure.

Are you by any chance calling this VI inside another sequence structure in your "not-correctly working application"?

Can you provide us with a simple example that illustrates where it goes wrong in the calling VI/application.

Thanks in advance!

[Rob65]

Hi Thierry,

Thanks for your help.

Unfortunately I cannot share the full set of VIs.

This is the first VI using the sequence structure and this is one of the first steps in the application that execute: the main.vi calls a VI that is configured as a modal dialog box and this dialog runs the code from the attached diagram. Both those VIs contain a state machine (while loop with case structure inside).

Since this problem only appears in LV2009 I was hoping this was some kind of setting I missed.

I will try to create a smaller test application to reproduce the problem next week or so.

Cheers,

Rob

[Ben]

Shot in the dark...

If the sub-VIs are configured to run in the same thread as the caller and the caller runs in the UI thread (wchich is single threaded) then no pralllel tasks.

Ben

[JÞB]

---

@Ben wrote:

Shot in the dark...

If the sub-VIs are configured to run in the same thread as the caller and the caller runs in the UI thread (wchich is single threaded) then no pralllel tasks.

Ben

---

Or the CLFNs are set to run in UI Thread.  Nice pointer Ben.  (The color says they probably are)

[JÞB]

As I recall, (going by memory alone)  CINs were depeciated between 8.6 and 2009 and the mutation caused all CIN to be converted to CLNFs without looking to see if the DLL was threadsafe and defaulting to run in UI Thread.  The 2010 compiler got just a bit smarter (since a lot of threadsafe calls suddenly ran in the UI and caused a bunch of headaces)

[Rob65]

---

@Ben wrote:

Shot in the dark...

If the sub-VIs are configured to run in the same thread as the caller and the caller runs in the UI thread (wchich is single threaded) then no pralllel tasks.

Ben

---

That's about the first thing I checked (should have mentioned this ...) All VIs have the "preferred execution system" set to "same as caller" (none have the UI thread) and the CLFNs are set to run in any thread.

And it all works in LV7, 8 and 2011 just not in 2009.

An yes Jeff, thanks for the hint. I do remember 2010 becoming 'smarter' - just discover that again a few weeks ago ...

Rob

[Ben]

---

@Rob65 wrote:

---

@Ben wrote:

Shot in the dark...

If the sub-VIs are configured to run in the same thread as the caller and the caller runs in the UI thread (wchich is single threaded) then no pralllel tasks.

Ben

---

That's about the first thing I checked (should have mentioned this ...) All VIs have the "preferred execution system" set to "same as caller" (none have the UI thread) and the CLFNs are set to run in any thread.

And it all works in LV7, 8 and 2011 just not in 2009.

An yes Jeff, thanks for the hint. I do remember 2010 becoming 'smarter' - just discover that again a few weeks ago ...

Rob

---

A question I can not answer off-hand is "What thread does a modal VI run in?"

Ben

[ThiCop]

Hello,

In LV 2012 a simple VI running top level with "same as caller" will run in the "standard" thread. (I have seen some exceptions)

In LV 2009 I'm not a 100% sure about this.

I don't have 2009 installed on my local pc so I cannot check it in 5 minutes. 

To check this you could use the Desktop Execution Trace Toolkit (DETT).

Rob, do you have DETT installed on your LV 2009 pc?

[Rob65]

I've just installed the DETT tool and checked what the different versions of LabView do.

In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.

In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.

So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...

When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.

I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.

To answer Ben's question: "What thread does a modal VI run in?":

In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.

In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.

Thanks,

Rob