Executable error 46308 - PC needs a full development copy of LabVIEW to run the executable. My PS 2-0 Class is causing this issue but I don't know why.

[Matt_AM]

Hey Fancy Folk,

 

I am running into an executable error that I was hoping someone could point me in the right direction to start troubleshooting.  

 

TLDR: I can build and deploy an executable on my PC and another dev PC and the executable runs fine.  However, when I deploy it on a PC without a full LV dev kit, I get error 46308 and it states that the PC needs a full development version of LV to run.  I have narrowed my problem down to my code calling my PS 2-0 class through building a secondary executable and including different classes to see what is causing my problem.  

 

Long version:

I've been troubleshooting this problem for about a week now and I feel like I am still lost in the woods.  I have posted it over on the official NI forums here, but I haven't had success in solving the problem.  

 

I built the executable and an installer and installed said installer on a new PC (booted up for the first time 2 weeks ago).  I have also installed Python 3.9 and the required toolkits so the python code can execute.  I did not add anything to the OS pathing found on this white page.  I am not sure if I did any pathing on my dev PC or the dev PC that was running the original test and when I checked the dev PC, nothing popped out that looks like I would have added it.  The executable runs fine on my PC and other dev PCs but won't work on the new PC (deployed PC).

 

My code uses DAQmx, Python, and COM VISAs and Instr VISAs.  I have added in all the individual parts and things work as expected.  However, when I add in my PS 2-0 class, I get error 46308 which states the executable needs a full development copy of LabVIEW to run.  I have tried various things to solve my problem, but I am still getting the same error.  I created a secondary executable and added in my Python classes and children, State machine classes and children, and PS 2-0 classes and children and rebuilt/deployed in sections.  When I add in the PS 2-0 class, the executable gives me the error. I have verified there are no breakpoints in my code with VI analyzer and I ran that on the PS 2-0 classes and the dependencies section of the project to verify there were no breakpoints still set. It looks like no matter which PS 2-0 child class I use will cause my error.  

 

I'm not sure what I need to provide for someone to help with the troubleshooting process.  I am assuming you'd need my PS 2-0 class and I can provide that if needed.  None of it is proprietary and its basically an abstract factory architecture for the PS 2-0 class with DD to override based on the child PS 2-0 class.  All the Children classes call the drivers from the MFC and I haven't added anything besides a wrappers to the MFC's VI's. I will say that some of the driver VIs are built for old version of LV so there may be some issues with those drivers? The code is attached to this post.  I seem to still have an issue with the SNDCSDLM.dll file being called from the 2022 instr.vi, but it is also included in the zip file.  Note, I'm still failry new to OO and this was my first attempt at it.  let me know if I did a bad job because I can't get better without learning from people who are better than me.  

 

The last thing I tried was looking at the way I am doing an async call to a popup (code below).  I found an article that showed which VI server property and methods aren't available in the RTE and I noticed that VI Path and VI Name are two of those, but it looks like those can't be called under specific circumstances.  

I added this code directly to a secondary executable that I've been using to see which part of my code is throwing the error.  This VI is a simple 2 button state machine (inc a counter and stop the event struct) with the timeout case never being called.  The timeout case is there to get the various parts of my code to "be seen by the RTE" (IDK the proper jargon).  Below is an image of the secondary exe's VI back panel which shows that the above code from the PS 2-0 class is being loaded into the exe.  In this state, the secondary exe can be run just fine on the deployed PC.

However, if I enable the the disabled state (which allows a child class to call a macro to set the voltage), that will cause my executable to throw the error on the deployed PC.  I don't think its an OO problem because the python and state machine classes don't cause issues and also use DD for children to override parent methods.

 

Literally any direction is helpful because I feel like I've been bashing my head against google for waaaay too long and although I've made progress as to which section is failing, I still have 0 idea as to why my PS 2-0 Class could cause issues.  At this point I think it could be something with VI properties in my PS 2-0 children or their dependencies.

 

Thanks

Matt

 

545624572_Matt_AMPS2-0code.zip

Edited May 15, 2023 by Matt_AM

[ShaunR]

18 hours ago, Matt_AM said:

