EPICS Controls 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  2021  2022  2023  2024  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  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Problems with motorRecord
From: Mark Rivers <[email protected]>
Date: Fri, 24 Jun 1994 11:14:00 -0400 (EDT)
Folks,

I have studied the OMS driver support code which is used by Tim Mooney's
motorRecord and I can see the problems with it, i.e. why it ties up the CPU
with polling.

Here is how is presently works:

- If there are any motors moving then motor_task() will call query_axis() at the
  polling interval.

- query_axis() calls set_status() which reads the position of the motor

- set_status() reads the position with the following code (for motors without
  encoders)
		send_mess(card,AXIS_INFO,oms_trans_axis[signal]);
		recv_mess(card,q_buf,2);

  This sends a message to the card requesting the position and then reads the
  response string back from the card.

- This is the critical code in send_mess()
	for(p=com;*p!='\0';p++)
	{
		trys=0;
		while( !(pmotor->status&STAT_TRANS_BUF_EMPTY) )
		{
			if(trys>MAX_COUNT)
			{
				Debug(1,"Time_out occured in send\n",0);
				trys=0;
			}
			if(pmotor->status&STAT_ERROR)
			{
				Debug(1,"error occured in send\n",0);
			}
			trys++;
		}
		pmotor->data=*p;
	}

    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.

- This is the critical code in recv_mess
		for(piece=0,trys=0;piece<3&&trys<MAX_COUNT;trys++)
		{
			if(pmotor->status&STAT_INPUT_BUF_FULL)
			{
				c=pmotor->data;
				Debug(7,"%02x",c);

				switch(piece)
				{
				case 0: /* header */
					if(c=='\n'||c=='\r') head_size++;
					else
					{
						piece++;
						com[i++]=c;
					}
					break;
				case 1: /* body */
					if(c=='\n'||c=='\r')
					{
						piece++;
						tail_size++;
					}
					else com[i++]=c;
					break;
	
				case 2: /* trailer */
					tail_size++;
					if(tail_size>=head_size) piece++;
					break;

				}

				trys=0;
			}
		}

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 problem is now clear:
    set_status() calls send_mess() and then recv_mess(). The CPU will be busy
    during the entire time from the start of sending a message until the
    complete reply is received. This includes the time for the OMS board to
    receive and decode the incoming message, and construct and transmit the
    response string. 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.

    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. Will it block further record
    processing?


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.

____________________________________________________________
Mark Rivers                             (312) 702-2279 (office)
CARS                                    (312) 702-9951 (secretary)
Univ. of Chicago                        (312) 702-5454 (FAX)
5640 S. Ellis Ave.                      (708) 922-0499 (home)
Chicago, IL 60637                       [email protected] (Internet) 



Navigate by Date:
Prev: [none given] Jeff Hill
Next: Re: Problems with motorRecord Joseph P. Sullivan
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  2021  2022  2023  2024 
Navigate by Thread:
Prev: sending strings to sub records cleaves%mickey.UUCP%denali.UUCP
Next: Re: Problems with motorRecord Joseph P. Sullivan
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  2021  2022  2023  2024 
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 ·