DQMH instrument driver using OOP for HAL continuous queries

[Zepeda79]

I have a DQMH module for an instrument driver, i replaced the Data cluster for an instrument class in order to use OOP HAL for having the capability to use different instruments using inheritance, i used to do this with a different approach, not DQMH but something similar, i implemented the events (commands) and also in the timeout event of the deque i had an implementation that gets many data from the instrument in order to maintain the status updated, specifically for a power supply for example... in the consumer loop is implemented every command and query that can be called and executed outside the VI or even in the same VI as manual control for the driver, something like set voltage, set current limit, set display on/off, set output on/off, in the terminal timeout of the deque there is a timeout specified, so, if no commands (messages) are received in that amount of time, the code in "timeout" event is executed, in this event are executed a set of queries like, get voltage, get current, get status, get range, get setpoint, get errors, etc.

Now with DQMH i want to do the same, i have implemented all the commands (events), but i don't know what can be the best way to perform the continuous get info sequence, the DQMH Dequeue Message VI does not have the timeout option, i know i can create an additional VI and replace it and even create a new template, but also i read somewhere that this is not a good idea. I have an implementation now running, i added a helper loop that triggers the "get info" in MHL event every amount of timeout, in the MHL i "turn off" the timeout in helper loop in order to avoid new "get info" command is triggered while something is in process and avoid some problem with accumulated messages in queue, apparently is working but maybe there is a most straightforward method to do this.

[Darren]

I like the idea of using a helper loop. I would go a step further and put all the instrument communication in the helper loop instead of the MHL. That removes a layer of unnecessary inter-loop communication.

[drjdpowell]

I suggest, instead of a "get info" message from your helper loop, have a "check if it's time to get info" message.  The QMH loop would record the last time it got info and would be able to ignore any build up of messages while it was busy.

[Olivier-JOURDAN]

It seems to me that the helper loop is definitely the way to go for a repeated action. As Darren said, I would  "put all the instrument communication in the helper loop".

To ensure correct timing, I recommend using the open-source toolkit I created. You can find more information on how it works here.

[Zepeda79]

@drjdpowell

I am trying to understand your idea, something i can figure out is where to "check if it's time to get info" should be, if is in the MHL it should be an event triggered somewhere.

[Zepeda79]

Thanks Oliver-JOURDAN

I taked a brief look at the API, great job, i was doing something similar (but very basic) in other applications, but i am trying to implement this helper loops with DQMH, the approach of having all the instrument related events is what i am looking for, i understand the way that the API works and i am agree with your recommendation to have al in the same loop, my problem is that the native DQMH deque does not have available the timeout, and your API is not a DQMH that is what i am trying to implement, maybe is a way to integrate this in someway, the way that is in my head for now is to have a helper loop that receives the event commands from the MHL of the DQMH but seem to have more complex flow. 

[Olivier-JOURDAN]

Thanks for the feedback @Zepeda79.

I probably missed something important in your goal. Helper Loops is a kind of native DQMH feature. It's the recommended way to execute periodic code --> https://documentation.dqmh.org/dqmh/7.1/AddHelperLooptoDQMHModule.html

Why do you need the MHL to execute your periodic code? The helper can handle the periodic code and the other instrument interactions.

Can you rephrase your goal and why the HLoop is not the correct answer for you?

[drjdpowell]

---

@Zepeda79 wrote:

@drjdpowell

I am trying to understand your idea, something i can figure out is where to "check if it's time to get info" should be, if is in the MHL it should be an event triggered somewhere.

---

I was giving a suggestion for your current design of doing the work in your main MHL, triggered by a periodic message from your helper loop.  Specifically, my suggestion was about how to deal with your MHL being busy and messages to it building up.

[drjdpowell]

---

@Darren wrote:

I like the idea of using a helper loop. I would go a step further and put all the instrument communication in the helper loop instead of the MHL. That removes a layer of unnecessary inter-loop communication.

---

Note: this advice of instrument communication is not necessarily a good one. It depends on how complex the problem is; one could easily be adding rather than avoiding unnecessary inter-loop communication by putting it in a helper loop.