I seem to still have an issue with the SNDCSDLM.dll file being called from the 2022 instr.vi, but it is also included in the zip file

Are any of the DLL's dependencies (if any) missing on the troublesome PC?

[Matt_AM]

37 minutes ago, ShaunR said:

Are any of the DLL's dependencies (if any) missing on the troublesome PC?

I am not sure how to check for that.  Although I've used LV for a long time, I haven't really needed to build executables or installers.  I do include all my classes in my executable and I believe that all the dlls should be included as well.  The image below is from the secondary executable and is meant to show that I am including all the common classes.  As far as I can tell, the SNDCSDLM.dll is the only dll that is associated with my PS 2-0 class and that is set to be always included.  Additionally, it populates in the data subfolder of the executable when the executable is built.

 

[ShaunR]

SNDCSDLM.dll depends on cvirte.dll. You can check it's deployed on the target machine with Dependency Walker. It's always deployed on development machines so maybe that's the issue. Something easy to check and eliminate.

[Rolf Kalbermatter]

21 hours ago, ShaunR said:

SNDCSDLM.dll depends on cvirte.dll. You can check it's deployed on the target machine with Dependency Walker. It's always deployed on development machines so maybe that's the issue. Something easy to check and eliminate.

Shaun already pointed you at the culprit. There is one potential pitfall however. CVIRTE.dll is the same for LabWindows/CVI as is LVRT.dll for LabVIEW. It is the Runtime Engine that contains the entire business and support logic for executing LabWindows/CVI compiled DLLs and executables. And it has similar versions as LabVIEW too. So depending on in which CVI version the DLL was created, you may need to make sure you install the correct CVI Runtime version on that PC. Similar to LabVIEW, CVI also started to use an upwards compatible Runtime library somewhere around 2015 or 2016 I think. But if your DLL was compiled in an earlier version of LabWindows/CVI, things are listening a lot more narrow.

CVIRTE is used by several tools in the NI software stall (Not everything is developed in LabVIEW and not even everything in LabWindows/CVI, some tools are directly developed and compiled in MSVC). But some of the plugins in NI Max such as the instrument control wizard and similar are developed in LabWindows/CVI. So if you install a typical NI Development machine, that runtime library is absolutely sure to be present, but on a minimal LabVIEW runtime only installed machine, it is not automatically there. And none of the typical LabVIEW Additional Installer containers includes it.

The real problem is likely the developer of your SNDCSDLM.dll. S/he would know that they used LabWindows/CVI to compile that DLL and they should have provided a proper installer for this component that also takes care of installing the right version of the CVI Runtime to the target machine. Simply adding such components as a dependency in your LabVIEW project makes you automatically responsible to care about this yourself! And yes it is cumbersome, but there is no easy solution to this, other than the fact that the original developer of a component SHOULD provide a proper installer (and any user of such a component SHOULD include that installer as part of their own application installer rather than just copy the DLL alone into their project).

Edited May 17, 2023 by Rolf Kalbermatter

[Matt_AM]

My heros! I removed the DLM_32_125e class from my executable and it runs on the deployed PC, we are working again! 

 

Thank you so for much for responding.  I didn't know about the dependency walker and that is incredibly helpful.  Like I said earlier, I haven't really worked with executables and installers and knowing that information is vitally important.  

 

Also, thank you for the explanation about DLLs and LabWindows/CVI.  I have never really worked with that software before and I know it exists, but thats about it.  I contacted Ametek about the LabWindows/CVI version it was built with, but I have a feeling that they dont know.  Not trying to throw shade, but the DLM 32 125e is a Sorenson PS. If the story I've heard from the older coworkers is true, Soreson was bought out by Ametek a while ago.  I don't have high hopes that they know what version they used.

 

Edit: I lied.  I forgot to enable the PS 2-0 disable diagram and I am still not being able to execute my code 😕  You guys are still heros though! 

Edited May 17, 2023 by Matt_AM

[Matt_AM]

Question about OO, because I think I am doing it wrong.  In my parent PS 2-0 class' Create VISA based Class, I am using an enum to grab the proper child at run time by dropping the child into a case based off of the enum?  Is this the proper method (image below).  I think I remember reading something somewhere that you should use the "get default class" vi when doing this architecture.  Again, I'm new to OO so if my design is wrong, please let me know so I can make it better. 

