LabVIEW
visa serial port and while loop
Solved!
Since we have changed to discussing error handling here is what I do.
I find I use state machines a lot of the time so I have made it a habit to do this.
If an error occurs in any state it is acted on instead of going to the next state.
Then in my error case I shutdown all power sources and display a message or handle errors that can be dealt with without aborting.
@Edjsch wrote:
Yes, I do act on all errors. Unknown ones are just cleared. Read up on error handling. Sometimes this is the last resort. My application has thousands of users, and never has anyone reported an issue with this.
<How about an error setting up your com port like it's missing?> That CANNOT happen. The VISA Resource Name drop-down list box only shows ports on the computer. If you type in a port number that doesn't exist, no port is opened. If the user tries to send a query anyway, Bytes at Port == 0, so I put up my "no data received" error informing the user of possible causes.
Well, I can't get you to wear a seat belt. Maybe the customer doesn't even know there's something wrong with the application. Maybe they're missing data and don't even know it. Don't swallow those errors arbitrarily. Just don't. At least log the error information somewhere.
@Edjsch wrote:
Ok. Say I eliminate the Clear Errors vi and select a dialog to display in the Simple Error Handler. Do you know what happens? You get some obscure generic LabVIEW error message that often (not always) gives you no indication of what happened. Then you Google the error message, and often you get nothing useful either. I don't want to subject my users to that.
< Maybe they're missing data and don't even know it.> NO, NO, NO. You're not comprehending. Missing data is one of the most egregious errors possible, and I DO notify the user when that happens. One of the first rules of error handling, is to handle it in your code before the system generates an error. The last ditch attempt is an error handler vi, like a try-catch construct in C++, C# or VB.net
I think we're just not good at communicating to each other because the more you post, the better I feel about your error handling methods.
I agree with your "one of the first rules" because that's probaly THE FIRST RULE.
I would let the errors propagate to your last-ditch error.vi. All the errors you need to have handled are already handled (like your timeout handler). Any unexpected error gets handled by the last-ditch error handler.
The last-ditch error handler was actually what I was advocating for.
But I do stand by my advice to let unexpected/unhandled errors propagate to this last-ditch error.vi rather than eat them.
I have to add that there ARE exceptions to this rule. i.e., an overnight burn-in. In that case, maybe you log non-critical issues and continue - BUT, you still have to know which are non-critical and which will cause you to bring the chamber to ambient, shut off the power supplies and exit the application (or bring it to a safe state and hold there).
<You don't crash the executable.> Of course not, and I don't. (However, sometimes stuff happens, like a driver, memory, or PC hardware error that causes an application to crash. Another manifestation we've all seen a lot is a poorly-written web page hanging the browser. When you look in Task Manager it says "Not responding", at which point your only resort is to end the task.)
<You handle unexpected errors by shutting down gracefully.> Yes, but sometimes, as in my case, there is no need to shut down at all. What's the point of closing my application just because the user doesn't have the serial cable plugged in, is at the wrong baud rate, or his instrument is not powered on? Shutting down is a last-ditch attempt when hardware or some other resource the program needs is not functioning or available, and staying running poses a threat. This is not my case.
I think we've beaten this to death. If you want to continue, please start another thread.
Cheers. 
