Error -1073807339: Timeout in VISA Read when reading a lot of data.

[Rodnebb]

I have an application that reads a datalogger via a COM port.

I manage to read correctly when the amounts of data are limited, but when the message size is big I only get the first half of the message.

(Actually I expect 3600+ bytes but receive only 2000+ bytes. When I shall get ~2000+ bytes its all fine)

So, the usual suspects are timeouts I guess, so I have set the timeouts manually to very high numbers, but this only makes things go slow 😕

The code looks something like this:

§          VISA Open

§          VISA Enable Event

§          VISA Discard Events

§          VISA Serial Instr: Timeout == 100 000

§          Loop

o       VISA Write

o       VISA Wait on Event (Timeout 200 000ms)

o       VISA Read (Bytes to read: 40 000bytes)

§          VISA Disable Event

§          VISA Close

I have also tried including the VISA Discard Events into the loop to be certain I don’t have old events lying around.

Any suggestions?

[mikeporter]

Can you post the code? LV is a graphical language and there are just too many things that don't come across in text pseudo-code.

Mike...

[Wayne.C]

Do you always get the same # of bytes?  If so, take a look at the default buffer size for your version of VISA.  You may need to increase the buffer size or read the data in smaller chunks.

[falkpl]

I like to use this architecture it always works great for me.

Visa Initialize()

initialize Shift register to empty string.

Pass in start time.

do{

COM_STRING = Read (Bytes at port)

Concatinate COM_STRING with string shift register and feed results back into SR.

Parse Concatinated string.

}While(!Error && !Too much elapsed time && Parsing not complete)

Sorry dont have my LV up and running so I cand post an example.

This architecture will not timeout requires no events and runs fast and asynchronous.  Using it as an action engine will allow you to call it when ever you want in a state machine allowing for a responsive application.

Paul

[Rodnebb]

Some investigation has revealed that VISA Read always comes up w/ 4096 bytes -> the buffer is full.

The solution is probably just to read the port in smaller chunks whenever there are bytes at the port, and then stop the read process when a \n is arriving. It is however not possible to use eventhandling here (?) as eventhandling suspends the operation until an event is occurring. If the buffer goes full before the \n arrives Visa Wait On Event continues - but I assume I risk losing some bytes if I read the gate then, and continue waiting for an event (?).

Another thing: earlier we had problems when wiring "Serial Instr: No of bytes at serial port" to "byte count" (that is the number of bytes to read). I thought this would be most efficient, but it did not cause the correct no of bytes to be read. Instead I was suggested here to just wire a very high number to the "byte count" input. Does anyone know why this happens?

Message Edited by Rodnebb on 06-07-2007 03:28 AM

[Wayne.C]

I find the Number of bytes at serial port useful when I know I won't get enough data to overflow the buffer and I don't know the exact # of bytes I'll be receiving and there is not going to be a termination character.  The problem with it is that you have to figure out how long to wait to make sure you have all the data received in the buffer before you check how many bytes are in the buffer.  When you just read x bytes from buffer, VISA continues to read until x bytes have been read from buffer or the termination character has been received ( if enabled ) or a serial timeout occurs.

I think in your case you might try setting up the /n as the termination character and doing  series of reads of perhaps a 2000 bytes.  Last read should stop when termination character is received.

[Rodnebb]

Jupp, this is what I did and it seems to work.

Does anyone know if there is a difference (advantage) between using LabVIEW's Event handling and simply checking for a termination character yourself?

[falkpl]

Attached is a very crude template of what I have described previously.  Essentially you are alway keeping your HW buffers empty and are doing the processing in software.  This will allow you to handle data streams and non uniform messages, placing the work on a parser inslead of VISA events.  You will no longer have to worry about VISA Timeouts since you will dictate the tempo of the reads.  It is not needed for constant length strings response strings but can work there too.  It will require modifications since I spent less than 5 minuted developing it.

Paul