Calling a VI out of PPF in the VI's project context: VI hangs

[BalazsB]

Hi,

I found an issue with "Application Directory.vi" when its called from Project Provider Framework's context (PPF). (Probably it’s not the only issue, but I was able to reproduce only with this VI.)

The issue in detail:
I have a project (TestProviderProject) to illustrate the problem. In the project there is a VI called "getApplicationDirectory.vi" which contains the "Application Directory.vi" VI.
When I try to run "getApplicationDirectory.vi" from PPF (with a right-click menu) the VI just hangs and waits for "Application Directory.vi" to finish.

I need to run the VI in the project's context (not in PPF's context) because the execution is very slow when it’s run in the PPF’s context (the reason being that all dependent VIs need to be loaded into the PPF’s context, which takes long if the project is big). Note that if I run the VI in the PPF's context, the VI executes fine (no hang). Here is the corresponding code snippet in the plugin where I define the execution context:

I used LabVIEW 2015 32 bit. The project and the PPF code is in the zip file.

(

• Unzip "TestProvider.zip"
• Merge "Providers" folder with "<LabVIEW>\resource\Framework\Providers"
• Restart LabVIEW
• Open the TestProviderProject and right click on "getApplicationDirectory.vi", then select TestProvider --> Run VI

)

What could be a possible solution to this problem?

Thanks,
Balazs

[David_L]

Hi Balazs,

I did a bit of troubleshooting on this and it seems that the "Application Directory" VI contains a few Application property nodes which seem to hang in the provider context.  As a workaround, have you tried using mxLvGetProjectPath.vi in order to get the Project Path?  Is there a specific reason you need to use "Application DIrectory" VI and not the mxLv specific VI?

David

[BalazsB]

Hi David_L,

The specific reason I have to use the "Application Directory" VI is that I cannot change the code which contains this VI so this was just a demonstration of the problem in a small project. Furthermore as I mentioned before there are other similar issues, but I can only reproduce this one.

Balazs

[David_L]

I see.  In this case it seems that the only solution would be to call the code in a different context that doesn't hang or to change the code being called to not use Application property nodes.  I'll report this bug to R&D, but it's not highly likely to be fixed in the near future and when it does would only be fixed in newer versions of LabVIEW.  If you're creating an add-on that will be used in older versions of LabVIEW you'll have to workaround the issue.

Sorry I didn't have a better answer for you, but let me know if you have any further questions on this.

[David_L]

For reference, this was reported to R&D as CAR 654834.

[BalazsB]

Hi David,

thanks a lot. I wonder how UTF is able to workaround the issue as UTF is also implemented as a plugin. I see though that UTF is not a regular plugin as it is implemented using "MXX" files. I couldn't find anything about this technology (MXX). Do you know any information about the usage of MXX files? My current hope is that we can workaround above problem in the manner of UTF/MXX. Does it make sense?

Balazs

[BalazsB]

Hi,

it turned out that the root cause is a blocking call inside TestProvider_Item_OnCommand.vi (part of PPF). It may be the case the code inside this VI (e.g., calling getApplicationDirectory.vi) hangs due to some circular dependencies (across PPF and custom code).

A possible workaround is to asynchronously call an auxiliary VI with the 0x80 option flag (Prepare to call and forget), in which the custom code (e.g., getApplicationDirectory.vi) can be executed. As a result, the call to the PPF (TestProvider_Item_OnCommand.vi) can return (resources are released), and the custom code can run without blocking.

I used my original project and added this workaround. I attach the fixed project.

Best,
Balazs