Experimental Physics and
Industrial Control System

Aloha Abdalla,

a bit of a long shot, but, the differences between the commanded and
RBVs might be bit resolution. If there is any a/d or d/a conversion
involved that could happen (this reply is prompted by your inclusion
of the image, and the differences being 0.064 and 0.032)

Maren Purves
Head of Instrument and Telescope Software
East Asian Observatory / JCMT

On Sun, Jan 7, 2024 at 1:43 AM Abdalla Ahmad via Tech-talk
<tech-talk at aps.anl.gov> wrote:
>
> Hello Kevin
>
> Thanks for your feedback. I have forgotten an important info to mention, it is the fact that the soft motor reaches the corresponding position (set in the RBV), but the difference that I mentioned in my first email is that the VAL is a bit different than the RBV, see the attached screenshot. Notice the gap motor is at 8 mm but the VAL is 8.064 mm. This behavior only happens when the DINP field is set to the "Done" PV. When it is removed, the behavior is resolved.
>
> Best Regards,
> Abdalla.
> ________________________________
> From: Kevin Peterson <kmpeters at anl.gov>
> Sent: Thursday, January 4, 2024 6:24 PM
> To: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> Subject: Re: Behavior of the soft motor's DINP field
>
> The soft-channel device support for the motor record was designed for
> simple 1-to-1 applications like the tangent arm example at the end of
> the motor record documentation.
>
> Complex, soft-motor applications almost always have problems with the
> done-moving behavior.  The motor record sets the DMOV field to 0 at the
> start of the move and then gets the value of DMOV from the DINP link,
> which must remain 0 from the time the move was initiated until all of
> the dependent motors are done moving.
>
> In this case, it may be better to use the 2slit_soft support from the
> optics module:
>
>
> https://github.com/epics-modules/optics/blob/master/opticsApp/Db/2slit_soft.vdb
>
> A lot of effort has gone into making those soft motors work correctly
> over the years.
>
> Kevin
>
> On 1/4/24 05:59, Abdalla Ahmad via Tech-talk wrote:
> > 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
> > <https://github.com/epics-modules/motor/blob/master/motorApp/Db/sumDiff2D.db>. 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)
> > P.O. Box 7, Allan 19252, Jordan
> > Tel: +96253511348 , ext. 265
> >
> > Fax: +96253511423
> >
> > abdalla.ahmad at sesame.org.jo <mailto:abdalla.ahmad at sesame.org.jo>
> >
> > www.sesame.org.jo <http://www.sesame.org.jo>
> >