Initial DQMH Development on Real-Time

[bartelma]

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 

[joerg.hampel]

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.

[Darren]

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

[ChrisFarmerWIS]

---

@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®

[Darren]

---

@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".

[bartelma]

Thanks for jumping on this question everyone!

@ChrisFarmer I went back and watched your video. Thanks for all of the tips and lived experience with DQMH on RT!

@Darren and @Joerg I can totally see how building the module in Windows would make testing 80% of the module easier, especially if I'm working on a remote server without hardware connectivity. It just requires me to simulate the I/O.

So if I were to build the module under My Computer, am I eventually going to be moving the entire module library into the RT target and it would no longer live in the folder under My Computer, or should the library live on both targets right off the bat and I just run the tester in Windows until I'm ready to deploy the VI to the target and run the RT Tester. This may be a fundamental LabVIEW project organization question and not specifically DQMH. For example, I've had a RT project in the recent past where a Windows VI and RT VI both called the same user interface VI, so the user interface VI was organized under My Computer but the Main RT VI of course was under the RT Target in the project. 

I included a picture below of a dummy project where the module library and virtual folders live both under My Computer and the RT Target. Is this an acceptable practice? Or should the module library only exist in one target at a time? I just want to start off on the right foot here.

[Darren]

I think you'll want the module (and its testers) to only be under one target. If you have it under multiple targets, I think you'll get errors when running the DQMH Scripting Tools.

[bartelma]

I thought you would be right about that Darren, but I played around with the project and scripting tools and the Add Module and Add Event scripting tools seem to work with the folders in existence on both targets. Maybe there are other features that wouldn't work quite right and I just haven't found it yet. 

I'm beating my head against a wall this afternoon though, and I'm hoping someone can help. I created a new project with my cRIO-9042 as the target and I added a new DQMH module to the RT target. I then created a new RT Tester for the module. After verifying no broken run arrows in the Main.vi or RT Tester VI I tried running the RT Tester on the cRIO and it crashes the RT Process every time! I can run the module and the normal Windows version tester on My Computer. I can also create a dummy VI to run on the cRIO without any issues. I also tried running the Main.vi of the module right on the RT Target and it crashes the RT Process too. 

Has anyone ever seen this with RT? LabVIEW 2024 Q3, DQMH 7.0.1

[Darren]

> Maybe there are other features that wouldn't work quite right and I just haven't found it yet.

Yeah, I think the specific issue I saw was that either the Rename Event or Remove Event tool generated an error when the module tester was on My Computer but the module library was on RT.

[bartelma]

Update to my head bashing session this afternoon: I decided to build an exe of the RT Tester VI and deploy it to run on startup and in this case it worked without crashing the RT Process. (side note I did have to provide an event structure Timeout value so that it looked for button presses. Maybe there should be a default value for this in the scripted RT Tester creation?) 

So there's something going on with running the Module itself or the RT Tester interactively that crashes the RT Process on the cRIO. Ultimately, it's only a slight inconvenience because I can always build a debuggable exe of the RT Tester and connect to it remotely as well. But I'm curious if anyone else has had issues running DQMH modules from the development environment on an RT Target?

Thanks for everyone's comments so far!