Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
<== Date ==> <== Thread ==>

Subject: Re: Proper initialisation of Motor Record .RMP value
From: Peter Linardakis <peter.linardakis@anu.edu.au>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 23 Oct 2013 10:21:03 +1100
Hi Mark

We're using a Group3 Type G board as a motor controller with, I think, a home grown asyn driver (written by someone no longer in our employ).  We'll investigate whether the .RMP values change in between boot, but we've also noticed the .RMP value spontaneously change during operation, without moving the motor.  Does this point to a driver issue?

Cheers
Peter


On 22/10/2013 2:39 PM, Mark Rivers wrote:
What motor controller and driver software are you using?

The motor record attempts to read the hardware position at reboot.  If the controller value is non-zero then it assumes the position is valid, and it will use it.  That value will take precedence even over an autosaved value.

When you reboot should your controller still have a valid readback reading, or does it become undefined?

Mark

________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Peter Linardakis [peter.linardakis@anu.edu.au]
Sent: Monday, October 21, 2013 9:55 PM
To: tech-talk@aps.anl.gov
Subject: Proper initialisation of Motor Record .RMP value


We're pretty new at controlling motors using EPICS and we've run into a few small issues.  After a crate reboot, some of a bank of 28 motors end up with a motor.RMP value that is quite close to the signed 32-bit integer limit (both at max and min ends).  If we then try move the motor more than the difference, the motor just stops.  We're not running a complicated setup, we just home the motors using limit switches.  We do not use encoders at this time.

My question is, how do we properly initialise the .RMP value to some known value, probably zero?  At this stage of the game, we're not looking to use an autosave module or similar.

Regards
Peter

Dr Peter Linardakis
Accelerator Research and Development Engineer
Nuclear Physics | Research School of Physics and Engineering
Australian National University
e: peter.linardakis@anu.edu.au<mailto:peter.linardakis@anu.edu.au>
p: (02) 6125 2862 f: (02) 6215 0748



Replies:
RE: Proper initialisation of Motor Record .RMP value Mark Rivers
References:
Proper initialisation of Motor Record .RMP value Peter Linardakis
RE: Proper initialisation of Motor Record .RMP value Mark Rivers

Navigate by Date:
Prev: caQtDM Mezger Anton Christian
Next: RE: Proper initialisation of Motor Record .RMP value Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
Navigate by Thread:
Prev: RE: Proper initialisation of Motor Record .RMP value Mark Rivers
Next: RE: Proper initialisation of Motor Record .RMP value Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·