DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Initial DQMH Development on Real-Time

Hello everyone,

 

I had the pleasure of meeting several of you at this year's GDevConNA, and I'm just now getting around to reaching out for some DQMH help. I'm relatively new to DQMH and I've only ever developed one measurement and logging app using the framework for a Windows PC/cDAQ system. It went fairly well but I did fall into some of the normal traps so I'm hoping to learn from my mistakes with this new endeavor. 

 

This time, I'm developing an application for a Real-Time target, a cRIO-9042 with LabVIEW 2024 Q3 and the DQMH package version 7.0.1. I do plan on using the embedded UI.

 

I noticed the DQMH consortium document DQMH in LabVIEW Real-Time :: DQMH Consortium Docs recommends developing modules under My Computer, then dragging them to the RT target when ready to deploy. This doesn't seem like a practice I would normally follow when developing RT applications, especially ones that interface directly with RT I/O. So is there a reason for this advice and is it outdated or does anyone have a different opinion or experience?

 

Thanks,

Mark 

0 Kudos
Message 1 of 5
(47 Views)

Hey Mark,

 

great to hear that DQMH works well for you so far. We've been using it for lots of RT projects for the last 8 years now, and we're still in business 😉

 

As for your question, the only reason really is that developing under Windows allows you to run your module faster, which might mean you test it more often, which aligns with the philosophy of developing and testing your module in isolation, then integrating it into your application. 

 

I do agree that the recommendation comes across quite strongly. Perhaps we can look into explaining ourselves or toning the message down a bit.




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® (Developer Experience that makes you smile )


0 Kudos
Message 2 of 5
(25 Views)

I think the primary reason for the recommendation is that most/all of the DQMH scripting tools will only work for modules that reside under 'My Computer'.

0 Kudos
Message 3 of 5
(19 Views)

@Darren wrote:

I think the primary reason for the recommendation is that most/all of the DQMH scripting tools will only work for modules that reside under 'My Computer'.


Hi Darren.  That surprised me!  It seemed to work fine for me on the various cRIO projects over the years.  Can you specify which tools definitely don't work outside of 'My Computer'?

 

@Bartelma - I created a GLA Summit presentation a few years ago about using DQMH with LabVIEW RT - it's starting to date a little, but there are still a few relevant tips in there if this interests you: LabVIEW Helper Video Library | Wired-in Software | Melbourne --> Tips and tricks for developing RT applications using DQMH®

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

0 Kudos
Message 4 of 5
(13 Views)

@ChrisFarmerWIS wrote:


That surprised me!  It seemed to work fine for me on the various cRIO projects over the years.  Can you specify which tools definitely don't work outside of 'My Computer'?


Well now I'm the surprised one. I just tried all the scripting tools on a module under an RT target and they all worked great! I don't think that's always been the case. 🙂 I just had to make sure I didn't have the module tester under My Computer, as that caused some errors. But yeah, with everything under the RT target, it worked fine. So yeah, I'm thinking that maybe we don't need that guideline anymore, and that keeping RT-based DQMH modules under the RT target in the project should "just work".

0 Kudos
Message 5 of 5
(5 Views)