Error handling rationale

[bratdv]

Hi,

By default, the error message enqueued in Check Loop Error.vi is not flagged as a Priority Message:

I wonder why is this? In the case when multiple messages are already in the queue, error case executes only at the very end. Don't we want to handle an error ASAP?

I know I can create a child class and override the VI, but honestly I am afraid to do so, since I do not have a lot of experience with OOP and am not sure how to manage/maintain this new class accross multiple projects:where to store in on disk, how build an executables with it, etc.

Thank you!

Best,

Anton.

[ChrisFarmerWIS · Accepted solution]

This question comes up every so often.  I asked it back in the day too.

The general feeling is that messing with the queue order is generally a bad thing, and should be done so exceedingly sparingly. It is recommended that errors are handled as close to the error source as possible. Only the Stop module is high priority because normally you need that to happen right away.

In the early days, my modules were doing a lot of self-enqueuing, and therefore the MHL is being buffered up quite a bit - and hence if an error occurred then it would be at the end of that queue waiting to be handled. What I ended up doing to get around this is I check if there was an error coming out of the MHL case structure, and flushing the queue if there was. I do this before the DQMH Error Handling VI, so that the very next item in the queue will be the error case. But I've essentially aborted all enqueued cases as a result of this. In the end I was ok with this process because I didn't want the subsequent cases to be acted on if an error occurred half way through. The error case was designed more of a catch all. But we don't write code like this anymore, and avoid the self-enqueueing. This was an early piece of code.

At the end of the day, you can override the DQMH Queue class to make it do what you want.

[drjdpowell · Accepted solution]

Errors in doing an action should be handled before the next action, so that should be a "Priority message", I would think.

[Olivier-JOURDAN · Accepted solution]

---

@drjdpowell  a écrit :

Errors in doing an action should be handled before the next action, so that should be a "Priority message", I would think.

---

My personal approach is to treat errors I want/can treat where they occur (i.e., before the error case). I'm using the error case as the collector of all the unexpected errors I can't treat without modifying the code.

In that way, I'm really fine not having the error message as a "priority message".

[bratdv]

First, I wanted to thank all those who have replied and apologize that I may be using the forum wrong by answering the last person when I actually wanted to address all previous replies.

Your answers, being rather controversial, made me re-consider how I use QMH (or DQMH). In this project I am working on a production station that does optical assembly. I am interfacing a lot of hardware (laser, cobot, linear and pneumatic actuators, valves…) and making a sequence of actions that eventually lead to a complete assembly. For process control logic I use DQMH module, each case is an action. I create an array of messages and enqueue them at once. After the last action is finished, I move to a different array of actions and so on. Basically, using MHL as a sequencer.

The appealing part is the ease of creating the list of actions: adding new steps, swapping steps, re-using steps is as easy as create a case and edit array with the list of actions. The downsides: list of cases in MHL structure does not fit in my screen (a few dozens) and error handling. This is where I started the topic – I want to “handle” an error right away, typically by aborting the sequence and indicating the reason to an operator. When I was using QMH I just set the priority flag for errors and they were enqueued in the front of the queue to call error case. In DQMH it is not as easy, since I am supposed to create and edit classes that I am not comfortable with yet.

Well, now I think that I am abusing QMH. After some reading, I realized that Queued State Machine should be more suitable for my application. I am still learning the difference QMH vs QSM and yet need to find a textbook implementation to learn from and try to convert my code.

[joerg.hampel]

Whenever we need a sequence of steps (and there is not a dedicated sequencer like TestStand or DTS available) we resort to our State Machine template. 

Feel free to take a look and see if it inspires (or just go ahead and use it as is):

https://dokuwiki.hampel-soft.com/code/dqmh/state-machine/overview

Personally, I cannot recommend it highly enough.