Deploy and run at Startup for RT systems

[joerg.hampel]

Fab,

does the "splash" VI have to load another VI dynamically? Or can it just be a Wait on the block diagram, and then the Load Module VI?

[joerg.hampel]

---

---

does the "splash" VI have to load another VI dynamically? Or can it just be a Wait on the block diagram, and then the Load Module VI?

Never mind, I tried both, but to no avail. Waiting doesn't change the behaviour.

[FabiolaDelaCueva]

We continue to investigate. An R&D suggested workaround: 

Modify the build specification "Source File Settings" to not remove the front panel. 

[henriksandin]

That does sound like a pretty good and straightforward solution! 

Thank you Fabiola and R&D I will try it! 

[ManuelSebald]

Thanks for the hint with the build specification. I tested the workaround on our cRIO system under the same circumstances as last time. Unfortunately, it didn't work neither. It made no difference if I unchecked the "remove front panel" option for the whole project, or only for the DQMH-module.

So, we will probably stick to our workaround and make a template with them.

BR

[joerg.hampel]

Quick update: We see the same behavior with LV2018 f1 (Real-Time 18.0.0). Enabling the Embedded UI on Linux RT targets still renders Singleton modules non-functional.

Our workaround (implemented in our RT template) is still setting singleton modules to "Preallocated clone reentrant execution" in the VI properties of the main.vi, and modifying the "Get Module Main VI Information.vi" as follows.

Caveat: Everything that Fab stated before is still true. If you're not loading/unloading your modules in one place as we do in our Real-Time applications, you're in for additional synchronization work, complications or worse.

[joerg.hampel]

So, the time has eventually come when we've been bitten by the limitation of our own workaround: If the DQMH singleton module gets loaded reentrant (for Linux RT / Embedded UI / Runtime), the "Get Module Main VI Information.vi" will report the wrong execution status.

To work around this limitation, we use a nifty little VI posted by @AristosQueue which "given an non-clone VI name, generates the Nth clone name". This allows us, when on Linux RT / Embedded UI / Runtime, to check the first clone instead of the main.vi for its execution status.

If you're interested, download the attached VI and the VI mentioned above and give it a try. This solution seems to work well for us, please let me know what you think of it.

[FabiolaDelaCueva]

I am out of the office, I will review this weekend.

I am curious to see what others think about this approach.

[Darren]

The Generate Clone Name.vi ships with LabVIEW 2014 and later. It is here:

[LabVIEW 20xx]\vi.lib\VIServer\Generate Clone Name.vi

P.S. - It's a hidden gem. 😉

[joerg.hampel]

To keep this thread up-to-date:

"DQMH 5.0 and later supports both Singleton and Cloneable modules in LabVIEW Real Time. DQMH 5.0 modifies how the DQMH modules are launched. DQMH now uses Start Asynchronous call instead of the Run VI Server Method."

(Delacor Queued Message Handler Documentation)