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: Motor record -- URIP with soft limits |
From: | "Ernest L. Williams Jr." <[email protected]> |
To: | "J. Lewis Muir" <[email protected]> |
Cc: | EPICS Techtalk <[email protected]> |
Date: | Tue, 25 Sep 2012 13:31:51 -0700 |
On 09/25/2012 01:01 PM, J. Lewis Muir wrote:
On 9/25/12 1:45 PM, Fong, Nia W. wrote:Hi, We just setup our motors to use a readback link URIP, getting motor position from an external LVDT device and are running into a problem when the motor is moved to one of its soft limits. We notice that when a motor is moved to its soft limit, it is possible for the motor to end up at a position slightly outside of its soft limit (how far out depends on how high we set the retry deadband RDBD). As a result, the motor can no longer be moved until the soft limit it is violating is manually widened outside of the RBV value. According to the motor record documentation, HLM uses the VAL, but it looks like it is instead using the RBV field. Both fields would seem valid depending on the application. Has anyone else run into this problem using URIP and the HLM and DLM? How was it resolved?Hi, Nia. I've run into the same problem, but not using URIP.
Are you using "Use Encoder" ? Seems to me that any of the "USE xxx" modes exhibit this problem.
My scenario is like yours: I can't move the motor because it is beyond one of the soft limits. My workaround is to temporarily extend or disable the soft limits, move the motor back to a position within the original soft limits, and then restore the soft limits.
This is a manual operation that we don't operators to have to deal with. Of course, some sequencer could be written for automation.
Well, here it seems that some code changes can be made in the motorRecord business logic to handle this case?If there's a better way, I'm interested in hearing it.
We are also interested in a better solution for this problem.
Lewis