Experimental Physics and
Industrial Control System

"Redman, Russell O." <[email protected]> · Fri, 4 Jul 2003 16:14:15 -0700

BAAAHHH!!!

Ignore my previous message!  My previous tests of the speed of the replies
from the motor controller were misleading.  Replacing it with a loopback
connector allows the serial "communications" to run as fast as I can drive
them with no unexpected delays.  The delay must be introduced by the motor
controller, not by the code running in the IOC.

Dr. Russell O. Redman
Tel: (250) 363-6917 | Fax: (250) 363-0045
<mailto:[email protected]>
National Research Council Canada | Conseil national de recherches Canada
5071 West Saanich Road           | 5071 West Saanich Road
Victoria, B. C. V9E 2E7          | Victoria, C.-B. V9E 2E7
Government of Canada             | Gouvernement du Canada

> -----Original Message-----
> From: Redman, Russell O. [mailto:[email protected]]
> Sent: Friday, 2003 July 04 3:38 PM
> To: Tech-Talk (E-mail)
> Cc: 'Honey, Allan'; Dunn, Jennifer; Wooff, Robert
> Subject: overheads in serial communications with drvAscii, sioSup &
> tnetDe v
> 
> 
> This is probably one for Allan Honey to consider, but may be of wider
> interest.
> 
> I am experiencing very large overheads using serial 
> communications to talk
> to a motor controller.  I am using drvAscii v2.2 with sioSup 
> and tnetDev to
> communicate over a serial line to a motor controller.  The 
> hardware layout
> is :
> 
>    ioc --(Ethernet)-- terminal server --(19200)-- controller
> 
> where I am using sioSup and tnetDev to connect to a specified 
> port on a
> terminal server, which is configured to talk at 19200 baud to the
> controller.  The IOC an MVME2402-3, a PowerPC running VxWorks 
> 5.4 and EPICS
> R3.13.5.  
> 
> I am passing short messages both ways across this link, 10 
> characters max
> each way.  At 19200 baud, the line should pass about 2000 
> characters each
> second, so the whole prompt/response sequence should be 
> complete in about 10
> ms.  In fact, it takes around 300 to 400 ms to complete.  
> Till now, I have
> operated on the assumption that the PPC was so fast that the 
> latency in
> serial communications would be dominated by the baud rate, 
> but apparently
> not.  After considerable testing, I am convinced that the 
> controller is
> replying quite rapidly to each message and is not a 
> significant source of
> delay.  I am convinced at the 95% level that the delay is introduced
> somewhere in the serial driver/Ethernet connection.
> 
> For example, if I set a single record to scan every 0.1 
> seconds, it is able
> to process once every 4 tries:
> 
>   -> dbpf "conb:lo:gal:wrtst.TPRO","1"
>   DBR_UCHAR:          1         0x1
>   value = 0 = 0x0
>   -> dbpf "conb:lo:gal:wrtst.SCAN",".1 second"
>   DBR_STRING:          .1 second
>   value = 0 = 0x0
>   -> process:   conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   process:   conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   process:   conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   active:    conb:lo:gal:wrtst
>   process:   conb:lo:gal:wrtst
>   (etc...)
> 
> An interesting variation is to forward link two records 
>   conb:lo:gunn:x:rx.FLNK = conb:lo:gunn:x:px 
> 
>   -> dbpf "conb:lo:gunn:x:px.TPRO","1"
>   DBR_UCHAR:          1         0x1
>   value = 0 = 0x0
>   -> dbpf "conb:lo:gunn:x:rx.TPRO","1"
>   DBR_UCHAR:          1         0x1
>   value = 0 = 0x0
>   -> dbpf "conb:lo:gunn:x:rx.SCAN","Passive"
>   DBR_STRING:          Passive
>   value = 0 = 0x0
>   -> dbpf "conb:lo:gunn:x:rx.SCAN",".1 second"
>   DBR_STRING:          .1 second
>   value = 0 = 0x0
>   -> process:   conb:lo:gunn:x:rx
>   active:    conb:lo:gunn:x:rx
>   active:    conb:lo:gunn:x:rx
>   process:   conb:lo:gunn:x:px
>   process:   conb:lo:gunn:x:rx  - repeat block
>   active:    conb:lo:gunn:x:rx    |
>   active:    conb:lo:gunn:x:rx    |
>   active:    conb:lo:gunn:x:rx    |
>   active:    conb:lo:gunn:x:rx    |
>   active:    conb:lo:gunn:x:rx    |
>   process:   conb:lo:gunn:x:px  - end block
>   process:   conb:lo:gunn:x:rx
>   (etc...)
> 
> In this case, rx is able to queue a message at the start of 
> the block but
> must wait for both the previous px message and its own 
> message to complete
> before it finishes processing and triggers px again.  The 
> pair of messages
> take about 700 ms to complete.
> 
> Needless to say, this overhead is unacceptably large.
> 
> I have no idea where to begin looking for such large overheads in the
> drvAscii/sioSup/tnetDev combination, nor even whether this is the real
> source of the problem.  Any ideas what might be wrong?
> 
> Dr. Russell O. Redman
> Tel: (250) 363-6917 | Fax: (250) 363-0045
> <mailto:[email protected]>
> National Research Council Canada | Conseil national de 
> recherches Canada
> 5071 West Saanich Road           | 5071 West Saanich Road
> Victoria, B. C. V9E 2E7          | Victoria, C.-B. V9E 2E7
> Government of Canada             | Gouvernement du Canada
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System