Error handling using parallel while loop

[Tommy1977]

Hi all

First off: A recommendation 🙂

I am reading the Labview style book, which I can highly recommend to all.

Second:my problem

I am trying to implement the multiple loop framwork with a separate loop for error handling using a queue (p.282). 

However I cannot see how the errors are sent from the DAQ and main loop into the error queue. 

Does anyone have the template for this or have tried to implement something similar.

Best

Thomas

[Norbert_B]

Thomas,

you have to implement enqueuing in the 'producing' loops. This can be done in an error state in those loops in order to only send actual error information.

The biggest question is: Does the local produce loop have to react on specific errors other than just sending to the handler loop?

Example: You configure an invalid DAQ configuration. Hence, latest starting the task will create an error. OK, sending the error information to the error handler is easy by enqueuing the error to the error handler queue, but is it valid to stop DAQ loop? Or move it into an idle state?

Your requirements should define this....

Norbert

[Tommy1977]

thanks for the reply. I like the idea of using an error case in the producing loops, to send the error. I think that the easiest way to stop, is to let the producing loop stop itself. However, I can see the case where the error could instead prompt the user to plug in the daq cable, and in this case it would be better to use the error handling loop to control shutdown of the producer loops. But that solution is more complicated and time-consuming to code. Choices choices 🙂

If anyone has the template from the labview style book. of i would very much like a copy. It seems very well written, adaptive and comprehensive.

[Bob_Schor]

The LabVIEW Style Book was the second book on LabVIEW I purchased (the first one was labelled "Third Edition", and I've been lobbying one of the Authors to write the Fourth Edition, offering to proof-read it for him)(I made the same offer to Peter Blume), and the first one I read cover-to-cover three or four times.

Did this not come with a CD/DVD or a link?  [My copy is at home, and it's been almost a decade since I purchased it ...].  I have some files on my PC in a Bloomy Controls folder that date from 2008-2009, which makes them pretty old and likely "partly obsolete".  Check with the Publisher, or contact Bloomy Controls directly.

Bob Schor

[FM82]

I could never reccomend too much the reading of "The labview style book". I found it enlightening, my labview code has improved so much after reading it that i feel like a new programmer.

[pangvady · Accepted solution]

NI offers a library called the Structured Error Handler (http://www.ni.com/example/31253/en/) that you could build from. SEH fits nicely in the producer-consumer loop architecture. 

It allows you to "throw" errors from anywhere, with options to manipulate, prioritize, retry, or classify errors, and "catch" these errors in a asynchronously running loop that the SEH refers to as the "Central Error Handler". In theory, the Central Error Handler could prompt the user and send a message back to the source of the error to tell the offending module its next path in life.

[Tommy1977]

Thanks for all the help. The SEH looks very promising and I will try that first. It looks like it has all the functionality that I need. 

A comment on the whole add-on vi libraries in LabVIEW: From my perspective the VIPM is potentially filled with great code for all types of projects and I will try to investigate when I have time. Are there any other repositories that a budding (not so young programmer need to know about). Maybe there is some sort of great to know labview sites?  

[Jacobson-ni]

If you skip ahead to around slide 23, the webcast I linked below covers a bit of the SEH as well as local vs central error handling which might give you some good ideas.

http://www.ni.com/webcast/2711/en/

Edit: Slides 1-23 are just the basics of LabVIEW errors which it sounds like you understand

[Tommy1977]

Very helpfull, thanks.

[Bob_Schor]

The first thing my original LabVIEW mentor (everyone should have one!) recommended was the OpenG Library, which (before VIPM) was being maintained by LAVA.  Over the years, some of the functionality in there has been "folded in" to LabVIEW, but it still represents a useful collection of VIs and functions that "NI forgot to add".  From VIPM, install the OpenG Toolkit, which gets you the most useful 95% of OpenG.  Once the package is installed, you will find OpenG not on the main Palette, but listed in the Palette entries "below" the main Palette.

Bob Schor