DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Message Pumps in DQMH

Solved!
Go to solution

 

So in a message pump type idea, what is the "correct" way to start a pump and also to stop the pump? I have a measurement I want to take for 30 seconds, but updated the currect reading via the message pump.

 

So DQMH event "start measurement" should also start the message pump.  Do I make the request a request+ broadcast and the pump listens to the broadcast, or is it ok to have the message pump and the MHL both listen for the request event.

 

I originally made it a broadcast, but as I was following Fab's advice to obtain the events via the SubVI I discovered the difference between the Obtain Request Events and Obtain Broadcast Events.  To use the stop event I needed the request event though I originally only had the broadcast events registered in the message pump.  I am not sure if it is good practice to have the two loops processing the same requests at the same time.  I can see using stop in multiple areas, but I could just as easy stop the pump via the "Module did stop" broadcast.  

 

Generally I am leaning towards stop being a special case, and starting the pump from a broadcast.  That way the module seems to have a single entry point for that message.  The pump starts in a similiar way as any other object outside the DQMH, but that may just be an arbitraty line I am drawing.

 

Thoughts?

 

Thanks,

0 Kudos
Message 11 of 41
(4,034 Views)

I tend to use Requests for helper loops within the DQMH Main.vi, if I don't want code outside DQMH calling that request, then I make the Request VI private. 

 

Broadcasts should be left for things code outside the DQMH wants to register for.

 

It is OK to be registered for the same event in multiple places. As long as you do not fork the registration wire, you should be fine. Each event structure handling DQMH Events should have its own registration. 

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 12 of 41
(4,027 Views)

Hi Pete,

 

 

I wanted to suggest that you convert your Message pump DQMH into a DQMH template. With DQMH 3.1 you could build it into a package that installs everything you need so the next time you go to Tools>Delacor>DQMH>Add New DQMH  Module... you would have the option to chose between a Singleton, a Cloneable and a Message Pump.

Here is more on how to create a DQMH Module Template: 

http://delacor.com/documentation/dqmh-html/DQMHDocumentation.html?AddingaNewDQMHModulefromaCustomT.h...

 

Then, if you are feeling generous, you could share that package with others here 😉 

 

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?
0 Kudos
Message 13 of 41
(4,014 Views)

This is an interesting topic.

 

We're writing a motion control DQMH module. In our application it is often possible for people to manually adjust the position of our actuators. The physical motion controller is normally aware of this as it gets feedback from encoders on the actuators, but I want the software to reflect these changes in real time. 

 

Before I read this post, I had intended to write an external "monitor" loop which polled the (cloneable) DQMH to request updated positions periodically. Since I only want to do that when a module is idle (I dont want to be polling during motion for example as the module already broadcasts its position during a move without having to poll it) I wrote a modified message queue object which broadcasts a module status event with the argument "Active" or "Idle" when a) the message handling loop dequeues a new message (only broadcast if the module was previously "idle") and b) after completion of a message state IF the queue is empty at that point.

 

I had planned to write the external monitor to register for the status broadcast and keep a "record" of which clones were active/idle and periodically request the position of all idle modules.

 

