Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Any caveats in using DQMH on Real-Time?

Highlighted

Hello,

I am a big fan of DQMH.  It really well extends the concept of recent NI QMH-based Sample Projects, while it automatically scripts many common coding components such as registering new events, cases, caller APIs, etc.  What is more, it is unbelievable that it is all free available from VIPM and great introduction films are available on Youtube.    It is so wonderful. 

While having a lot of benefits from DQMH, I have come up with two questions about DQMH.

  1. Is it possible to have an installer of DQMH outside of VIPM?
    Some users are worried to be dependent with a library on VIPM, because they would like to use libraries natively supported in NI installers. 
  2. Is there any caveats, when I use DQMH on Real-Time target?
    Since NI provides QMH-based Sample Project also for Real-Time target, In the flow of introducing DQMH to my customers and implement together, there will be a point where they start wanting to use some NI RT products such as cRIO / sbRIO.  In that case, do you provide any caveats for users to pay attention when we use DQMH for Real-Time targets?

Thanks much for your invention, and thank you so much for being generous and speading this wonderful frameworks for everyone in LabVIEW world.

Regards,

Osamu Fujioka

0 Kudos
Message 1 of 10
(3,929 Views)

Hello Osamu,

We are glad you like the DQMH.

  1. Is it possible to have an installer of DQMH outside of VIPM?
    Some users are worried to be dependent with a library on VIPM, because they would like to use libraries natively supported in NI installers.

These are some of the arguments we use with our own customers: VIPM ships with LabVIEW since 2013, your customers can use the same NI LabVIEW Installer to install VIPM. The LabVIEW Tools Network uses VIPM as the distribution method for the tools available there. You can point your customers to the DQMH LabVIEW Tools Network page: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286

Also NI allows us to display the "Compatible with LabVIEW" icon on our page, which means NI has validated our toolkit: http://delacor.com/products/

Hope these arguments help you, if you still get push back from your customers please let us know, we might be able to help you with other arguments.

2. Is there any caveats, when I use DQMH on Real-Time target?
Since NI provides QMH-based Sample Project also for Real-Time target, In the flow of introducing DQMH to my customers and implement together, there will be a point where they start wanting to use some NI RT products such as cRIO / sbRIO.  In that case, do you provide any caveats for users to pay attention when we use DQMH for Real-Time targets?

We have not used the DQMH on a Real-Time target project yet. We have had discussions internally as to what the caveats/changes would be. There is nothing on the DQMH that would make it not work on Real Time. Here is the list we have come up with:

  1. Event structure is supported in RT.
  2. The general guideline in RT is to limit the size of queues, so we would create a child class of the DQMH Queue class that would override the queue creation to limit the size of the Queue.
  3. Having a class shared between RT target and desktop means the classes get locked for editing. One workaround would be to have a project for the RT target and a different project for the desktop application.

If you try it out, please let us know how it goes.

Thanks again for reaching out and for your encouraging feedback.

Best regards,

Fab

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Message 2 of 10
(3,045 Views)

Hello Fabiola,

Thank you so much for your reply. 

  1. Is it possible to have an installer of DQMH outside of VIPM?
    Some users are worried to be dependent with a library on VIPM, because they would like to use libraries natively supported in NI installers.

These are some of the arguments we use with our own customers: VIPM ships with LabVIEW since 2013, your customers can use the same NI LabVIEW Installer to install VIPM. The LabVIEW Tools Network uses VIPM as the distribution method for the tools available there. You can point your customers to the DQMH LabVIEW Tools Network page: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286

Also NI allows us to display the "Compatible with LabVIEW" icon on our page, which means NI has validated our toolkit: http://delacor.com/products/

Hope these arguments help you, if you still get push back from your customers please let us know, we might be able to help you with other arguments.

I will go with the arguments which you suggested above.  Sometimes, my customers do not have network access on their machines, but, even in that situation, we can distribute vipm file and locally copy it to isstall through VIPM.  So, no worries in this case

