ComRd* Bug or customer "fiction" ??

[wxfield]

Hi,

I'm using CVI 5.5 with Labview (on WinNT & 2000) to create serial port DLL's. Much of our serial com code has already been written in CVI, so it made sense to simply port the objects to DLL's for use with Labviews.

We noticed a possible bug last Friday where after interogating a serial device (no error correction) we expected to see a result returned. We used the Flush*()'s to clear the I/O buffers, wrote our command, sent it..and read back in a response. Each time we read the response it "seemed" as though our serial device was postpending high-order ascii characters to the output. We of course, took a look at the inline output of the serial device during this process and eliminated our proprietary seria
l device as being the culprit. Our only conclusion was that the ComRdTerm() and the ComRd() we were using was adding the unwanted characters to the output.

Our device doesn't support any type of error correction, but we aren't dropping any characters from the data. So we are a bit perplexed. Has anyone at NI heard of this ??

Kindest regards,
Warren Crossfield

[Chris Matthews]

Are you sure the strings you are sending in are NULL terminated? Remember C expects a NULL character (HEX 00) at the end of each string to know when the message ends. Make sure you are NULL terminating the string or the serial function may send some garbage bytes of the string at the end.

Best Regards,

Chris Matthews
Measurement Studio Support Manager

[wxfield]

Hi Chris,

Yes, we are sure. We are using sprintf() to build our command string, and as you know - it postpends a NULL after all other operations are completed. And we still get grabage postpended. I have just confirmed that this "weirdness" does NOT happen AS OFTEN on WinNT machines, but happens nearly 100% of the time on Win2000 machines.

-Warren

[Chris Matthews]

The garbage is on the response string though right? I was asking if you are NULL terminating the response strings after you read the response data in from the instrument.

Take a look at our CVI example samples/rs232/serial.prj. Notice on line 507 the CopyString function call that puts a NULL character on the end of the string after it has been read in. There is even a Note there to tell you ComRdTerm does NOT put a NULL character at the end of the string.

Chris

[wxfield]

Hi Chris,

Ok, I guess the confusion lies in the Online help. The Online help files don't mention the absence of the NULL in the returned data..but the examples files do?
The .c example file only mentions ComRdTerm(), does ComRd also have the same quirk? In other words, will it place a NULL after "read_cnt" bytes ??

Kindest,
Warren

[Chris Matthews]

I'm pretty sure ComRd does put the NULL character on there, but to be safe what I would do is initialize my strings with NULLs like this:

char readBuf[20] = {0};

That way you don't have to worry about it.

Chris

[NoVIsonme]

One of our customers had exactly this problem. ComRd does NOT append the terminating NULL to the string it reads. We got round it by Array[NumberOfCharsRead]=NULL. Simple but annoying to find.