Jump to content

Reg. Centralized error handler.


Recommended Posts

Hello All,

 

 I have one doubt about the Centralized error handler.

 

1. Centralized error handler?

It means we should have a one controller or centralized error module that talk with error API that we have included in to our all modules like user console, sensor etc.

 

2. or just having a FGV is fine for Centralized error handler.

 

Can any one  please help me in understanding about the term Centralized error handler.

 

Thanks In Advance.

 

Hemant

Edited by Hemant Chourasia
Link to comment

There's lots of topics on central error handlers, and multiple NI Week sessions have been dedicated to them.  As for your implementation, it is up to you.  A FGV can make for a fine central error handler if all you want to do is log all error from all locations, email someone on an error seen, or shutting down on specific errors.  But of course if an error comes in at a code module, then it usually makes sense to try to handle that error as close to where it was generated first, and only letting unhandled errors get passed to an error handler.

Link to comment

In my own words I'd say a central error handler is a separate code module (ie. library, class, while loop, VIG) that is dedicated to capturing and reacting to errors generated in other code modules in the application.  This allows for errors to be organized by their origin, time, or other factors.  A few possible reactions to an error coming in can be to log it, notify the operator with an asynchronous dialog (allowing for the application to continue to try to operate), notify the administrator (email, SMS, etc), or shutdown if a specific error, or enough errors are seen (if your application sees 100 errors in one second it is safe to say you should probably just shutdown safely).

Link to comment

These forums are for general discussion and without you mentioning the CLA I didn't realize this was in relation to that.  Now that I see your crosspost over on the darkside I realize this is talking about the CLA, and for that I think I did have a separate running parallel loop (like actor) that received messages from other parallel loops, and then had comments stating what to do with the newly received messages like "Add code for logging all errors here" and "Add code for performing asynchronous dialog here", but didn't actually implement them.  I don't remember the specifics if the requirements talked about having to do anything with the errors.  You'll want to read the requirements and determine the amount of work you need to do to cover them.

Link to comment

Thank you very much your responses really appriceted and thanks a lot.

But when ever I am using QMH for centralized error handler, I am encountering following problem. Thats why moving to FGV, block other process. 

1.  Let us say error occur from user console and error handler display error to user with the option to clear or continue.

 

This needed user interaction to carry on. Even though my controller is executing without user interaction, idley controller should come to halt as soon as error occure or timer should stop.

 

2. For stopping all the module's,  I am broadcasting the stop flag for stopping all module(centralised error using QMH  and etc. using user event. In this case am unable to trap any error which is coming from shutdown state as my error handler, QMH has already been stopped or exited.

 

Thanks

Link to comment

There's lots of solutions, and anything I'm going to suggest might work or might not work depending on other factors about the design I'm unfamiliar with.  

For you number 1 issue in my designs the central error handler is a parallel running loop that doesn't halt the rest of the application asking the user if they want to continue or abort.  My dialog just informs them of when the error happened, what the error was, and where it came from.  My other code modules are written in a way that they should retry what they were doing, by reconnecting, or to go into an inert state where they only send some type of reset command to the hardware they are talking to.  In neither case does the error dialog block anything.  If you are using a FGV with a dialog, then that will block the flow of data which it sounds like youi don't want.

For your number 2 issue I've seen something like a variable that gets incremented for every code module (actor) spun up, and then decremented for every code module that shutdown.  Then only when this value is 0 does the error handler loop shutdown.

  • Like 1
Link to comment

Sure blocking in these situations are fine, but for me many of my tests run for months unattended, and having a prompt come up and ask what the user wants to do, may leave the DUT in a weird state for a long time that could be dangerous, or at least invalidate the rest of the test.  Prompting to continue is not something I do often, and usually it is only in the part of the application where I know the user should be there.  Like if the user is setting up a test and they forgot to configure something I will prompt them to continue or go back and fix it.  In this case a dialog is fine, but mid test is a poor place for a dialog in my applications.

  • Like 1
Link to comment

Right, dialog in mid of the test may also lead the memory full error if you have asynchronous error handling..

Not if it is done right.  Either have a circular buffer of errors as a history, only show the last error, or cache the errors to disk.

3 hours ago, Hemant Chourasia said:

Instead of dialog in mid of the test its better to have some kind of status as string or something.

That's a fine idea but it doesn't scale well to large applications.  You now have this inherit coupling between the error handling code, and the UI that the user sees by passing control references around.  It reduces modularity, but in a pinch works fine.  I probably wouldn't do that in the CLA, and am unsure how it would score using that technique

  • Like 1
Link to comment

Thanks for the your reply.

Circular buffer and show last error, good idea.

As for just CLA, i think blocking other process it being fine if error occur in any other module.

As from the sample exams ATM,car wash and elevator, it seem FGV well suited in that type of scenario. 

Have you seen this samples exam any time?

What do you thing FGV is fine or not.?

Thanks in advance.

Link to comment

Look at the error handling requirements section of the example CLA exams:

ftp://ftp.ni.com/pub/gdc/tut/cla_sample_exam_atm_machine.pdf

Also there are some example exams and answers on this NI page.

http://www.ni.com/gate/gb/GB_INFOCLAEXMPRP/US

Do the work that covers the requirements.  I'd recommend a separate running code module, but a FGV may meet all the requirements depending on how it is implemented.

  • Like 1
Link to comment

Here is a useful nugget on the CLA over on the dark side:

http://forums.ni.com/t5/Certification/Certification-Nugget-CLA-Certified-LabVIEW-Architect/m-p/3165461

I took 1 hour creating a module template (actor) that was library based.  It has a core VI with a while loop QMH with template cases like Error, Event, IDLE, Request, Send Reply, and a couple of others.  This used user events to send and receive data which I made a few templates for.  After this first hour I copied this library into all the separate code modules I knew I would need.  Then I spent about 2 hours coding up the code, putting down comments on how something would talk to something else, or where data needed to be handled.  The last hour was documenting, which included VI icons, comments, VI descriptions, and the tags.  All you do for the requirements is place a [Covers: XXX] comment.  Did you look at the example exams I linked to which have example solutions?  It shows how this is done.

Link to comment

Actually I have already looked into the sample example and hopefully I will be posting my attempt in the coming weekend. I am practicing for a while now. 

But sometimes doubts are coming.

After looking into the sample exam also I have doubt about tags placement.

1. Regarding tags,  it should point to the exact location where the requirement has been covered or how to place a tag if there is doubt about the tags.

Thanks

Link to comment

Generally the rule I followed was to place the tag, along on the block diagram, in the state (or case) that was going to cover it.  If it was just a utility VI without a state machine it was just on the block diagram near the code that covered it, or in a blank area with the comment stating what the developer should finish and how that would cover the requirement.

Link to comment

Must of these questions are covered in other CLA material, and the articles already linked to.  I'm not overly qualified to talk about CLA specifics, only my experience.  Every VI must have at least one block diagram comment, and every VI must have a VI description.  I can't remember if every control I made had a description or not.  I didn't bother with tip strips for the CLA.  Style to me is mostly code cleanliness.  Do you have many unnecessary wire bends?  Do your wires cross lots of other wires?  Do you have very nested structures?  These could all be signs of poor style since type defs, libraries, classes, and subVIs can make the code easier to read and follow.  You may want to check out the VI Analyzer which scans your code for style like this.  NI uses this for grading but doesn't share the specifics of what the tests and criteria are.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.