LabVIEW Serial Read takes too long to send

[Daniel Coelho]

Hi.

I'm using LabVIEW and VISA to do a simple write and read operation for a LIN transceiver.

Every time I receive a byte from the master LIN node I have to reply with another byte as the slave LIN node.

The problem is that between the read and write of the bytes there's more than 2 ms of delay (i've seen this with an oscilloscope DPO 2014).

My VISA settings are 19 000 Bd, 8 data bits, 1 stop bit, no parity.

I have a Timed Loop and inside the timed loop I read and write emediatly.

I have no waits nor any other king of delays inside the loop.

Why is it taking so long to reply?

Is there a way to write to the serial port faster?

Is it possible to reduce these 2 ms to 1 ms or almost 0 ms?

I've made this with a microcontroler and the response/write is done emediatly after reading the expected byte.

I apreciate all help.

Regards.

Daniel Coelho

http://www.vistoolkit.com - Your Real Virtual Instrument Solution

[smercurio_fc]

Increasing the serial baud rate will do nothing to decrease the delay between the end of the read and the beginning of the write. The baud rate only changes the speed at which the transmission occurs. What you are seeing is the delay incurred in going through all the layers between the hardware (i.e., the UART on the motherboard of your computer), and the application (LabVIEW). You have to go all the way up to the application (to accomplish the read), then all the way back down (to execute the write). 2 msec is not that unusual. If you absolutely must have better performance then perhaps you should consider using a Real-Time platform.

[JÞB]

How are you configured for Sync / Async? 

Good KB that can improve VISA turnaround and explains in detail what Smercurio-FC alluded to

Message Edited by Jeff Bohrer on 03-04-2010 01:48 PM

[Daniel Coelho]

My VISA VIs are configured as Sync.

Changing to Async doesn't change a thing.

I'm not looking for a real time solution because I can do this with a PIC microcontroller with a simple code.

I just want to understand if it is really impossible to obtain the same result.

I understand that going up and down the layers takes time, but 2 ms seemed to much for me.

Since I'm "simulating" a LIN card with a LIN transceiver, reading one byte at a time and respond with 5 bytes if a specific byte is received seems a very quick and simple thing to do with LabVIEW.

When I use a NI USB LIN card with LabVIEW, the LIN messages are read and sent quickly, the only (big) difference is that the card is an usb card instead of serial port.

[Mark_Yedinak]

Can you post an example of your code? I haven't timed my serial VISA communications but I haven't notice the type of delays you are seeing.

[Daniel Coelho]

I took the Basic Serial Write and Read.vi example and changed it.

Please see the atached file.

[Daniel Coelho]

Hi Mark.

Did you have the chance to see my VI?

Do you notice the same delays I do?

I apreciate your help.

Thanks in avance.

[Bill_in_Detroit]

Daniel:  I took a look at your code and don't see any problem with it.  However, doing the math:

19,200 BAUD = 19,200 BITS per second.

10 BITS per BYTE ( 1 BIT start + 8 BITS data + 1 BIT stop = 10)

19,200 BAUD = 19,200/10 BITS per BYTE = 1,920 BYTES per second

1,920 BYTES per second / 1000 milliseconds per second = 1.92 BYTES per millisecond (ms)

Now the above would not be a problem since you are only waiting for one character (which should only take 0.52 ms), however, you are sending 5 bytes.  That's a total of 6 bytes round trip or 6 * 0.52 ms = 3.12 ms.

In addition, having "Enable Terminating Char" on your VISA Configure Serial Port can't be helping unless your serial LIN device requires it because having to wait for a teminating character on a read or write (in your case it appears you are using a 0x0A or line feed) increases the number of characters that need to be transmitted. 

Another thought just came to me:  If your serial device is sending a terminating character, it is possible you may have a second read operation each cycle due to the 0x0A (line feed) and the fact that your code only reads one byte at a time from the serial port.  This may also add some time to your response.

I hope this helps.

Message Edited by Bill_in_Detroit on 03-18-2010 09:16 AM

[Mark_Yedinak]

When you timed this with the oscilloscope what specifically were your measuring? Were you looking at both the receive and transmit lines? Were you only seeing the 2ms delay on the receive line? How fast does your instrument respond? Is it possible that you are seeing the delay because the other end of the communications is slower than you think? Also, as pointed out it does take some time to actually send the bits across the line.

[Daniel Coelho]

I'm sorry for the delay answering.

Meanwhile, the hardware isn't available and I can't make tests just yet.

But, I understand your baud rate maths and, don't take me wrong, the problem can't be in the baud rate because a colleage of mine was able to do it with a PIC microcontroler with a simple code (read one byte, if byte found, reply) and I don't see any delays in the LIN bus.

As soon as I get the hardware back to me, I'll measure the time difference between RX and TX in the serial bus.

By the way, I noticed something, I can't read as fast as the bytes arrive. Every cycle I read the "bytes at port" number and read one byte per cycle, it increases until it reaches the maximum 4096.  This may be an issue too.