Experimental Physics and
Industrial Control System

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

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