Delay over RS232 line of 9600 baud rate is 20ms.

[KizKas]

I'm sending 1 byte over one RS-232 line as follows:

1. On TX side VI:

       1. Time Stamp using Get Date/Time In Seconds

       2. VISA WRITE with the following configuration: Enable Termination Char=False, TimeOut=10s, BaudRate=9600, DataBits=8, Parity=None, StopBits=1.0, FlowControl=None

2. On the RX side VI (this VI is started first):

       1. VISA READ with the following configuration: Enable Termination Char=False, TimeOut=10s, BaudRate=9600, DataBits=8, Parity=None, StopBits=1.0, FlowControl=None

       2. Time Stamp using Get Date/Time In Seconds

Why is the delay between the two time stamps gives 20 ms of delay?

Is there an implicit delay in the Serial driver?

Why is this 20 ms delay unchanged when I send 15 bytes instead of 1 byte?

Thank you for your help.

KizKas.

[Zinnium]

20ms,  That sounds about right.  It has a mixture of reasons, but simply its almost all hardware.  It gets better or worse depending on the actual equipment, and also what year it is from. 

If you are needing to do higher speed reads and writes; you'll have to upgrade to a USB or Ethernet connection.  DB-9/RS232 is only good for situations where you don't need to be so fast and want to save a dime or two.  You'll always have some lag time from hardware, but the newer communications systems minimalize this.

Message Edited by Zinnium on 01-29-2009 11:41 AM

[KizKas]

Hi Zinnium;

Thank you for the reply.

I was expecting a delay of 0.0011 sec for 1 byte to travel over the cable because:
9600 bits per sec -> 872 CHAR (=11 bits) per sec.
Hence it takes approximately 0.0011 sec to pass one byte from TX to RX side.

Also:
Why is this delay, what is its nature?
Can I expect this 20 ms to be constant for the same equipment?
do you know Threads in this Discusssions Forums dealing with the same isssue?
do you know NI support Notes dealing with the same isssue?

Again thank you very much.

KizKas.

[Pnt]

---

KizKas wrote:

Is there an implicit delay in the Serial driver?

---

No.

The termination char is disabled, so probably your hardware has a timeout. Then it sends the response.

When you send 15 bytes, you need 15 ms to send them, plus the timeout.... = time is longer to get a response.

[Coq_Rouge]

Under Windows you cannot do any reliable software timing below 10 ms. In Labview it  is around 15 to 20 ms. The actual numbers vary depending on the actual version of Windows and Labview. Your problem is that you are very close to the timing resolution in Labview and Windows. This is the source for your somewhat strange timing results.  

[KizKas]

These measurements are done using LabView Real-Time (Target HW is PXI 8104). There is no Windows involvement here.
This is a loopback test form COM4 PXI 8430 RS232->COM4 PXI 8430 RS232.

Please refer to the attachements.

KizKas.

[KizKas]

Should have been written: COM4 PXI 8430 RS232->COM5 PXI 8430 RS232.

KizKas.

[Zinnium]

Why is this delay, what is its nature?

Yap, and happens on about everything else too.  like to use these Siemens S-220s for a lot of stuff (They are Cheap, and reliable) and I can get delays of around 80ms or so for 5bits and having the PLC do a 1+1 calculation. 

Can I expect this 20 ms to be constant for the same equipment?

 Yes, may have a slight variation but nothing more than a 1/2%.   Also if you have 2 pieces of equipment that are the same make and model, and could have even been manufactured along side each other: There most likely is a small difference between the two of them.  This is normal, and that's why there are tolerances.

do you know Threads in this Discussions Forums dealing with the same issue? 

Look up ModBUS, RS232, DB9 and  use the other keyword "delay". you'll find a bunch of threads on this.   It seems to drive people nuts.

do you know NI support Notes dealing with the same issue?

Yeah, they know but its not a bug or anything.   If you look up the past post. you'll see the NI people chatting about it in there.

[KizKas]

Hi Zinnium;

Thank you for the reply.

1.

I'm unable to find postings or NI support notes dealing with "RS232 propagation delay" except this one:

     http://forums.ni.com/ni/board/message?board.id=170&message.id=54343&query.id=97644#M54343

 Please can you direct me to other links which deal with the same subject.

2. I have run my above code in different Serial FIFO conditions (in MAX). I'm getting inconsistent results when No FIFO is used.

    Please refer to "Loopback_Test_from_COM4_to_COM5_Using_Different_SerialFIFOconditions.txt"

3.  The posting mentionned in item 1 talk about "14 bytes FIFO effect"; is this the reason causing the following:

               A) During my experiment, I was often getting 19.9 - 20ms delay and very few times 0.00001 ms delay ( I forget to tell you

                    about this).

                    Please note that the 19.9-20 ms delay is obtain with TX FIFO=64 and RX FIFO=64 on both (COM4 and COM5) ports

                    Note also that in my application the RS232 messages are 15 bytes long.

               B) In my current attachment (Loopback_Test_from_COM4_ ....), I'm getting 53 ms, 58 ms toghether with 20ms, 19ms,... .

4. What is the consequence of removing  FIFO use in Serial VISA?

Thank you for helping.

KizKas. 

[KizKas]

Hi Zinnium;

I have done propagation delay measurement of PC to PXI, and also PXI to PXI (hence here in loopback). I have attached the result in the below Excel sheet.

Note that in the regular application, the PC sends a DO rising edge each time it sends a RS232 msg, this allows the receiving PXI to measure the delay between the Tx and Rx events of the

RS232 packet. Note that receiving the RS232 packet means that we have received all its data up to the last byte.

Please can you help me in undertanding the following:

 1. Why when no FIFO is used, I'm getting different time for PC-PXI and PXI-PXI?

      Why is 16.4 ms below the 17.18 (time due to transmitt 15 bytes at "9600bps, 8 databits, No parity, no control flow, stop bits=1").

 2. What is the meaning of the 20 ms that I'm getting.

 3. Any comment?

Thank you;

Kizito.