After reading this post, I wonder if what I should actually do is have a helper loop inside the DQMH which uses the active/idle broadcast event to start/stop polling internally. That would mean I wouldnt need to worry about working out which clones were idle as the clones would handle it themselves. BUT, now I want effectively a "private" broadcast event so that only the DQMH module can register for the active/idle status... but a "private" broadcast makes no sense really in terms of a general DQMH. Alternatively I could switch the activity status broadcast to a private request event back to the DQMH and have that event queue a message to a second message handling loop which fires the actual update position request periodically when the module is idle... (I think I'd implement the helper loop as a queue driven loop, but when the module goes idle, set the time out to "n" ms and do my polling in a timeout case. Then when the module goes active, set the timeout back to -1.

 

Any thoughts on this approach?

 

Thanks

 

Paul

0 Kudos
Message 14 of 41
(3,936 Views)

@psmorris wrote:

 

 

After reading this post, I wonder if what I should actually do is have a helper loop inside the DQMH which uses the active/idle broadcast event to start/stop polling internally. That would mean I wouldnt need to worry about working out which clones were idle as the clones would handle it themselves.


Exactly!


@psmorris wrote:

 

BUT, now I want effectively a "private" broadcast event so that only the DQMH module can register for the active/idle status... but a "private" broadcast makes no sense really in terms of a general DQMH. Alternatively I could switch the activity status broadcast to a private request event back to the DQMH and have that event queue a message to a second message handling loop which fires the actual update position request periodically when the module is idle... (I think I'd implement the helper loop as a queue driven loop, but when the module goes idle, set the time out to "n" ms and do my polling in a timeout case. Then when the module goes active, set the timeout back to -1


I would go for the private Request. You create a regular Request Event and then change its scope to private. I move it to the virtual folder called "Requests" that is already private and add a new virtual folder there called "Private Requests".

Then, do not register for this event in the EHL, instead register for it in the Helper loop.

 

When the helper loop handles the event that the module is idle, it sets the timeout of the event structure to the time you want to update the position, when the helper loop receives that the module is busy, then it sets the timeout of the event structure to -1. The timeout time can be transmitted via a shift register with an initial value of -1.

 

Hope this helps.

 

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?
0 Kudos
Message 15 of 41
(3,911 Views)
Solution
Accepted by FabiolaDelaCueva

Hi Fab,

 

At last I've got around to making some changes to the example code originally posted and building it in to a vip which I've attached. This should install the source and metadata files into the correct place to populate the template enum with a Message Pump template.

 

It sounds like a few people have taken this idea and run with it which is excellent - hopefully the updated code will be useful.

 

Cheers,

 

Pete

Message 16 of 41
(3,717 Views)

Hi Pete,

 

Thanks for sharing this template with us. I hope lots of people find it useful.

 

I did a quick review and I like that it works out of the box and it even comes with a template for a HAL. Kudos for that!

 

On my wish list:

  • when you get a chance and if you agree this would be useful for others, consider removing the #Code Needed tags that come from DQMH and the scripting tools and add your own pointing the developer as to what they need to do in different areas of the template to convert it into an useful module to them.
    • For example, you could add a #Message_Pump_Code_Needed tag in the factory pattern VI indicating that they need to put any other protocols in the same folder as the RS232. 

Thanks again for taking the time to create this template. 

 

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?
0 Kudos
Message 17 of 41
(3,704 Views)

Hi Pete,

 

I am working on an application that will have several DUTs running different test configurations (switch positions, frequency, etc.), however they will all be using the same hardware. Each test will be at an interval set by the user, but this interval will be quite long (probably around 30 to 60 seconds).

 

Each test can have a different total duration so they will be stopping and starting at different times. DUT1 could be every 30 seconds for a total of 24 hours, with DUT2 every 60 seconds for 7 days. A third DUT at 45 second interval could also be added at any point while these tests are running.

 

Bearing in mind I have not looked at your DQMH add-on, do you think that your Message Pump will support this kind of application? From what I have read the current applications are for a set period across all measurements/events.

 

Cheers,

Darren.

0 Kudos
Message 18 of 41
(3,385 Views)

Hi Darren,

 

Sounds good - I think it sounds like the message pumps could help. The code I wrote doesn't change anything about DQMH regarding the starting and stopping of modules - all it does is inject a message into the event handling loop at a regular interval which can be set differently for each instance of the module. 

 

You would still have a higher level controller vi/module which would start each module up, and either maintain responsibility for shutting it down or hand that responsibility over to each module.

 

I hope that helps, the code is really simple so I'd say take a quick look and I'm sure it'll make sense. Let me know if you have any questions.

 

Cheers,


Pete

Message 19 of 41
(3,381 Views)

Cheers Pete, I am now up and running with the hardware so I'll download it and have a look

 

Will let you know how it goes...

0 Kudos
Message 20 of 41
(3,370 Views)