"Remove block diagram'ed" VI's contain compiled code for multiple targets

[QFang]

I find myself making a lot of VIPM packages for code re-use.  As we re-use more code we increasingly want to protect the code so that we can more freely share such packages with e.g. sub-contractors/licensed users without sharing the block diagram.  (and the first person to suggest we use VI password protection gets to wear the donkey ears for the rest of the year.)

When you remove the block diagram from a VI, you also remove the ability for that VI to recompile which means that it can only run on the same version of LabVIEW and on the same hardware as it was compiled on/for.  This makes it a giant pita if you have code that is used (and works) equvally well on e.g. vxWORKS cRIO and "Windows".  Currently VI's consist of 4 parts (Front panel, block diagram, code and data) and without the block diagram, the code section cannot be recompiled.

I wonder, if it would be possible to extend this to either allow the "code" section of the file to be essentially an "array" or at the very least let there be two "code" sections?  -It would tremendously increase the usability of the "remove block diagram" feature if we didn't need to maintain a copy for each hardware platform.

I'm not sure how technically possible this would be, but since deployed code (at least to RT) typically gets compiled into (rt)exe's the extra and un-used code section(s) could be stripped during exe build, and the slight performance hit during development/debugging runs that might come from this along with larger VI size seems to me to be a decent trade-off.  

So my suggestion is to investigate this and if possible allow some extra choices during the "strip block diagram" from VI process where you get to select an extra "target platform" or two.

A much less savy alternative would be to modify the existing tool to automatically pre-fix and output multiple "versions" of the same code distribution, one for each selected target platform. This would at least speed up the process of maintaining and creating all the variations.

[Intaris]

Hmm, we use the same VIs on up to 8-9 targets.  This would lead to a lot of bloat on the code side of those VIs.  I think there could be code for differing "OS" tags. "Windows", "Linux", "MacOS", "RT".  FPGA is a different beast since the VIs can't run natively anyway.  Simulation code would be covered by the aforementioned cases.

If technically feasible, this would be nice.  It could even allow for the VIs to no longer get "dirty" just be opening them on a new target.  That would be nice.

[QFang]

Yeah, its annoying that a VI gets "dirty" just by opening it in the context of a new target even though there is no changes (other than compile target) made.. If VI's could be configured to retain the compiled code for multiple (user selectable?) targets at once, this would indeed imply that they would no longer become dirty just by opening them.. I didn't even think about that, but this would be a nice "side effect" bonus!

[QFang]

I created a thread on the forum to promote and discuss this idea further. 

forum thread

[SteenSchmidt]

This would be really nice.

It wouold probably also open up for faster load of VIs, if the compiled code could get closer to execution code for the given target. It could perhaps even make the runtime engine smaller.

Btw, I find the most common reason for a VI to be marked dirty when opening on a different target is reentrance and debugging enabled at the same time. So, if you have a reentrant VI with debugging enabled, that will be compiled differently for an Real-Time target and a Desktop target. If you disable debugging on the VI it will no longer be marked dirty when opening on the other target. Annoying.

/Steen