Visa Read Overrun Problem

[LVCoder]

Dear all,

I am using VISA Read Function to read data coming from my Hardware.

The data is coming really fast. The H/W is sending 1600 bytes after every 10ms.

I am using Event Structure(timeout event) to check whether 1600 bytes are at port or not. Timeout is set to 1ms. i even tried with 0ms.

Baud Rate = 3000000.

but the program is giving Buffer Overrun problem when i am trying to read data using VISA Read.

I have set the buffer size to 64000 but with no success. The problem still seems to persist.

i have played around with Receive buffer of COM Port in device manager. i tried all the values from 64 to 1600, again with no success.

every time i run the program i get an error stating,"A character was not read from the H/W before the next char arrived" at VISA Read Function.

and i am not doing anyother processing other than Reading data from the Port in the timeout event. 

What could be the problem?

 Thanks,

Ritesh 

[RavensFan]

How are you able to set a Serial port to have a baud rate of 3 million bits per second?  I wouldn't even think that is a valid serial port setting.  That is about 300kB every second.  What are you communicating with?

What do you do with this data once you recieve it?  Are you doing anything else in the loop that is receiving data?  Are you running this on a Windows PC?   A 64,000 byte buffer would only give you a little over .2 seconds to read the data.  There is certainly no way that small numbers like 64 or 1600 would work.  You'd have to set the buffer to an even larger number than 64,000 bytes if the hardware will let you.

Have you tried setting up any hardware handshaking?

[LVCoder]

How are you able to set a Serial port to have a baud rate of 3 million bits per second?  I wouldn't even think that is a valid serial port setting.  That is about 300kB every second.  What are you communicating with?

i am communicating it with Virtual Com Port device(VCP). i am using FTDI's FT232R IC. 

What do you do with this data once you recieve it?  Are you doing anything else in the loop that is receiving data?  Are you running this on a Windows PC?  

i am putting that data in a queue and dequeing it data in another loop and processing it. yes, i am on win xp sp2.

A 64,000 byte buffer would only give you a little over .2 seconds to read the data.  There is certainly no way that small numbers like 64 or 1600 would work.  You'd have to set the buffer to an even larger number than 64,000 bytes if the hardware will let you.

 i have set it 6400000 and getting the same error.

[LVCoder]

And i dont know much about Handshaking.

but we are following a protocol.

First the Program sends some data to the H/W. Following that the H/W starts sending data to the Port. 

[LVCoder]

Any Help Please!!

[LVCoder]

Could anyone please tell me what is the origin of this error?

Right now i am in a big dilemma whether the error is due to H/W buffer overflow or at the receiving port from where my program is reading data.

One thing more, i can set bookmarks in my hardware program. so when i set bookmarks in my H/W program and was sending 1 bunch of data at once(1600 bytes), it worked fine. But when i removed the bookmarks and H/W started sending data with full speed, it started giving me the same error.

This thing is just driving me crazy for hours now.

Pls. Help me out before i start losing my hair from my head !!

Thanks,

Ritesh 

[Steven_T]

Ritesh, 

When VISA gives you an over-run error it means that the driver associated with the port was not able to get all of the data out of the hardware before data coming through the port over wrote it.

Most UARTs have an internal FIFO.  Some of the larger FIFOs would be about 128 Bytes.  If you are communicating at 3MBaud, it would take you only 426us to completely fill up the bus and cause this error.  The driver associated with the port is in charge of communicating with the hardware and giving the data to VISA.  So it is actually the hardware driver that is causing the error, not VISA.

There are a few ways to prevent over-run errors and most of them involve using hardware handshaking so that data will stop transmitting before an over-run happens.

I hope this helps,

Steven T.

[LVCoder]

Hi Steven,

Thanks alot for your reply.

Most UARTs have an internal FIFO.  Some of the larger FIFOs would be about 128 Bytes.  If you are communicating at 3MBaud, it would take you only 426us to completely fill up the bus and cause this error. 

This error only arises when i send data in a continuous mode. However, if i send 1600 bytes and then stop the device, the program runs with no problem. If at 3MBaud, it fills the buffer in 426 µs, it should give error even when the data is sent only once. I hope what i am talking is sense. Just correct me if i am wrong.

As i mentioned before also that i am using FT232R IC. and FTDI has built a DLL to communicate with their chips through LabVIEW. I tried using their basic functions and they all ran absolutely fine except that the string returned by the Read function had some issues. Other wise there were no memory over run issues with their DLL functions.

Thanks,

Ritesh 

[Steven_T]

Ritesh,

The over-run is still caused by the driver of the hardware.  What you are observing is that the driver is able to keep up with bursts of data coming into the port.  So for the first few thousand bytes coming in, there is no error.  However, after a while, the driver falls behind and cannot keep up (hence the over-run error).

How does FTDI recommend that you use their ports in LV?  VISA may interact with the driver in a different way or set properties to different values.  All of this can have an impact on how the driver performs.  Also, this DLL that they provided may not return overrun errors the same way that VISA does.  The malformed string may just be missing data that was missed because of an over-run error.

You have not mentioned anything about the types of flow control that are available to you.  The only real way to prevent over-run errors in data intensive communication is to have ways to hold-off the data (flow control).  Since the data will be interrupted for a fraction of a second, the driver will have a chance to get the data out of the hardware in time.  Communication will automatically resume once the data is read out of the hardware.

Thanks,

Steven T.