01-21-2009 02:57 AM
Hi there,
I have a workspace with several real-time DLL projects:
ControlManager: the DLL with the RTmain function, so it can function as the Startup DLL
RemoteControl, MotionControl, DataManager, EventLog: support DLL's with DllMain supplying needed functionality for the ControlManager.
When I manually copy the support DLL's and then Run->Install Program...... the ControlManager, my RT-Target gets all the files needed and works using my latest DLL's, without any explicit run-time loading of any DLL.
So far I haven't found any way to make the "Run->Install Prog....." automatically update my support DLL's although I have included the .lib files for each support DLL in my ControlManager project.
The auto-increment option for the version info doesn't help either, worse yet; it seems to increment after the install and nags about the project release configuration being out of date when I want to install the DLL again, forcing me to build again , thereby incrementing the version again (vicious circle).
Does anybody know why LabWindows/CVI does not seem to be willing to do this not so uncommon task for the lazy programmer and save him the bother of having to manually update his support DLL's?
Thanks in advance,
Aart.
01-21-2009 10:56 AM
The Run>>Install Program to Real-Time Execution Target option behaves very similarly to when you start debugging a RT DLL. There is currently no mechanism to detect changes in loaded dependency DLLs or to force an update if those dependency DLLs are already present on the target. I will file a request to have your situation considered.
For now, you could write a simple batch file to ftp your support DLLs to the target, then add it to the Tools menu via Tools>>Customize. Of course this still requires you to do two separate things each time you want to redeploy your application, and your batch file will have to be updated if you change target machines or source paths. It may still be convenient for you though.
Mert A.
National Instruments
02-25-2009 11:45 AM
Hi Aart,
It turns out that my previous response was incorrect. If you follow a couple (unofficial) guidelines, CVI does do a good job of finding and copying your project's DLL dependencies as needed:
The reason for the first guideline is that CVI only looks for your support DLLs next to the main DLL. If it can't find them there, it won't be able to FTP them to the RT target.
The reason for the second guideline is that CVI first attempts a LoadLibrary on the main DLL on the target before transferring any dependency DLLs. If the main DLL loads successfully on the first try -- which is the case if your support DLLs can be found in the system directory -- then CVI assumes it does not need to copy/update any dependencies. If the DLL does not load, CVI determines its missing dependencies and FTPs the DLLs over.
As for the third bullet point, the installation process puts the DLLs in the NI-RT\CVI, whereas just debugging an RT project puts the files in NI-RT\CVI\temp. The temp subdirectory is not part of the system's DLL search path, but the parent CVI directory is. So if your dependency DLLs can be found in that directory, your main DLL will load on the first try, and CVI won't copy over the newer versions of the dependency DLLs.
Hopefully these guidelines will help you for now. We'll try to make the experience better in a future release.
Mert A.
National Instruments