LabVIEW
Real-time application works in development but is broken on deployment
Hello all,
Simple yet difficult question: I have attached a picture with a VI that has been deployed on an RT target (this is from a debugging session of the RT exe). This application works within the development environment, but is broken all over the place when built. As you can see from the image, there are classes that are included (and I would think they would be automatically pulled into the build as they are directly referenced), but they are obviously broken. Any thoughts as to why this might be? Could it be that the build is not picking up the parent of these classes? (if so, that is weeeeaaaaaak) This is incredibly frustrating.
Thanks, Matt
Thanks Bob. The code is rather large and contains a lot of RT, FPGA and hardware stuff, so this would not be useful. Not to mention that you would have to have all of these modules installed, a controller to deploy the system on for testing, etc. etc. The reason I did not post a snippet is that the snippet would be meaningless given that the application underneath is quite complex (would likely pull in a lot of dependencies that many here don't have access to) . AND, this is an image from a debugging session on the target (i.e. rtexe - not a LV session), so there is no 1:1 correlation. But, allow me to demonstrate:
Note the lack of broken wires as we are now pulling from the development portion of the project (not the executable). This is not meaningful. Sometimes (many times) a picture is worth one snippet and a thousand words (especially when referring to an RT exe rather than a development issue)...
Anyways....if you notice in the original image, the portions that are broken are related to the classes depicted. These are properties associated with the classes themselves (so they are just methods contained within a property folder in the class library). The VI shown is called by the top level application VI. In this iteration (shown in the image), I actually provided a control for injecting the class from the top level VI (hoping that the classes in that diagram would suck in all the dependencies); this obviously didn't work.
As it turns out, I just starting dumping all of the VIs directly called by the top level VI into the must includes of the build and...viola!...the build was successful! I must be misunderstanding how dependencies are calculated in these builds, because there is nothing particularly tricky about this - the VIs I had to include are directly referenced in the main application VI. LabVIEW in this instance seems to be wanting to behave like another language now where we have to explicitly import these dependencies. Lame. This likely needs an AE to explain exactly why this is; and this might be beyond most AEs experience (was beyond mine).
