DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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?

 

 

Jens_S_0-1669296298275.png

 

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?

 

0 Kudos
Message 1 of 6
(164 Views)

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 

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

0 Kudos
Message 2 of 6
(118 Views)

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.

0 Kudos
Message 3 of 6
(98 Views)

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.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

0 Kudos
Message 4 of 6
(83 Views)

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.

0 Kudos
Message 5 of 6
(66 Views)

@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

 

 


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

0 Kudos
Message 6 of 6
(37 Views)