How to treat error handling in the consumer loop in the queue message handler structure?

[William1225]

Hi,

I'd like to know how to stop the producer loop(event loop) in the QMH structure when the error happened in the consumer loop.

I've construct a demo code by myself as the attached image, but it's a pity that I have to create a recdundant indicator "End" to trigger the value change event to stop the program. This is not a good way to do it. Could someone give me some better idea how to deal with it? Very appreciated to you sharing ideas.

[crossrulz]

I like to use User Events to force the Event Structure to do things for me.

You could also make Stop non-latching and use the Value Change (Signaling) for that control and be sure to set the switch back to FALSE in the event case.

[GovBob]

Here is an example.

Hope this helps.

[mikeporter]

Concerning your doubts about the "traditional" implementation of this pattern, I hear you. As I have written many times before, its main benefit is that it is easy to explain in a training class. It unfortunately has a lot of drawbacks.

Tim's suggestion about User Events, is a good one. But to use it to the best advantage, you will need to get away from having everything on one block diagram. If you think about it there is no real need for the two loops to be on the same block diagram and a lot of really good reasons for them not to be. For example, if they are in separate VIs, they can both be event driven and any communication problems between loops evaporates.

Its also more modular, easier to maintain, more reusable, etc...

Check the link in my signature.
Mike...

[Bob_Schor]

The QMH is basically a While loop that dequeues a Message + a Case Statement that acts on the message.  I'm going to assume we are only worrying about errors in the QMH's Case Statement (if an error occurred in the Event loop, it could be handled in a similar manner).  Note this assumes we've designed the Message Queue so that the dequeue never causes errors.

So the only source of an error is inside the Case Statement of the QMH.  I put a "Trap Error" sub-VI following the Case Statement.  If there is no Error In, it does nothing.  But if there is, it calls a Handle Error Message, with the Error as the Message and the Error line cleared.  At present, I am not passing in the previous Message (which could be used in deciding how to respond to the Message), but that could be done, as well.

So if an error occurs within the QMH, the next "Message" will be "Handle Error", with the Error available as a parameter.  Depending on the nature of the Error (and possibly its context), you can take appropriate action, including causing an orderly exit or "fixing" the error condition.

I got the idea for doing this by looking at some of the Data Acquisition Project Templates that ship with LabVIEW (2012 and later).

Bob Schor

[kotha_mahesh]

Amazing Thanks