LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH driver with OOP for HAL aproach

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. 

0 Kudos
Message 1 of 3
(154 Views)
You can create a child class and override the Dequeue behavior to have a timeout if you want. For repetitive tasks I like having the helper loop continually send the request, but I send it through a request event, not directly to the queue like you've shown here. If you're afraid of overloading the number of requests, you can use a "request and wait for reply event" and just ignore any timeout errors. Then if your main loop is busy, you know you won't send a new "get status" event until the timeout has elapsed, which could be a couple of seconds. (5 seconds is the default)
0 Kudos
Message 2 of 3
(143 Views)

Thanks Gregory

 

Sounds really simple and good idea to create an event with wait for reply for "get info" i will try the performance in a new version of my driver and come back with my comments.

 

Best regards

0 Kudos
Message 3 of 3
(140 Views)