Creating Installer for Executable - does the NI dependent software get automatically installed?

[JimB.]

---

@Matt_AM wrote:

Problem:

I have code that uses XNET, DAQmx, and Python to control communications to a motor.  When I build the executable and run it on my PC, everything works fine (thank you conditional disable loops for RUN_TIME_ENGINE == True for relative pathing).

---

I'd generally avoid needing different relative paths, but if it's working you do you.

---

@Matt_AM wrote:

However, the run arrow is disabled and when I click on it, I get a 46308 error.  I am assuming since the executable runs on my dev machine that I don't have a problem with the executable itself, but the new PC.

---

You aren't actually intending to use the Run arrow in an EXE are you?

If so, you have a major architectural issue right off the bat. Whatever you have set as the Startup VI is what your EXE will automatically start running at the beginning of execution. The Run and Abort buttons are debugging tools; they shouldn't even be visible in a built EXE.

---

@Matt_AM wrote:

The next step would be to verify that all NI and third party drivers are installed on the deployed PC.  I went to search for NI MAX to see what was installed and I don't see it.  I assumed since my code calls the XNET, DAQmx, and Python modules that the modules would be included when the installer is created.  

---

Have you tried carefully examining everything that shows up in the Dependencies section of the project manager? Are you absolutely certain that everything you call dynamically is included?

---

@Matt_AM wrote:

How can I force the installer to also install the Python module or will that have to be an auxiliary installation?

---

It's not possible to package anything aside from NI installers using the Additional Installers section.

You could theoretically use the run executable options on the Advanced page, but I've generally found it better to put together a package that scripts the installation of everything, including my LabVIEW application's installer.

[Matt_AM]

---

@JimB. wrote:
You aren't actually intending to use the Run arrow in an EXE are you?

If so, you have a major architectural issue right off the bat. Whatever you have set as the Startup VI is what your EXE will automatically start running at the beginning of execution. The Run and Abort buttons are debugging tools

---

No, I plan to have the executable run right off the bat.  However, when I build the current executable and deploy it on a PC without a full copy of LV installed, it automatically has the run arrow broken and when I press the run arrow, I get the "Error 46308" popup.  However, if I run the executable on a PC with a full copy of LV, the executable starts running automatically.

That being said, I also need to include the "quit labview" code at the end of the code in the runtime environment. 

---

Have you tried carefully examining everything that shows up in the Dependencies section of the project manager? Are you absolutely certain that everything you call dynamically is included?

---

As far as I can tell, yes.  The only thing I call ansynconously is the popup in the from the PS Class.  I try my best to not use async calls to code because I like the traceability of the wires.  I like the DQMH framework more than Actor Framework because I think the actor framework abstracts too much traceability of code from other devs that aren't familiar with the framework compared to DQMH.

That being said, I have noticed that one of the instr.vi drivers calls a library in the instr.vi directory and that directory is included in the support directory, "data", when I build the executable.

---

It's not possible to package anything aside from NI installers using the Additional Installers section.

You could theoretically use the run executable options on the Advanced page, but I've generally found it better to put together a package that scripts the installation of everything, including my LabVIEW application's installer.

---

The only other stuff I *should* need installed is Python with the psutil package included, which has been installed on the deployed PC.  I say should because, if memory serves, I use the basic LV blocks, some math Vis (Mean.vi), NI VISA, DAQmx, and Python node in this code.

---

I'd generally avoid needing different relative paths, but if it's working you do you.

---

Relative pathing is the only way I can think of to reference the python scripts needed for my code without having to update the direct file location every time.  My logic being that it is easier to copy/paste the code to different PC's (TBH, the dev PC wasn't the actual PC running the initial testing. I would have to push that code to the testing PC to modify and verify that it worked then push it back to my PC for version control).  

Matt

[Matt_AM]

Got leads for Monday, I found this page which has a bunch of info for vi server properties and methods not supported in LV RTE.

Wouldn't you know it, VI Path and VI Name are two properties that can't be used under certain conditions.

I am not sure if my code does go through the StaticViReference Properties or not, I'm assuming yes based on the image below

Edit: Looks like I dont have leads, I went around troubleshooting in a different way and included the code that I thought was bad into my troubleshooting EXE (below) and it runs fine on the deployed PC.  Hindsight says I should have done this earlier.

Matt

[JimB.]

---

@Matt_AM wrote:

---

---

Relative pathing is the only way I can think of to reference the python scripts needed for my code without having to update the direct file location every time.  My logic being that it is easier to copy/paste the code to different PC's (TBH, the dev PC wasn't the actual PC running the initial testing. I would have to push that code to the testing PC to modify and verify that it worked then push it back to my PC for version control).  

---

I typically handle this in one of two ways:

1. If I am deploying the scripts, or any other asset really, along with my application by referencing them as files to include in my build spec, then I structure my project such that the relative path remains the same. I use the Application Directory VI to find the base path. which will point to the project folder in the dev environment and the folder where the exe resides in the runtime environment. So if I have the default setup where (IIRC) the application builder will put such things under a Data subfolder, then I also keep them in a Data subfolder in my project.
2. If these are scripts that are deployed separately, then I don't trust they will always be in the same spot or even present at all. I may distribute the application with the expected path set as the default, but I will both add logic to make sure the file exists before calling it and add an entry to whatever method I'm using to store my app's configuration (ini, json, sqlite, whatever...) to allow this to be changed. (If you're happy with a simple ini file, you can use the Configuration File VIs to do this.)

[Matt_AM · Accepted solution]

I got the executable fixed and it can run.  Have an issue now with getting python to call a module, but thats a different conversation.  

Digressing, I posted on the lavag forums and you can see the detailed discussion via the link.  The TLDR; version is that the SNDCSDLM.dll library required another LabWINDOWS/CLI library combined with me doing the factory pattern incorrectly.  

Apparently LabWINDOWS/CLI is forwards compatible after like 2015/2016 and the secondary dependent CLI dll requires a specific version of LabWINDOWS/CLI to get things working that wasn't included in the installer for the main executable.  The lavag post has a user who posted a dependency walker which was used to determine that the SNDCSDLM.dll required the CLI dll and is how I found out about it.  I assumed LV installers are "smart enough" to pull the dependencies of dependencies, which to be fair, the installer is including a CLI version when the executable's installer runs.  My situation appears to be an edge case with CLI DLL requiring a specific version of CLI for the executable. I didn't track down which version is required.  I contacted the MFC (Amatec) of the dll but that PS 2-0 child is a Sorenson which was bought by Amatec and I haven't gotten any information of which version of LV/CLI was used to create the DLL, so I redid the executable to remove the PS 2-0 child.  

As for the bad OO design, it stemmed from my misunderstanding of how the factory pattern is supposed to be initialized and I broke OO philosophy.  When I initialized the PS 2-0 child, I dropped all child classes into a case structure that was selected by a type deff enum.  This then forced the PS 2-0 Class to have all children associated with it to be included in the executable and since the CLI dll would cause a broken run arrow, any child PS 2-0 class I would run made the executable fail to run.  To counter this, I am now using relative pathing to path to the desired child class then using the "get default class object" vi combined with a "to more specific" VI to load the proper PS 2-0 child.  From there, I removed the PS 2-0 child that is associated with the SNDCSDLM.dll from the always include section of my executable and now my code is able to run.

It was a long process and I wanted to document that a solution was found.  Hopefully anyone suffering from this problem in the future has an easier time troubleshooting than I. 

Matt 

Matt