Labview DLL calling subvi's with VI server not working on LV runtime machine

[phil_prismtc]

Hi all,

I have built a LV dll that includes a VI server call to a vi (which has sub VIs). I have verified the file paths are all correct. I have included the (VI server called) VI dynamically in the application builder. I have a VB app that calls the dll.

The whole process works brilliantly on PC's with LV development systemd installed but not on a machine with LV runtime only.

On the develpoment machines ..
The VB app calls the LV dll. The dll front panel pops up and the user can interact with it as normal. When the user hits the stop button, the dll front panel closes and returns control to the VB app as well as sending a return value which indicates how the dll was closed (by the user or due to an error etc).

On the LV runtime machine ...
The VB app executes and calls the dll, the dll front panel does not pop up (as it does on the development machines) and the VB app indicates the LV dll has started, then stopped prematurely.

I have tried including all sub VI's of the (VI server called) VI dynamically with the application builder but the result was the same. I am out of ideas.

All help welcome and appreciated.

Regards,
Phil



As an aside, I noticed when I saved the LV VI's using the "save with options" selection (application distribution), LV didn't save any VI's that are called using VI server.

[tst]

I don't have any experience working with LV DLLs, but I would like to ask this - is this working on your development machine from the executable? If so, does it still work if you move the VIs you're opening? I don't know about DLLs, but at least when building EXEs, the paths for the VIs change, because they are included in the EXE. Do you have those VIs on the second PC? Can you check whether this will work as an EXE (build an EXE instead of a DLL and run it yourself to see the result)?

[phil_prismtc]

Unfortunately I need to use a dll, not an exe. The VB application (compiled to an exe) calls the dll. The PC with the development system has only got the VB exe and the DLL on it, no VI's. As I said it runs normally in that environment and the windows task manager shows that the LV runtime engine is being utilised.

To all intents and purposes I believe the same run-time engine on a PC without LV dev system installed should behave the same way.

[tst]

---

@phil_prismtc wrote:
The PC with the development system has only got the VB exe and the DLL on it, no VI's.

---

What do you mean "no VIs"? You said you're calling VIs dynamically. These have to be on the computer. Where are they located? When you build an EXE (and I suppose a DLL as well) any VIs which are included are moved into that file, so their paths change. That's why I made the suggestion about moving the VIs, to see if this is a path problem.
Other than this, there are things installed with LV which might not get installed automatically with the run-time engine. That's why I suggested (and suggest again) that you try compiling the application to an EXE and running it indepedently TO TEST whether it works or not, not as a replacement for the DLL. When you run it as an EXE with a front panel you can use different kinds of tests to determine the problem (for example, whether your VIs were found or not). Hope this helps.

[phil_prismtc]

Thanks for your help. Problem solved !!

I followed your advice and compiled an EXE to test the system. When I ran it on an LVRT PC I found it was looking for several other dll's. Upon investigation I realised the required dll's are all part of NI-DAQ (mx). Once I installed the NI-DAQ drivers, everything worked, including the original dll.

I assumed the DAQmx VIs that were included in the build list (for the dll/exe) eliminated the need to install NI-DAQ on the LVRT PC. My mistake.

Thanks heaps for your advice and help