PC <-> RT with redundant (back-up) user interface

[breiter56]

Great news. I've created my first DQMH module to "refactor" a subset of code from a very poorly written application ( a long story, made short, that I must share: It starts with "forked" queue's and mystery messages that were coming from a sub-vi nested 3 deep. It ends with my consultant: "But the code works". Classic!) Now for the real topic:

How to design a DQMH based application that primarily runs on RT (cRIO-9045) with a PC UI, that is ready to run solely on the cRIO embedded UI if the PC is unavailable? I've had two life experiences running machine control applications on PC, in one case windows update prevented operating the equipment and the other, a virus took out the PC. The primary reason I'm setting this requirement is to log data  directly to corporate network folders associated with each test we perform. We are controlling and monitoring a hydraulic power unit as the stimulus to the Device Under Test from which we acquire (post-process and log to file) the DUT mechanical responses and stimulus conditions. The secondary reason is for network access facilitating automatic e-mail notifications upon important events. In case the PC or IT network is not available, I intend to switch our touchscreen monitor input to the cRIO, make a couple run-time changes to RT and save files to a jump drive. Another reasonable option would be to have two monitors with the primary UI on the cRIO and have PC VI porting data to the network. 

I have not studied it yet, but on the surface Hampel Software Engineering / DQMH / HSE Generic Networking for DQMH Modules · GitLab looks very helpful for the primary architecture. I'm all but lost for planning the back-up embedded UI. To be fair, I'm not sure how to accomplish this architecture regardless of DQMH. I can't imagine this would be as simple as having two instances of one UI module on each of the targets........

What examples, or reference material might help me see the design process this would require?

Thanks - Jared

[joerg.hampel]

Hey Jared,

if you can manage to keep the dependencies at bay, the GenNet template could be a very simple solution to your requirement. 

• You would be able to have the exact same module(s) running both on Windows and on the RT target -> that would mean that you'd have the exact same UI both on Win and RT
• The UI module(s) should have no dependencies to RT code so it/they can also run on Windows
• While the Windows client is connected, you would set the UI module running on the RT target to "forward requests" (the option in the GenNet examples is called Enable Network Forwarding) and the UI module running on Windows to "accept requests via network" (the option in the examples is called Enable Network Listening) 
• When the Windows client becomes unavailable, you can - either manually or even automatically - set the UI module running on RT to not forward requests any longer but process them locally
• You could even modify the GenNet implementation to both forward requests via network AND process them locally, that way both clients would show synchronised UIs

This is of course only one of many, many ways to achieve what you're looking for. 

[ChrisFarmerWIS]

If you haven't seen it already, there is this video on implementing DQMH on a LabVIEW RT target.  There are a few ideas on user interfaces discussed that might give you some ideas...

(377) GLA Summit 2021: Recommendations for better LabVIEW RT development using DQMH - YouTube