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: Behavior of the soft motor's DINP field |
From: | Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov> |
To: | Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>, "tech-talk at aps.anl.gov" <Tech-talk at aps.anl.gov> |
Date: | Thu, 4 Jan 2024 15:26:08 +0000 |
Hej Abdalla, thanks for sharing your experience. I have been digging into the soft motor business recently, still working on a patch to allow the forward of motor status (the .MSTA field) into other records. Back to your problem: between the poller towards the Galil and the soft “motor poller”. (This is my limited understanding). However, in order to understand your situation better, could you run a camonitor/pvmonitor on the following fields: .VAL .RBV .DMOV for all 4 motors: The 2 physical motors and the 2 logical ones ? From:
Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Abdalla Ahmad via Tech-talk <Tech-talk at aps.anl.gov> 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:
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 |