Error in MHL not added at the front of the queue?

[Jens_S]

Hey!

Today is stumbled across a very strange behavior of one of my DQMH modules. After calling a few request in quick succession (where each of the MHL cases takes quite some time to finish) the second one fired an error in the MHL. I'm expecting to get this error for some testing but realized that the corresponding error message and error handling only executed after the last of the enqueued requests has been finished.

After a bit of digging I found the "Check Lopp Error.vi" which is adding the "Error" message to the MHL queue. To my surprise the "Error" message is added at the end of the queue.

I could swear that the error messages were always placed at the beginning of the queue. Could it be that this behavior was changed once?

I would like to change this behavior to handle my errors as soon as possible after they occurred. Is there anything wrong that I've missed with placing error messages at the beginning of the queue?

[Ozfarmboy]

It has always been like this.  I recall wanting to do the same 2-3 years ago. 

I have two suggestions:

1) The workaround - straight after the MHL case structure, put another little case structure in to flush the queue if an error has occurred, and then the next MHL case will be the error case (and nothing else will follow unless more items were put on the queue in the meantime via the EHL).

2) Redesign your workflow - Sounds like you may be falling into the trap of making your QMH a state machine and you have a number of cases buffered up in the queue.  This is not recommended practice as you can't guarantee the sequence of events (ie. a high priority element can override this order and muck it up).  I would review your design and see how you can change this.  If you need a state machine, then consider creating  a state machine in a helper loop 

[Jens_S]

Thanks for your quick response!

1. Sounds like a solution but flushing the queue is something I don't need. If I ran into an error then the error case decides what to do with the error. In most cases it just needs to generate an error message and clear the error afterwards.

2. I definitely don't have some kind of state machine in my QMH. The requests that are buffered up in the queue don't need to be handled in a particular order. They are simple request to execute a specific test and now and then they get added a lot quicker then they can be executed (which is totally fine). If one of the test fails for an unknown reason I want to see why right after the test failed and not minutes later after all the other test in the queue are finished.

So right now I still consider overwriting the the DQMH Error Handling VI. If a test failed for some reason and the error handling case decides this is some critical error the module will be stopped immediately so the queue will be flushed anyway.

[Ozfarmboy]

Also, you could just call the Error Reported broadcast VI straight after the MHL case has finished if an error is coming out of it so that whoever is listening to the error reported broadcast will get notified straight away.

[Jens_S]

Yes, this would also be a possibility, but the error handling would still be done after all other requests from the queue have been processed.

I am still trying to understand why an error should be handled in the "error" case only after all other requests from the queue have been processed. As long as the requests to the module are relatively slow and the queue doesn't really fill up, it's not a problem or simply not noticeable. However, as soon as you have to process many requests and still want to achieve the fastest possible error handling, this does not work with the current implementation.

Using the error broadcast event at the end of the MHL feels more like a workaround than a solution, especially since simply setting the "Priority Message" flag in the "Delacor_lib_QMH_Check Loop Error.vi" achieves exactly the behavior I would expect.

[joerg.hampel]

---

@Jens_S wrote:

So right now I still consider overwriting the the DQMH Error Handling VI. 

---

First of all, leveraging LVOOP to overwrite the DQMH Error Handling.vi is the way to go here. That's why the module admin is a class after all.

---

@Jens_S wrote:

The requests that are buffered up in the queue [...] I want to see why right after the test failed and not minutes later after all the other test in the queue are finished.

---

It is not a recommended practice to fill the message queue with messages for actions that will take minutes to execute. I agree with Chris that there might be potential for improvement in the design. 

Spoiler

Personally, I would most probably go with a state machine for that kind of "sequence" of test steps

[Jens_S]

---

@joerg.hampel wrote:

It is not a recommended practice to fill the message queue with messages for actions that will take minutes to execute. I agree with Chris that there might be potential for improvement in the design. 

Spoiler

Personally, I would most probably go with a state machine for that kind of "sequence" of test step

Thanks for your input 👍. I think I still need to clarify a few things here and there.

1. There is no sequence or order of request in my MHL queue, just a few tests that sometimes get added in quick succession.
2. We test 6 similar but still different devices where each test is more like a complex test sequence. Starting the test takes some time (up to 5 min) and involves a lot of small steps which are handled by a state machine.
3. The module is only responsible for managing a test queue and to start or stop tests so there is a lot of idle time in the MHL.
4. The tests themself run for at least 24h and are observed by another cloneable module instance for each test.

I know my application is no the most common in terms of test duration but splitting up the test start and stop procedure is just making them more difficult to handle and feels unnecessary. If I add test for all devices it will take approximately 20 min to start them and I don't want to wait that long until I get a response that something went wrong starting or stopping a test. That's why I was wondering why the error message is enqueued at the end of the queue and not at the beginning.

[drjdpowell]

---

@Jens_S wrote: That's why I was wondering why the error message is enqueued at the end of the queue and not at the beginning.

---

I think the DQMH inherited that from the original NI QMH template (that DQMH is based on), so I'm not sure anyone is going to be able to supply a reason.  

[joerg.hampel]

Thanks for elaborating, Jens. I agree that your use case is valid and makes sense. 

With that being said, in my own, personal opinion, I still believe that the message queue is not the optimal place to handle the execution of your tests as an error should be able to cancel the execution. This feels like your application logic is mixed up with the framework functions.

Instead of overwriting the DQMH message queue or modifying the error VI, I would probably go with a separately and manually implemented registry for your test steps, maybe another queue or array or similar, which you have full control over, and which you can design in exactly the way your use case demands. 

But that's just my 0.02. I'm eager to hear other people's opinions.

PS: James is right, the original QMH design only prioritises the "exit" message. An error is added at the end of the queue.