DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Message Pumps in DQMH

Solved!
Go to solution

Hi guys,

 

I've been working with a couple of customers recently who are interested in building applications based on DQMH. One of the requirements which has been coming up is the idea of creating a base DQMH module which has a message pump to continuously output messages at a preset rate (different for each instance of the module).

 

What the module is outputting messages to will change, often some hardware protocol which requires continuous messaging even if the data has not changed (I don't want to use the main event timeout as the message pump period would get interrupted by other events being triggered). 

 

I have been discussing the idea of creating a cloneable DQMH module which has an additional helper loop to continuously send messages, and then uses a simple hardware abstraction layer to hide the communications protocol behind.

 

I just thought it would be good to get your feedback on this, is this something you've done elsewhere with a similar/different method? If you would like a more fully featured example I could try and find some time to work on it in the next few weeks, but have attached my initial PoC here.

 

Cheers,

 

Pete

Message 1 of 41
(8,662 Views)

Just for anyone who doesn't have LV 2016 available, I've attached a quick screenshot of the core vi. 

 

It's relatively simple, in the top left is the sub-vi named Message Pump.vi. This iterates at whatever rate is set by the main vi, executing the timeout case of the event structure to call the Output Data message at the pre-defined rate. The only other case in the event structure is the shutdown case which is called when the main vi enters the Exit case.

 

In the Output Data case in the main vi (bottom left) is the action sub-vi which is a dynamic dispatch vi and completes a different action depending on the value entered for Data Protocol on start up (both the Pump Period and Data Protocol controls are set from the Launch Module vi with the CtrlVal.Set method. 

 

I hope that all makes sense. 

 

Cheers,


Pete

0 Kudos
Message 2 of 41
(8,634 Views)

2015 version here for anyone interested.

 

Cheers,


Pete

0 Kudos
Message 3 of 41
(8,604 Views)

Hi Pete,

 

Thanks for sharing the code with us. I like what you have done and the idea is implemented well. 

 

There are some areas that could be improved that are not taking advantage of DQMH. 

 

Helper Loop: Service.lvlib: Message Pump.vi

From what I can tell, the stop event is only being fired during the Exit case, why not register the helper loop to only listen to the Stop Request?: Something like this:

Register For Stop Request.jpg

 

Detail on other event case:

Timeout Event Case.jpg

 

This removes the need to create another event outside of the DQMH. Registering for a single event, means your helper loop will not be interrupted by other events.

If you don't like this approach, at least I suggest that when you do create events, you do wrap them in VIs so it is easier to find where they are being created - fired and destroyed. 

 

The next point is more of a preference: When the helper loops are simple like this one, I prefer to have it directly on the Main.vi block diagram. 

 

Regards,

Fab

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 4 of 41
(8,596 Views)

One more thing, I would put the factory pattern into a VI and call it from the initialize case. Do that after calling the "Did Init" broadcast  "Synchronize Caller Events.vi". This will ensure that you don't time out the starting of the module. Any errors during the factory pattern would be then broadcast via the error case. 

 

If you decide to keep the factory pattern outside of the MHL, then you probably should have it outside of the outer error structure, so an error during factory pattern would not launch the rest of the DQMH module.

 

I believe the first option is cleaner and might give you more information. 

Alternatively, you could have a separate request to set the instance type, so in the case of an error, you could always call the factory pattern again.

 

Regards,

Fab

 

[Edited to reflect that the code should be after the "Synchronize Caller Events.vi" not the Did Init broadcast.]

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 5 of 41
(8,593 Views)

Hi Fab,

 

Thanks for the feedback. I made a couple of modifications for the 2015 version of the code I put up, one of which was to use the stop event already created.

 

I like the suggestions of wrapping the factory pattern code in a vi and putting it in the init procedure - I'll see if I get time to make the modifications in that area too.

 

Cheers,

 

Pete

0 Kudos
Message 6 of 41
(8,582 Views)

The timing on this is almost perfect for me, thanks for putting up ideas and solutions.

 

I am modifying your idea to be active only at certain times.  I have a request + broadcsat to start an acquisition, and then it needs to run for X seconds and stop.  While acquiring I want to get the recent readings and broadcast them.

 

So I have a start event, a get status event, a stop event.  All request + broadcast.

 

So in my pump I start it with a -1 timeout.  I am then registering for the Start broadcast, that then sets the timeout so it will pump the get status event.  Then after X seconds it will stop the acquistion and reset the timeout of the pump to -1.  It also is watching the stop event so no lockups.


Thanks both of you.

Message 7 of 41
(8,580 Views)

Hey Fab,

 

Quick question.  Is there a reason you pass the Module Admin in to the pump but not the cluster of user events and you instead call the obtain VI?

 

0 Kudos
Message 8 of 41
(8,576 Views)

Hi Evan,

 

thanks for the feedback. It's always good to know ideas and examples that I put up are being useful to real world applications. 

 

Give us a shout if any other questions come up. 

 

Cheers,

 

Pete

0 Kudos
Message 9 of 41
(8,568 Views)

@Evan wrote:

Hey Fab,

 

Quick question.  Is there a reason you pass the Module Admin in to the pump but not the cluster of user events and you instead call the obtain VI?

 


This is a DQMH style thing. If you see all of the Request VIs and the Broadcast VIs call the obtain VI is inside the VIs, we never feed the cluster of user events. This way, you don't have to be chasing the wire of the cluster events through all of your cases in MHL to see where they are being used. Instead, you can just search for where the particular Request VI or particular Broadcast VI is being used. I was just following this same principle. This goes back to sometime around 2012, you can see the very initial drafts of DQMH and how I was proposing to transform QMH back then. DQMH has come a long way since then 😉

 

I pass the module Admin class wire, because there is no other way out of the box to transfer that information. I could transfer just the Module ID and that would be OK too. I don't have a strong preference either way. It would depend if you plan on creating your Module Admin children or not.

 

Fab 

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 10 of 41
(8,544 Views)