LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem building real-time executable with softmotion tables

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

0 Kudos
Message 1 of 3
(2,960 Views)

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!

Stephanie A.
Americas Marketing Manager
National Instruments
0 Kudos
Message 2 of 3
(2,936 Views)

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

0 Kudos
Message 3 of 3
(2,874 Views)