Edit: To be honest, I feel like my current method breaks the idea that OO doesn't need all the children to run properly where as my current method does.  It worked for me so I never really questioned it until now.  I included my thoughts about my design and why it's failing at the bottom of this post.  I think I need to use the Get Class default value with relative pathing to call the proper child class.  

 

Additionally, if one method is called from the parent class for a child, will all associated methods for the parent and children be called as well?  I'm sure that statement is word salad to people who understand OO better than I, but I am trying to ask that if I call my Set PS Voltage macro, will the all child classes associated with the PS 2-0 class be loaded into the executable as well based on my current design? (see image below).

Edit: Explicit additional info.  I am trying to ask if the DHP Set PS Voltage is called, will the DLM_32_125e Set PS Voltage also be called with my current initialize code the designed the way that I did?  Additionally, I am not sure if other methods are included with this executable like the Create VISA based Class.

In other words, since I am calling the Set PS Voltage, is only Set PS Voltage for the DHP class loaded into the executable in this case?  

 

For additionally information, I have removed the DLM_32_125e from the always include section as well as the dll.  I just want to verify that in my current test executable, that the code only calls the DHP Set PS Voltage so I can verify that the DLM_32_125e class doesn't have its code being include which could cause my problem.  Below is an image of the executable's always include section.  As you can see, the DLM_32_125e is still in the Project files and I am not sure if I need to fully remove it from my project or not.

When I go to the Preview tab, it looks like the code is still calling the DLM_32_125e.  I am assuming I need to fully remove it from my project for it to work properly.

 

Edit: With the way the executable is set up and how I designed the code, I think I understand why the dll is being include.  Since I am including the child class in my PS 2-0 Create VISA based Class AND am including that class in my executable via the Source Files tab, that it would make sense that all of my classes need to be included in my executable.  I think I need to go down relative pathing to call the proper child class in my enum case.  I just want to make sure I am going down the correct path.  Additionally, since RTE uses a different pathing schematic, will I need to include a conditional disable diagram to grab the proper class in dev and RTE?  I am assuming yes.  I use application directory as my starting point for relative pathing typically, should I use that or the VI path in this case.  I'm not sure which pathing is correct in an executable while also wanting my pathing relative to my PS 2-0 Class due to the folder hierarchy I have (image below).

Edited May 17, 2023 by Matt_AM

[Rolf Kalbermatter]

16 minutes ago, Matt_AM said:

Question about OO, because I think I am doing it wrong.  In my parent PS 2-0 class' Create VISA based Class, I am using an enum to grab the proper child at run time by dropping the child into a case based off of the enum.  Is this the proper method (image below).  I think I remember reading something somewhere that you should use the "get default class" vi when doing this architecture.  Again, I'm new to OO so if my design is wrong, please let me know so I can make it better.

This absolutely will pull every class in that case structure into your VI hierarchy. And if any of them is not executable (for instance because it calls a DLL whose dependencies is not satisfied) your VI here (and the whole class it is a member of) will have a broken executable status.

The idea with using the Get Default Value for a class is exactly to avoid that. If you resolve the class at runtime with the Get Default Value function it does not matter if any of the classes that you may eventually call is present or not on disk, or broken or whatever, when trying to load your "Generic" PS2 OO class. It will load and as long as you do not try to instantiate one of the not present or broken classes at runtime, nothing bad will happen.

Only when you indicate to this function to load SNDCSDLM, will it cause a runtime error to the fact that something is wrong with that class when it was trying to load it. If you however only indicate to load and use AG6038A (just to name something) and that class has no problems, you can execute everything and it does not matter that the SNDCSDLM class is not executable for some reason.

But with your current implementation it does matter. The Class constant makes the whole class a static dependency of your VI (and of your entire Power Supply 2.0 class) and if any of the class members of SNDCSDLM is broken your entire Power Supply 2.0 class is also broken, even if you never even intend to run the SNDCSDLM class in it.

Edited May 17, 2023 by Rolf Kalbermatter

