Conditional Disable of Front Panel Objects for RT Targets

[colbrunn]

We are running into an issue where we are beginning to have our code base running on multiple platforms (Windows, RT) and some functions are not supported on RT targets. We have written scripts that crawl through our code and puts conditional disable structures around functions not supported on RT targets. In pretty much every case these functions are not needed on the RT target, they just happen to be in the library that gets deployed to the target. This solution works really well until we get to unsupported front panel controls (ActiveX, XControl, etc). Even if I disable the control or indicator on the block diagram it still throws an error (see image) and I can't deploy. I found a discussion from 2013 about changing how front panel objects are managed when the control or indicator is disabled. Last I saw was that Aristos Queue said he was going to go back to the development team to discuss.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Better-handling-of-UI-elements-within-conditional-dis...

Does anyone have a solution for this because right now I am looking at having to duplicate versions of code and whole libraries and I am hoping there is a better way to manage this?

[rolfk]

Well, UI on RT has traditionally not even been  possible. Much of the basic stuff like standard controls simply got stubbed out so that a VI could be still loaded but simply didn't do anything with that useless UI. There is a reason that the Realtime version of LabVIEW was internally dubbed LVintheDark. It was operating literally in the dark with no other possibilities than remote displays, including the debugging of code running on the target.

XControl and other advanced stuff never quite was part of that as it used to be an experimental part of LabVIEW for a pretty long time. And at around 2011 NI started to embark on the LabVIEW NXG adventure and later stated its intentions to replace the classic LabVIEW with that in the longer run (they talked about a 10  year plan starting from the official release of NXG somewhere around 2017), diverting most of the development resources to that and more or less stopping new feature development on classic LabVIEW. The RT system got support for a minimalistic UI since new higher end cRIO systems started to be released that had built in display support, but that was limited to the basic UI elements and based on the standard X Windows system they could reuse from their Unix platform support (from which only the Linux variant was left over at that point). But the X Windows manager they deployed on the cRIOs had to be a lightweight implementation as the more heavy weight implementations would be rather unsuitable for a RT system, so there was not much use in investing into fancy graphic modes and features anyways.

Basically your mode of operation is rather backwards. Repurposing a heavy weight UI centric framework to LabVIEW RT is a major development feat if you haven't planned on decoupling the UI from the actual business logic from the start. Someone hasn't done his homework when deciding that this library/framework can be easily ported to LabVIEW RT as is.

[ImreSzebelledi]

We had the same issue with our huge legacy framework and unfortunately there is no easy answer. What we get away right now is almost the same solution as you did:

1. Create conditional disable structure around every function that is not supported on RT (we use Pharlap and Linux RT as well).

2. Enable embedded ui when possible.

2. Move unsupported elements within classes outside the class. (eg. VI with subpanel/subpanel ref --> Servodrive.lvclass:Testpanel.vi seems like a good idea at first but it will bite you). Because every element of the class is deployed, even if it is not called.

3. Enable "Remove unused elements of project libraries" for the build specification.