Dear NI Forum:
I have a similar sounding very large scale project with similar issues. I find the new 8.2 builder dreadful.
Because my current project is large scale and must support multiple parallel operating instrument drivers in a robust manner I have modelled it as a main EXE which serves only to read the base configuration files and dynamically launch a series of base services that all instruments need such as error handling, external TCP comms, data logging, H/W watchdogs, etc. and a series of instrument drivers that can all be launched, operated in parallel and then stopped "on demand".
All messaging between dynamically launched VI's and betwen dynamically launched VI's and the main executable is performed using these remote queues. Internally in any given dynamically launched VI, local queues may also be employed if the back panel diagram contains two or more parallel loops .
An outbound comms server simply accepts all acquired data messages from the various instruments and services as it arrives, formats it and sends it on to the VB U/I via its client connection to a socket server in the VB code.
Finally each dynamic VI operates in its own separate thread which also serves to make the whole system
Given this flexible architecture, then my objective is to have a single VI in my executable with no explicitly named dynamically launched VI's and yet be able to dynamically launch VI's using path information stored in an XML file that I have created. This is more flexible in that it allows me to change or add the software without having to issue an entirely new build.
The dynamically launched VI's and their dependent sub-vi's are stored in a source code distribution build.
The installer then includes the EXE and the source code distribution build and installs them in the Program Files directory.
If I later create a new driver for my project then I should simply be able to create a source code distribution folder for that new instrument only and include an updated XML configuration file and the old exeecutable that is already installed should then be able to work with the new driver without requiring any further modifications. This is important in isolating the effects of any code change or expansion to the new code only and insuring a high degree of reliability.
At least that is supposed to be the plan. It all worked beautifully until I tried to create the installer and source code distribution files.
Unfortunately I keep running into various issues with the various builders such as:
1) I am using subversion for my source code control tool. It creates files that are very similar to the actual VI's except that it attaches .base-text to them so that in addition to abc.vi existing, another file called abc.vi.base-text exists. The builder misidentifies the .base-text file as a VI because it apparently is doing a substring match on ".vi" rather than checking to insure that the last three characters ARE .vi.
2) I worked around the SVN problem by creating a separate parallel copy of the code that is NOT controlled by SVN but this means double work because any fixes I do in the uncontrolled code have to also be updated in the controlled version. This effectively defeats all the benefits of source code control.
3) Paths for the dynamically launched VI's and XML file differ between the source code version and the executable version. I had to write a program to test whether I was in source or exe mode and use different base paths accordingly.
4) LabVIEW keeps cross linking VI's when I run builds and/or run the executable while the project view is open so that my original source code VI's become linked to VI's in the source code distribution library that I am creating, either in the builds directory or in the destination "Program Files" directory. This leads to the dreaded "1003" error and I have to hunt down these relinked VI's and put their paths back to where they belong. This is very erratic and hard to prevent.
5) The dependency node on the project view tree allows you to open and browse through the dependent files and acts as though those dependencies are manually editable so that you could manually remove a dependency if you so choose and even prompts you that removing the dependency from the project does not remove the VI from the disk. In reality, however, removing VI's, DLL's, or other files from the dependency subtree of the project view does absolutely nothing. They still end up being included in the source code build distribution.
6) This dependency problem is important because the source code distribution node arbitrarily takes it upon itself to include DLL's not part of the main directory hierarchy of my project and replicate them where IT wants rather than where I need them to be. For instance, I have DLL's located at C:\abc on my machine as opposed to C:\MyProject\... When the source code distribution builder creates the distribution build it creates a parallel directory to MyProject called abc and puts a copy of the original DLL into that parallel directory.
This creates serious problems for me because my application must work with other applications and share the same instance of that DLL, not two separate DLL's with the same name but different paths.
It also poses a problem for code maintenance, what happens if the vendor who shipped me that DLL as part of their hardware driver issues an upgrade? Then I have to create a separate upgrade installer to copy that DLL over to the NI copied DLL.
7) Trying to remove these parallel folders containing the duplicate DLL's from the destination directory pane of the Installer builder after copying the source code distribution over from the source to the destination panes "breaks" the builder dialog. It removes my source code distribution directory name and promotes the sub directories underneath it to the next higher directory level - at least that is what is indicated by the user interface. In reality what happens is that removing one of these parallel folders removes my source code distribution folder entirely from the build.
😎 Dependent VI's located in user.llb, vi.llb, and instr.llb will necessarily be part of the source code distribution because they are contained as sub-vis of my dynamically launched vi's. If I un-check the "exclude" check boxes for these libraries to force their inclusion in my source code distribution, then it WILL build an installer - however if you try to run that installer, it will crash in the process of installing the program and present you with a cryptic and unexplained MSIExec error which you have to research at msdn.microsoft.com and even then you will learn very little about what is wrong with the installer that was created.
If National Instruments is going to use MSIExec as the engine under it's installers "hood" then it needs to provide graceful ways to handle installer exceptions and it needs to provide meaningful error messages that developers can use to troubleshoot and debug any installer errors. Currently there is NO available documentation on this subject at NI.com and the attitude seems to be that the installer will always behave properly and that there will be no errors. The available information on the installer is limited to the patently obvious and is all but useless.
9) Because it is undesireable for my architecture to be forced to declare my dynamically launched VI's as such when initially creating my executable, the source code distribution and dependency walker don't seem to understand whenever I am forced to create a new sub-vi in my project to solve some issue I encounter. The executable builder and the distribution builder and the installer builder happily create their updated targets without the new sub-vi and the frustating thing that occurs is that a perfectly fine source code VI in the source code directory will not work properly when dynamically launched from the destination directory when in executable mode because it will be missing the necessary new sub-vi. This again results in the dreaded "1003" error .
The only way to overcome this problem is to manually add each new VI to the project VI.
I have been working with the help line on these issues for the last week or so and some of these problems have been "worked around" at this point but I think that NI's development people ought to take a look at how to resolve each of the above described problems in a systematic method that is not so painful for their customers who are doing large scale development with dynamic VI's ASAP.
I would be happy to hear any suggestions anyone has to offer me regarding how I can "have my cake and eat it too" in my project, i.e. does anyone know of sure fire ways to work around the above problems so I don't have to substantially modify my source code and/or dump dynamic VI's?
Thanks,
Doug De Clue
Instrumentation Programmer/Test Engineer
DME Corporation, Inc.
Orlando, FL
ddeclue2@earthlink.net
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