[Matt_AM]

Thanks for the quick response.  After I sent that message I thought a bit and I 100% agree. I edited my previous post but wasn't fast enough for your response.  

 

Going off my previous post's edit towards the bottom (which wasn't there when you responded originally, my bad), how should I do my relative pathing?  Quoting the edit I made below

Quote

I think I need to go down relative pathing to call the proper child class in my enum case.  I just want to make sure I am going down the correct path.  Additionally, since RTE uses a different pathing schematic, will I need to include a conditional disable diagram to grab the proper class in dev and RTE?  I am assuming yes.  I use application directory as my starting point for relative pathing typically, should I use that or the VI path in this case.  I'm not sure which pathing is correct in an executable while also wanting my pathing relative to my PS 2-0 Class due to the folder hierarchy I have (image below).

 

[Rolf Kalbermatter]

Why do you think your path hierarchy in the RTE needs to be different than on your development system? You should be able to arrange that in a way that there is (almost) no difference!

If you make sure to not enable the LabVIEW 8.0 hierarchy layout in your application build settings, the relative paths inside the executable remain automatically the same. Of course you will need to add all those classes explicitly to the build now, as LabVIEW can't track them as dependency now anymore, since you have no static reference to them. 

Edited May 17, 2023 by Rolf Kalbermatter

[Matt_AM]

2 hours ago, Rolf Kalbermatter said:

Why do you think your path hierarchy in the RTE needs to be different than on your development system? You should be able to arrange that in a way that there is (almost) no difference!

To be honest, its because I don't know any better.  Typically I use the application directory go to support things like the python scripts I need to call for my actual application code.  With RTE, I've noticed the directory path is typically something like C:/.../[Project Name]/Main Proj/[executable name].exe compared to the dev path of C:/.../[Project Name]/Main Proj.  I realize application path is based on my file structure, but I'm trying to give the concrete example that the executable typically needs a different pathing than my dev environment, see image below of the conditional disable structure I use to access the python scripts.  

Digressing, I am not sure how LV handles pathing when building an exe to reference a child class.  Below is an image of my code for the Update Current method.  It is the default PS 2-0 Vi and it launches an asynchronous call to a PS 2-0 popup to let the user know that the method doesn't exist (TBF, I have this as always needs to be override, but the OVP is the exact same logic with a different message).  If I grab the PS 2-0 Create VISA based class's path like the image below then strip and rebuild accordingly, will that work in both RTE and dev environment?  I am not sure how I can access the child classes in the RTE once I put the child classes into the "always include" section via relative pathing.  Do I reference my classes in the dev environment or do I have to include them in the "data" subdirectory that gets created with the exe?

I am assuming that I will have to include the classes in the data subfolder of the executable then path to it like I do for the python scripts with the conditional disable structure to get the correct path to the child class.

 

[Matt_AM]

I went to see how the executable pathing and stuff works and I am not seeing an error with my current setup and I believe that it should work in dev and executable form.  I wanted to get a second set of eyes on my modifications to Create VISA based Class modifications to make sure I did the change over from my original wrong method to the new correct method properly and that the new method will work with RTW and dev environment.  I modified the Create VISA based Class to get it's path then did relative pathing from there to access the child classes on my dev stand. I added two temporary path indicators to see where the VI's paths is and what the modified path to the child class is.  

 

When I build the executable, I set the startup VI as the Create VISA bases Class and always included the PS 2-0 Class and all children except the DLM_125_32e.  The files created on disc for the executable don't have the data subfolder for dependencies (so the bad DLL isn't being called).  When I run the executable, I am not getting an error.  Below are images of my back panel, then the executable's Source Files, then the executable running with my simulation child and TDK Genesis child.  The image of the executable FPs is to show that the simulation works fine and that the TDK fails because I'm not actually talking to TDK Genesis.  Note, the Simulation class doesn't actually call any code, but I would imagine that if the pathing is wrong, there would be an error when using DD to override the generic PS 2-0 Class's Init Class.  Additionally, I did probe the line coming out of the "To More Specific" VI and the "Actual Data Type" is set to the correct child class, refence image below for the probe.

 

Matt