Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Serial TIME OUT

When receiving a number of characters with "serial read.vi", VISA waits until timeout. We have already checked (with Terminal) that the connected device sends its string. After error occured and I start the same program again, reception works correctly. I already tried some modifications given in these forums (serial read.vi: TermCharEn:False; ASRL End In:None) - no change.
Please help, because we want to create an exe-file, but there restart doesn't help, but has always same problem!
Stefan,
0 Kudos
Message 1 of 4
(3,158 Views)
Hello,

I understand that you're doing a serial read and it's taking the full timeout period before the read returns, whereas you would like the read to return the data immediately, is that correct?

If so, all you need to know is the termination character that you are looking for (such as hex 0x0A for linefeed), and once you give this information to VISA then it will stop the serial read as soon as 1) you get the number of bytes that you asked for when you called VISA read 2) VISA read detects a termination character or 3) VISA read times out, whichever comes first.

The way you tell VISA what termination character you are looking for in LabVIEW is the "Configure Serial Port.vi". Open the LabVIEW <-> Serial.vi example, and look at the block diagram.
In the Configure serial port VI inputs, observe that the top connector is "Termination Character". Wire the decimal value of the byte that should terminate the read into this terminal. Now, try to run the program. The VISA read should stop when it sees the termination character and not wait until it times out (unless the termination character is not received within the timeout period).

If you need any further assistance or I didn't answer your question, please post here.

Scott B.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(3,158 Views)
Hello, Mr. B! 😉

I think I have understood it. But my problem is a little different:

I want the string received to be processed in parts.
The first "processor" waits for the header of the string, the next one checks only the "data container". In some cases, there is a third one which is in between and is responsible for skipping unused data.

The string for which we are waiting in this special case is really sent (we checked that), has about 20 characters, a "\s" at the start, and "\n" at the end.
Therefore we turned the "TermCharEn" to false.
I thought it would be best to handle incoming data like binary and not ascii...

Amazingly, there is no data at all in the receive buffer.

Also, if we start the same application again, it works every ti
me!

I hope you can help me

Thank you
Valk
0 Kudos
Message 3 of 4
(3,158 Views)
Hello Valk,

I'm not sure that I fully understand your problem. From what I understand, you're not using a termination character, so you must be reading a precise number of bytes into the program off of the port. The program does not see the data the first time, but if you run it again, then the data is available?

If you are sure that the data made it into the port, the serial hardware and kernel-mode driver is responsible for delivering it to higher level serial drivers and the LabVIEW software buffer. If you could provide more detailed information about your problem, that would be helpful. From what you have told me, the only thing I can come up with is that possibly the port is not opened when you receive data on the port. If this is
the case, you will not get the data into LabVIEW.

Consider the following set of events:

-You recieve data1 on the port.
-You open the port
-You receive data2 on the port.
-You do a "read" on the port

After this, your read will return only data2, not "data1 data2" as you would expect. This is because anything received on the port is discarded while the port is closed.

Perhaps this is applicable in your case. If not, please describe in more depth the set of steps that you are taking to read the data and describe the data that is expected but not received.

Thanks,
Scott B.
Applications Engineering
National Instruments
0 Kudos
Message 4 of 4
(3,158 Views)