error 1003 when using call by reference

[RobCole]

We have had a lot of difficulty with dynamically called VIs as well.

One of the things that we always had to do was to open all VIs (open the main VI first and then open all of the dynamically called VIs). Then do a "Save All". This will ensure that all subVIs are looked for in the correct location. Build your executable after the "Save All" and ensure that you are calling the newly saved VIs as well (if you need to copy them into a new location).

Dynamically calling external VIs is always a pain.

     Rob

[RobBoyer]

Thanks for the info guys,

Rob: That's a good suggestion, but unfortunately, I've already tried it without success.  In any case, I don't believe that I have any cross-linked VIs - I can open up all of them without LabVIEW performing any automatic conflict resolution.  And yet, as soon as I try and run the executable created from these conflict-free VIs, the dynamic calls throw error 1003.  It would kind of make sense if somehow the VIs that were being bundled into the executable were interfering with the original VIs being called from the plugin VIs - but I just put together a simple program to do exactly that, and it ran fine...  There's something fishy here. 😕

Maybe it makes more sense to go down the path of creating DLLs out of each plugin VI.  I would think that might resolve this issue.

Take care,

Rob

[RobCole]

All of our plug-in VIs are in .DLLs. We rarely make anything that has only one VI. So all sub-VIs are stored in the .DLL.

You can also try a "Save With Options..." and save ALL VIs to a .DLL. This will make for larger .DLLs but if it works...

And it will at least tell you if it is a linking problem into VIs in the main VI.

     Rob

[MarkBlack]

Here is a Knowledge Base article (KB) on this topic.

My Plug-In Application (EXE) Is Not Calling My Plug-Ins Correctly


There is another KB relating to this topic that is not showing up in the stardard ni.com search.  I will be looking into this and hopefully posting it later. 

[RobBoyer]

Thanks you very much BLAQmx - that is precisely the information I was looking for.  Rob: I'll be trying the idea of bundling the plug-ins and all dependent subVIs into LLBs - I assume that's what you meant...  DLLs are very different beasts.

Thanks to everyone - this discussion group is the reason I have never actually thrown my monitor.  🙂

Rob

[RobBoyer]

By the way - for anyone reading this link:  Please note that my previous attempt at explaining what was happening with shared subVIs causing the problem, etc, was completely wrong.  In my case, the problem turned out to be that my application could not find some vi.lib and user.lib standard VIs because they were only referenced by the dynamically called plug-in VIs.  By simply adding the vi.lib\* and user.lib\* path to the application .ini file, the problem has been resolved.

And as a recommendation to NI - please, please, make the error messages more useful, or at least add some optional tracing capabilities.  Maybe newer versions have resolved this, but if not, this will keep LabVIEW from being a world-class development tool in many peoples' minds.

Thanks again!

Rob