1994 1995 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 | 1994 1995 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: | Re: Proper initialisation of Motor Record .RMP value |
From: | Peter Linardakis <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
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: [email protected] [[email protected]] on behalf of Peter Linardakis [[email protected]] Sent: Monday, October 21, 2013 9:55 PM To: [email protected] 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: [email protected]<mailto:[email protected]> p: (02) 6125 2862 f: (02) 6215 0748 |