LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Server Methods behave differently in Project Provider Context?

When calling the method "Save Instrument" from the main development context, the following works no prob:

Screen Shot 2012-10-28 at 7.49.08 PM.png

Run this same code in the Project Provider context results in Error 1507 on the method. The workaround is to open an instance of the VI outside of the Project Provider Context, something like this:

Screen Shot 2012-10-28 at 7.48.31 PM.png

When debugging this Error 1507, I kinda just reckoned that opening the VI in the project context would fix the problem -- and it did -- but I have no idea where this (learned?) intuition/hunch came from, or why exactly this fixes the problem. So, to formulate this into a few questions:

  • Is this an appropriate workaround? Or, is it a hack that just happens to not give an error?
  • Is my bug/workaround above very specific/localized to "Save", or is there a superset of scenarios like this to watch out for where VI Server methods may behave differently in the Project Provider context?
  • Can you share other caveats and/or best practices and/or your own experiences using VI Server in the Project Provider context?

Thanks!

0 Kudos
Message 1 of 7
(3,102 Views)

Remember to close all the references for the other application instance, if not you will be able to crash LabVIEW very easy.

I managed to crash LabVIEW 10 times yesterday, when working on my Project Provider.

Also remember that when you add/change something to a project, this might trigger another call to a Provider VI, and if you don't wait until this call is finished you will kill LabVIEW.

So maybe you application works fine, and then someone installed e.g. GDS, that gets called when your code is running, suddenly LabVIEW starts to crash.

My solution is to add lot of waits here and there in my code. 150ms is currently my value and it has been scientifically calculated of course, I could go through the math but I guess it might be too complicated so you just have to trust me.

Keep wiring the labs.

BTW I thought of you when I saw this image:

wifi.png

Cheers,

Mike

Message 2 of 7
(3,055 Views)

<unclosed refs> *blush*

+1 for the code review, and another +1 if I could for the cartoon

Finally, I've not gotten into a scenario where a Provider VI crashes during simultaneous calls -- but will look out for this.

0 Kudos
Message 3 of 7
(3,055 Views)

Jack,

we found out the same in Application Builder Support; some builds could only be completed if they were run in the project context.

There were no crash but LabVIEW would just hang, and we had to force quit.

Mikael; sounds like your memory is getting very short... 😉

"...Remember to close all the references for the other application instance, if not you will be able to crash LabVIEW very easy.

I managed to crash LabVIEW 10 times yesterday..."

/J

Message 4 of 7
(3,055 Views)

Mellroth wrote:

we found out the same in Application Builder Support; some builds could only be completed if they were run in the project context.

If I might ask, how are you invoking the Build Specs? I have used "C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\AppBuilder\AB_API_Simple\Build (project reference).vi" to invoke build specs (a few different kinds) with no prob (so far!) running in the Project Provider context; should I potentially watch out for hangs?

Oh, and for both Mike and Jonas -- I'm working in LV2012 right now, so it's *possible* that some of the issues you describe are now fixed and no longer problems.

0 Kudos
Message 5 of 7
(3,055 Views)

We mainly used <LabVIEW>\vi.lib\AppBuilder\AB_API_Simple\Build.vi, the one you mention does not exist in my versions of LabVIEW (pre-2012).

If I remember correctly the FPGA builds were the ones causing us problem.

/J

0 Kudos
Message 6 of 7
(3,055 Views)

Mellroth wrote:

We mainly used <LabVIEW>\vi.lib\AppBuilder\AB_API_Simple\Build.vi, the one you mention does not exist in my versions of LabVIEW (pre-2012).

If I remember correctly the FPGA builds were the ones causing us problem.   

Good info, thanks -- if it's FPGA build acting up, I can defer this potential pitfall a little while longer... (I have built EXE, Installer, and Source Distribution with no problems)

0 Kudos
Message 7 of 7
(3,055 Views)