prevent a rs232 crash when "operation completed succesfully"

[Karel-K]

Dear all,

A certain test set-up should run for long times (months) and makes good use of RS232 comunication (over USB). Data rates are not high, but frequent, to four different devices.

Very occasionally the application crashes (in debug mode, running from CVI, not as stand-alone application).

It crashes in the ComWrtByte function, with error code -1, and CVI reports:

NON-FATAL RUN-TIME ERROR: "c:\FlexHeadControl\Relay_RLY08.c", line 105, col 9, thread id 0x00000ABC, function id 1: Library function error (return value == -1 [0xffffffff]). The operation completed successfully.

Well, if it completed succesfully anyway, why doesn't it continue to run?

I wonder if there is a way to handle this very occasional error, such that the application can continue (after some apropriate error handling) without manual interruption.

The program crashed on the first of the following two lines (which have been executed before hunderds of times):

ComWrtByte(device[iB], byte);
ComWrtByte(device[iB],13);

How does error handling work? Will it prevent crashes if I follow the error handling suggestions by CVI-help:

int ret = 0;

ComWrtByte(device[iB], byte);

ret = GetRS232Err();

if (ret<0)

{

   //error handling (for example resending, or reconnecting)

}

Will running in normal mode (as a .exe) instead of debug mode, outside of CVI SDK work?

I ask this since the error occurs very infrequent but may still ruin an experiment of months...

Many thanks for any explanations, tips and programming examples!

Karel

[RobertoBozzolo]

First of all, a return value of -1 means "Unknown system error". The operation completed with errors, so it's good to have a warning. A negative value always indicates an error, as you can see in the help.

Dealing with the popup error message is wuite simple: go to Run >> Break On menu item and deselect "Library errors" item. With this, the popup message won't show any more, but you will need to add the proper error handling based on the return code from the function like you have already shown in your post.

[wdmot]

I had this happen just now with LabWindows 2015 on a system with several RS232 devices (some RS232 over USB). Sometimes calls to serial functions such as ComWrt, ComRdByte, or FlushInQ generate an error -1, but a subsequent call to GetRS232Error() provides a message "The operation completed successfully." Did an error occur or not?? If so, how can one figure out what error actually occurred?

[RobertoBozzolo]

Debugging RS232 errors can be tricky if you happen to use multithreading or asynchronous operations. The rs232err variable is not multithreaded safe while ReturnRs233Error () function is, but both can be fooled by async operation on the serial line that may happen somewhere in the program. Only using the return value from RS232 functions you are sure to monitor the operation in progress. In case this value is -1, an immediate call to GetRS232ErrorString () should return the error encountered by the OS, provided no other I/O serial event has occurred in the meanwhile since that one could mask the error if successful.