garbage symbols in ComRd output string

[Sir]

So, my problem is: when I call ComRd function for a few time (the first call is allways OK!), I det more data in ComRd output string then it shoud be - for example, GetInQLen indicates thet is only 6 symbols, but the output string contains more.... This is not connected with late arrive symbols - the windows terminal show serial port input "is it shoud be"! Sometimes this unwanted "additional" symbols are a part of function names or path's, sometimes are a randomly symbols with no logic. What is it, and what to do?

[jr_2005]

If GetInQLen() indicates that there are only 6 characters waiting to be read, then you should only read 6. Reading more than this will result in garbage, as you have already discovered...

JR

[RobertoBozzolo]

If your instrument does not transmit the string terminator (NUL character), reading the variable with simple string management functions will result in the strange behaviour you are seeing, since for example strcpy will end only at the first nul character found and you will get all the garbage your string contains. You could try either filling it with 0 before reading or useing the return value from ComRD (actual number of characters read from the function) and setting variable[ComRdRetVal] = 0

[Mert_A.]

ComRd is returns the number of bytes successfully read.  Are you sure it is returning more than the expected number?  Keep in mind that ComRd does not nul terminate strings, so if you are expecting to read an ascii string, you need to put a nul character after the number of read bytes before you can read the data as a string.

Mert A.
National Instruments

[Sir]

Of cource I request only 6 symbols, as it determined by the exchange protocol with hardware on the other side of serial cable. But, any way, the output string MUST BY TERMINATED BY ZERO by serial port driver. And I must not get strings like XXXXXX34jdfs87hwquhzfdnwg0, where XXXXXX is correct responce from the hardware device, and the other is garbage from somewere...

[Mert_A.]

I may not be fully understanding you, but it would be undesirable for the serial driver, or the serial library to nul terminate returned data.  Data passed in serial communications are not necessarily ascii strings, and there is no reason to nul terminate (possibly incomplete) segments of a raw byte stream.  Additionally, if you request a read of 100 bytes, then pass a buffer that is exactly 100 bytes large, it is not large enough to hold the extraneous nul byte.

Mert A.
National Instruments

[Sir]

>You could try either filling it with 0 before reading I try to use constructions like this - Fmt(InputStr,"%s<%s",""); - in this case the string must by cleared and null-terminated, isn't it?

Message Edited by Sir on 01-08-2008 11:04 AM

[RobertoBozzolo]

Fmt and Scan, like all string-related functions, expect the strings to be nul-terminated, which your string isn't. There is a special notice on using non-nul terminated strings in the Formatting and IO Library reference, when treating scanning functions.

If you want to be sure that the answer from your instrument is nul-terminated you can either use one of the methods I suggested you before or StringCopyMax the exact-number-of-characters-returned-by-ComRd from the read string to an intermediate string: StringCopyMax automatically adds a terminator after copying the requested number of bytes.

I second Mert opinion that automatically adding a nul byte at the end of the received buffer would be dangerous: I am always speaking with devices that transmit raw data in binary format and a nul byte is as meaningful as the other 255 possible combinations: an extraneous nul byte could significantly alter the meaning of the message!