Using a vi that relies on a DLL in Python

[cw_muse]

My VI currently has a constructor node that calls a .dll file and has some invoke nodes that use functions specified in the .dll file. 

I want to be able to use this VI in python so I converted the VI into a DLL file which I can call in Python. Building the VI into the DLL was successful. Now, when I call the DLL file in python, the python file runs; however the constructor node and the invoke nodes in my VI don't seem run. Can someone give me tips on being able to use VIs that rely on .dll files in Python?

[wiebe@CARYA]

Make sure the dll can access all it's dependencies.

Add error handling (either a dialog or an output) so you get more feedback on the problem.

Does the VI run? You can test with a message box.

[billko]

---

wiebe@CARYA wrote:

Make sure the dll can access all it's dependencies.

Add error handling (either a dialog or an output) so you get more feedback on the problem.

Does the VI run? You can test with a message box.

---

I prefer to use the "beep.vi" to the message box because if you have an unexpected looping issue (I run into this sometimes at the very early stages of development when I might forget to put a manual exit on a loop with coding "in progress" and click the run button), you'll likely never be fast enough to acknowledge the message box and abort the execution before the modal message box comes up again.  With the beep.vi, you get the annoying "ding" sound when the VI executes, but you'll still be able to abort the execution.

[wiebe@CARYA]

Well, the message box will display an error if there is one. A matter of taste and situation...

[cw_muse]

If VI converted into DLL file and the DLL file is called in Python, is it possible that the VI can to open and executes another VI reference when python executes the DLL file? 

[rolfk]

Yes, but there are a number of caveats to observe:

- The VI must be compiled with object code included in the VI (no separated object code). and must have been compiled with the same LabVIEW version that was used to create the DLL.

- All the subVIs that VI is using must be at the same location relative to that VI as they were when the VI was compiled and saved.

- You get most likely trouble if that VI is using subVIs that happen to exist with the same qualified name in the compiled DLL VI.