How to package instrument driver in the user.lib or instr.lib directory

[doradorachan]

Hey guys,

I currently am using bunch of instrument drivers in my project.

In the VI form it works fine, but I noticed that once converted to an executable,

there are errors regarding the DLL that the drivers are calling.

Apparently the driver VI check if its being called in an VI or executable based on the current directory.

I dont think this is good/correct programming to begin with... but anyways since this driver is

saved in the instr.lib directory of LabVIEW, when I call it from the executable the default path becomes

XXX.exe/1abvi3w/instr.lib/.../.../VI above.vi

I saw this post  which talks about how vi's in instr.lib and user.lib will get the path 1abvi3w in an executable but never talked about how to deal with it.

so my question is can i solve this problem smoothly without copying the entire driver.lvlib into my project and

editing the VI above? i am fine with creating wrappers for driver vi's but would to like to avoid editing the driver vi's themselves.

[Dennis_Knutson]

For your IVI drivers, you have to run the same installers that you originally ran to put the drivers on your local pc. Unless you are calling the wrapper VIs dynamically, they should be included in your exe. No changes to them are required.

[doradorachan]

I am currently running the executable on the development computer so installation is already done.

This isnt about dll's not on the computer, its's about getting the right path to use them.

[HollyBerry]

Have you built a debuggable exe and monitored the file path using probes? 

You may also want to start from a more default directory location (the default directory constant) since the built exe will have a different path than the VI directory. 

[doradorachan]

yes I built an debuggable executable to see the paths. I created a simple VI in the instrument driver library to show what the paths looks like. The subVI just has the same file constants laid out.

I was hoping for a clean solution (i.e. add the instrument driver library to this section of the project..)

but i guess we just have conclude that the instrument driver was poorly programmed and needs to be edited.

[tst]

---

@doradorachan wrote:

I dont think this is good/correct programming to begin with...

---

I don't disagree, but there is a reason this code was written like that (you might note that it doesn't actually work) - before 2009, EXEs were built as flat directory, so stripping twice would bring you to the folder. Because of the addition of libraries, where different files have different names, this was no longer possible, so 2009 builds the EXE as a zipped hierarchy of folders, which is why the check for a folder succeeds even inside the EXE.

There are a couple of things you can do:

1. Replace the VI path with the Application Directory primitive. This is designed to function differently in an EXE. Understandably, you don't want to do that.
2. Check the 8.x checkbox in the advanced page of the build settings. This will make the code work correctly, but if there's LVOOP code with VIs of the same name anywhere, it will create extra folders that you need to move around with the EXE.
3. Add the driver to the project (just the lvproj, don't actually copy the files) and then set an explicit destination in the build for its VIs as an LLB in the data folder. This will place the driver VIs in an wLLB, which is external to the EXE and should then strip correctly. I can't say I have much experience with this, but I'm assuming it should also work with code that was originally in user.lib. This is probably the cleanest solution in terms of number of files because you only have one extra file.

[doradorachan]

---

I don't disagree, but there is a reason this code was written like that (you might note that it doesn't actually work) -

---

I didn't want to sound like I was criticizing but I totally understand that the driver was written in an older version of LabVIEW so it had to be programmed differently.

---

1. Replace the VI path with the Application Directory primitive. This is designed to function differently in an EXE. Understandably, you don't want to do that.
2. Check the 8.x checkbox in the advanced page of the build settings. This will make the code work correctly, but if there's LVOOP code with VIs of the same name anywhere, it will create extra folders that you need to move around with the EXE.
3. Add the driver to the project (just the lvproj, don't actually copy the files) and then set an explicit destination in the build for its VIs as an LLB in the data folder. This will place the driver VIs in an wLLB, which is external to the EXE and should then strip correctly. I can't say I have much experience with this, but I'm assuming it should also work with code that was originally in user.lib. This is probably the cleanest solution in terms of number of files because you only have one extra file.

---

I thought about 2 but I would have to adjust the rest of my code to it and I dont think it would be beneficial for future purposes.

3 definitely sounds promising, so I shall try it out when I have the time. Thanks.