EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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 1994  1995  <19961997  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: Stepper motors
From: Ric Claus <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Wed, 28 Feb 1996 15:14:05 -0800 (PST)
I am in the process of writing device support for the Allen Bradley 1746-HSTP1
stepper motor controller module.  I was running into a problem under 3.12.1 in 
which the database specified initialization algorithm (Move to the 
Negative/Positive Limit) was being aborted by the record support smcb_callback 
routine with a SM_MOTION command.  In looking at 3.12.2 I see that this 
problem has been fixed.  However, the initialization algorithms have changed 
as well and now no longer reliably provide enough motion for an HSTP1 to get 
a motor to one of its limits.  The HSTP1 can keep track of up to +/-8,388,607 
steps whereas 3.12.2 requests only +/- 1,048,575 steps.  Under 3.12.1 the 
algorithms used to request +/- 268,435,455 steps.  

How can we fix this?  I would prefer the implementation of a new command:
SM_FIND_HOME with an argument giving the direction to move in.  That way, any
stepper motor support function can determine for itself what "Find Home" means,
whether it is a motion of a controller dependent number of steps or a special 
function such as the "Find Home +/-" function of the HSTP1.

Failing that, I would suggest leaving the SM_MOVE commands, but with argument
+/-0x7fffffff.  That way it is easily detectable by the stepper motor support
routines what is wanted.  If the number is too big for some stepper motor
controllers to handle, the stepper motor support routine can replace it with
whatever it can handle.  Meanwhile, I can still detect it and replace it with
the proper "Find Home +/-" command.

I really don't like this last method since it is overloading the meaning of
the arbitrary number with a specialized function that does not necessarily 
cause a standard motion manoever.  It is also the wrong number for 64 bit 
systems.

I don't mind making the modifications necessary to recSteppermotor.c, drvOms.c
and drvCompusm.c, if the usual maintainers of these files are swamped.  
However, since I don't have the relevant hardware, I can't test the OMS or 
Compumotor cases.

	Cheers,
		Ric


Navigate by Date:
Prev: Re: DEC Alpha OSF-1 generated database Marty Kraimer
Next: Re: sequencer Andy Kozubal
Index: 1994  1995  <19961997  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: Re: Anyone using Tornado yet? Jeff Hill
Next: Events lost, discard count was XXX Gabor Csuka
Index: 1994  1995  <19961997  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 ·