04-12-2020 07:20 AM - edited 04-12-2020 07:41 AM
Hi Everyone
I am currently looking at how I deal with errors in my applications (all of which use a queued state machined with multiple modules), and considering how I can improve it.
At the moment I tend to have single error handler VI at the end of each module loop which runs the General Error Handler VI to display the error. This VI also logs the error (Just the error code and message) to a file. I use this file to keep track of errors that I have to fix during development of an App as well as logging errors when my customers are using it so I can try and identify what has caused the crashes that they are trying to describe (often vaguely and with much arm waving). Below is an example of one of modules.
My question is, does anyone have any suggestions on improving the information which is logged to file to better understand the events which led to the error (breadcrumbs). I am currently considering storing the last 10 states state which have been called in the module along with the data associated with it (My queue elements are all clusters containing a 'command' enum and a 'data' variant.) (edit, upon reflection, storing the current state and its associated data might be the extent of this approaches usefulness)
This is going to make for a potentially messy file, especially if I store it as a plain text file which would be my preference.
I would appreciate any better ideas that people may have.
Thanks in advance.
04-12-2020 09:06 AM
I can't visualize the tiny picture (I rail against pictures of Block Diagrams in LabVIEW Forum posts asking for help -- I can't see the details, I can't "closely inspect" the diagram to click ^H on an unfamiliar function and get LabVIEW Help to tell me what it is, I can't test it to see its behavior, I can't edit it to see if I can fix it ...) so I don't really know what you are doing.
.
I would recommend saving to a log file the Error Message (which gives you the Call Chain for what was running at the time of the Error) and the Enum showing the current Message (State). As I recall, there is some code in one of the Example Templates shipping with LabVIEW (possibly the QMH) that shows such a logger. If you want to "log, clear the Error, and keep running if possible", then you can pop up a little Dialog Box that self-destructs after a few seconds that shows the Error.
Bob Schor
04-12-2020 10:01 AM
Apologies for just the picture, I understand your aversion to them. I didn't want to add any actual VI's because I wasn't asking about 'how' to do it, more at a higher level 'what' to do and din't want to confuse matters too much.
The more I think about it, saving just the current module state and the error message is probably as good as it is going to get.
I was hoping that someone else had better ideas for what other information can be stored upon the generation of an error which aids in working out what happened at a later date.
04-12-2020 10:53 AM
I do something like that, but I also include an input to the logging subVI that is a string. That way I can put a note in the file as to which copy of the subVI called it.
So the string might say DAQ Loop, or Logging Loop, or Calculation Loop. Whatever I need to I know which subVI is logging the error to narrow down the source. I might also have a boolean input so that I can decide to log only on error, or log on warning, or perhaps always log the data coming in. You can build other info into the string such as iteration number, or state of the state machine, anything that helps the debugging process. So you aren't just logging the error, but some other useful information.