DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploy and run at Startup for RT systems

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?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 11 of 20
(2,924 Views)


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.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 12 of 20
(2,921 Views)

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

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

 

image001.jpg

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 13 of 20
(2,905 Views)

That does sound like a pretty good and straightforward solution! 

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

0 Kudos
Message 14 of 20
(2,900 Views)

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

 

 

0 Kudos
Message 15 of 20
(2,872 Views)

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.

 

Bildschirmfoto 2018-07-25 um 19.06.29 (2).png

 

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.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 16 of 20
(2,489 Views)

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.

 

dqmh-get-main-vi-info.png

 

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.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 17 of 20
(2,419 Views)

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

 

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

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 18 of 20
(2,410 Views)

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. 😉

Message 19 of 20
(2,407 Views)

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)




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 20 of 20
(1,527 Views)