Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Problems with motorRecord
From: sullivan@oxygen.aps1.anl.gov (Joseph P. Sullivan)
Date: Fri, 24 Jun 94 14:11:09 CDT
Mark writes...

re: send_mess()

>     This code sits in a tight loop testing whether the board is ready to 
>     receive another character, writes the characters to the board, and repeats
>     until the string is done. This is how the old driver support for the
>     steppermotorRecord also works, and Bob Delesio told me he tested it and the
>     OMS board can accept the characters essentially as fast as they can be
>     sent, so this code may be OK. It is worth verifying this.

I have measured this loop and the inter-character delay ranges from 
2.5us(between the 1st and 2nd char.) to 45us with the average being ~40us.
This is a close call, a fast interrupt handler could be used here. 
 
re: recv_mess()

> So this code also sits in a tight loop, waiting for the next character from
> the board to become available and then reading it.  This is NOT the way the
> stepperMotor record driver support worked. It was interrupt driven.

The inter-character delay for this loop ranges from 60us to 553us with the 
average being ~170us. Using interrupts in this case makes sense. 

re: OMS response latency

>     .... I would not be very surprised if it took 10 
>     milliseconds for the OMS board to do this. If so, polling 5 motors at 10
>     Hz would use 50% of the 68040 VME CPU.

I measured the VME8 response latency for commands that execute immediately, 
like "request position", to be about 1ms. This is still too long a time 
to poll.  

> 
>     Clearly a better way to do this is to write an interrupt driven routine to
>     read each character and to send a response message to a vxWorks message 
>     queues) when the complete response from the OMS board has been received.
>     set_status() would then just read the message queue with timeout. Note that
>     this method will not tie up the 68040. 

I agree. Time would be freed up for other records to process.

> 
> Further performance gains can be realized by polling less frequently (5 Hz?),
> but using the end-of-move interrupt to cause a poll to occur whenever a move
> completes. This will dramatically reduce the latency for determining when a
> move is complete.
> 
>

I agree and plan on rewriting the motor record to use the command-complete
(DON_S) and and character-available(IBF_S) interrupts in conjunction with 
the integration of the OMS VME58 board. I will be receiving a beta version 
of the VME58 early in July. 

	Joe

-----------------------------------------------------------------------------
Joseph Sullivan                        Phone:    (708) 252-8657
Experimental Facilities Division       Internet: sullivan@oxygen.aps1.anl.gov
Argonne National Laboratory            Fax:      (708) 252-3222
9700 S. Cass Ave. Bldg. 362
Argonne, IL  60439-4844




Navigate by Date:
Prev: Problems with motorRecord Mark Rivers
Next: Changes to Stepper Motor Record Andrew Johnson
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Problems with motorRecord Mark Rivers
Next: Changes to Stepper Motor Record Andrew Johnson
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·