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: | Behavior of the soft motor's DINP field |
From: | Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 4 Jan 2024 11:59:26 +0000 |
Hi I am trying to implement a simple kinematics system for a standard slit motion, where we have the kinematics equation as: Gap = A + B Center = (A – B)/2 I used the motor record’s soft motor implementation which has an example
here. The actual motor controller is Galil DMC based on the Galil EPICS driver, the kinematics is working fine but there might be some kind of
a bug in the RBV value of the soft motors. If you were to move any motor whether actual or soft, the transform record starts calculating and updates the soft motor RBV accordingly, but the soft motor stops before reaching the actual calculated position due
to the fact that the DINP field receives 1 if both motors are done moving (DMOV = 1). For example it is supposed to reach 5 mm but it reaches to 4.97 for example. The error might not be that much but it gets accumulated in each motion. I tried to investigate
more and I found the following: ·
Removing the DINP link value “fixes” the behavior? I am not sure if it is fixed or not but the soft
motors reach their corresponding values. ·
I remembered that we are configuring our Galil controllers on a 8 ms update rate. I set the update rate
to slower values and the issue can be resolved. ·
I looked into the soft motor record’s source code and I noticed that the DINP value is mapped into 3
values: SOFTMOVE = 0, HARDMOVE = 1 and DONE = 2. I am not sure exactly what those mean, but I tried setting these values to the DINP field but it did not work, it seems there is a certain logic happening inside the record that behaves differently on each value. This issue can problematic because the error in the position can be accumulated with each motion, also I am not sure how the SSCAN module
will behave in this case. Any insight is really appreciated. Best Regards, Abdalla Al-Dalleh Control Engineer SESAME (Synchrotron-light for Experimental Science and Applications in the Middle East) Fax: +96253511423 abdalla.ahmad at sesame.org.jo |