Buffer overflow serial communication

[mqamar]

I input a command (ex: *TST?) in labVIEW and run the serial communication VI example. The output after a clean run should be '0'. But, it says that there is some kind of buffer overflow. My bytes to read is set to 4. I change this to many different numbers, and i still get the same error. Now, if i change this byte read number to 0, the simulation runs fine, with no error. What does this mean???!

Also, do my labVIEW "baud rate" and device "baud rate" have to be the same? i am new to labVIEW altogether, so i dont even know what baud rate is.

My other guess was that the buffer/register of my device (power meter) might have information in it already, so i tried to clear it by the clear commands using the device's manual, that didnt do anything either.

Also, does it make a difference if the termintion character is ON or OFF under the subVI of "VISA Serial" ? i mean, either way, i get the same buffer overflow error.

Anyway, this is all the stuff i have done and make gotten the same error. After reading this, do you have any other suggestion? i am kinda stumped at this point. Do you think that i shouldnt be even using that example serial comm.VI. Any kind of suggestion that might give me any insight will be greatly appreciated. THANKS!

P.S. I have tried manipulating the Tranfer Buffer size and Recieve Buffer size from the advanced options from the device manager in windows, (i am using Win 2000 Pro.) ... but still i get the over flow!!! :headbang:

[Louis Manfredi]

Hi Mqamar:

May not be able to answer all your questions, but here is some information that may help:

Definitely the baud rate of both devices has to be the same. Baud rate is the speed at which the communications between the two gadgets occurs (in bits per second) If they are not set to the same rate, they can't talk. (This isn't special to LabView-- just a basic truth of serial communications.)

Sometimes devices will "autonegotiate" a baud rate. If you hook two systems up and have one try to talk to the other, it will keep trying different baud rates till it finds one that works. Sometimes that autonegotiation of baud rate can result in a bunch of junk collecting in the communications channel-- which might be important, see below.

Sending a clear command to the power meter might clear the power meter, but there might be bytes sitting in the hardware input buffer of your serial port, or in a software buffer in Windows and a command to the meter won't fix that (might even make it worse, if the power meter acknowledges the clear command with a message.) What I often do, if serial communications doesn't work, is flush the input buffer-- Inside a loop, read all the inbound bytes (throw them away), wait a bit --10 ms?, and then loop, keep doing this until you read zero bytes-- Then you know the inbound buffer is empty. After that you can send out your command and wait for a response, knowing for sure that there isn't any junk sitting ahead of the response in your inbound buffer.

Note that autonegotiation of baud rate can result in junk collecting in the serial port buffer, which might be the cause of the buffer overruns you are getting. Since that junk may have been sent at the wrong baud rate, it might be unprintable characters. Perhaps setting the number of bytes to read to zero is a code for reading all the bytes available, and you are getting a bunch of unprintable stuff (which you don't see) followed by the response to your *TST? command, which you do see. If you are displaying the message as a string on your front panel, try turning on escape code display to see all the unprintable stuff. (right click on the front panel indicator--the chocie should be on the list.)

Not sure if this is what is happening for you, but hope I've at least given you some ideas to try. Doubt that the transmit and receive buffer size in device mangler is the central issue, but I would set both as small as windows lets you, and leave it that way until you get things working.

Good luck, Louis

[Louis Manfredi]

Hi Mqamar:

One more thought-- Perhaps the device is sending more bytes than you think it is-- If you are expecting a message back, remember that the device might send you just the actual printable characters you expect, or it might send those followed by <CR><LF>, displaying the escape (non-printable) codes should help with this too.

Best luck, Lou