06-17-2010 05:40 PM
We have a cRIO which, in its day-to-day life, is employed as part of a robotic system. It operates using a real-time executable (Program A1) which runs at startup. This project (Project A) uses several softmotion tables to accommodate motion contouring, and interacts wirelessy using network variables with an executable (Program A2) on a PC. The developer breathed a sigh of relief when the two executables were safely compiled and archived--surely no foolish coding mistake could break the system now!
Recently, the cRIO was temporarily re-tasked for R&D Project B, which did not use softmotion tables, and did not replace the startup executable. While working on Project B, Program B was deployed, and the softmotion tables were aparrently un-deployed. When the cRIO was returned to its normal use, the developer was shocked, Shocked I say, to find that his trusty real-time executable no longer worked. Project A had to be reopened and the Tables re-deployed before the .rtexe would function again at restart.
Is there a way to build a real-time executable in such a way that one can Guarantee it will work in the future, even if a coworker should misconfigure or delete the project that created it? Can I build Table deployment - and any other factor that could be messed with - into the .rtexe? As a developer in an R&D environment with other coders, it would be nice to set reliable baselines.
Cheers, Wes
06-18-2010 01:20 PM
Wes,
I really appreciated your animated description of your problem. If I'm understanding you correctly, this KB discusses how to include support files to an executable. Take a look at it and let me know if that was the information you were looking for.
I hope you have a great weekend!
07-01-2010 09:49 AM
Stefanie,
I already use the include method for VIs and non-VI files called by reference in executables, which has improved robustness. It seems as if there are project-related "states" or something that are not intrinsically built into the executable but are also not stored in files which can be included in the way you suggested. If there is a way to take the current project settings/states and create an includable setup file or something that would work.
Actually, even just knowing which project items fall into this category would help me ensure that I handle them correctly. In this case it was the Tables, but I don't know what else could be relevant.
Cheers,
Wes