Re: Problems with motorRecord

[sullivan@oxygen.aps1.anl.gov (Joseph P. Sullivan)]

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