2. Is there any caveats, when I use DQMH on Real-Time target?
Since NI provides QMH-based Sample Project also for Real-Time target, In the flow of introducing DQMH to my customers and implement together, there will be a point where they start wanting to use some NI RT products such as cRIO / sbRIO.  In that case, do you provide any caveats for users to pay attention when we use DQMH for Real-Time targets?

We have not used the DQMH on a Real-Time target project yet. We have had discussions internally as to what the caveats/changes would be. There is nothing on the DQMH that would make it not work on Real Time. Here is the list we have come up with:

  1. Event structure is supported in RT.
  2. The general guideline in RT is to limit the size of queues, so we would create a child class of the DQMH Queue class that would override the queue creation to limit the size of the Queue.
  3. Having a class shared between RT target and desktop means the classes get locked for editing. One workaround would be to have a project for the RT target and a different project for the desktop application.

These inputs are very helpful.  Thank you so much for coming up with these valuable advise in short time.  I will keep these in mind and embark myself on RT with DQMH. 

At this point, my questions are fully answered and I really appreciate your help and DQMH.

Best regards,

Osamu

Message 3 of 10
(3,045 Views)

One additional caveat when using DQMH on Real-time is that the module tester that the framework auto-generates, relies on front-panel events. This makes it unusable on real-time targets without GUI  (real-time only supports front panel events on targets that have GUI-capability...). You could say that this is less of an issue because most of the tester functionality calls methods on the module sthat are not supported either (show front panel/block diagram), but the select module part for example is still useful, especially when you have added user events to the module and tester.

User events *are* supported, so most of the framework runs without a problem. No show stoppers there.

The issue with the testers could have been avoided by designing them the old pre-event structure way; wiring the controls and allow the loop to run continously to poll the controls. I've done this quickly by adding a timeout to the event structure to poll the different controls, and then have case structures to react on the booleans. Alternatively you could have one classic (no event structure) loop to manage front panel input, and a second loop to handle the user events.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 4 of 10
(3,045 Views)

Hi!

I have taken another way to address issue of events for testers. I have alteres the code by moving tester vi to PC, and passing eent data through netwrk stream to RT. There individual events are launched.

I have proposed this mechanism to incorporate in DQMH, as for PC applications this process will be transparent, while it will enable full functionality for RT systems

Message 5 of 10
(3,045 Views)

_Mike_ wrote:

Hi!

I have taken another way to address issue of events for testers. I have alteres the code by moving tester vi to PC, and passing eent data through netwrk stream to RT. There individual events are launched.

Hi Mike,

Do you mind sharing your code with us? We are evaluating different ways to add support for DQMH in RT projects and I would like to see what you have done.

Thanks,

Fab

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Message 6 of 10
(3,045 Views)

I'd like to add another caveat for people using DQMH with (Linux RT and) embedded UI enabled. When running a startup application on the controller in the runtime engine, you would get synchronization errors and could not set any controls from the Start Module VI.

 

Fabiola pointed me to the following thread which helped me understand what's going on (looks like a bug in LabVIEW) and find a suitable workaround: 

http://forums.ni.com/t5/Delacor-Toolkits-Discussions/Deploy-and-run-at-Startup-for-RT-systems/td-p/3...

 

Thanks, Fab!


Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor
hampel-soft.com | ALArchitects.org | GDevCon.com | DSH-Workshops.com | bit.ly/WUELUG
Message 7 of 10
(2,623 Views)

DQMH 4.0 is released and one of the new features includes the creation of a Real-Time DQMH API Tester.

 

Regards,

Fab

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Message 8 of 10
(2,088 Views)

Quick update: LV2018 still shows the same behavior. See this post


Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor
hampel-soft.com | ALArchitects.org | GDevCon.com | DSH-Workshops.com | bit.ly/WUELUG
0 Kudos
Message 9 of 10
(1,227 Views)

Another update: We have come up with what we think to be a valid and working workaround.


Joerg Hampel | CLA, LabVIEW Champion, DQMH Trusted Advisor
hampel-soft.com | ALArchitects.org | GDevCon.com | DSH-Workshops.com | bit.ly/WUELUG
0 Kudos
Message 10 of 10
(1,132 Views)