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: | Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov> |
To: | "Pearson, Matthew" <pearsonmr at ornl.gov>, Torsten Bögershausen <Torsten.Bogershausen at ess.eu>, "Peterson, Kevin M." <kmpeters at anl.gov>, "tech-talk at aps.anl.gov" <Tech-talk at aps.anl.gov> |
Date: | Tue, 9 Jan 2024 18:05:03 +0000 |
Hi,
Glad it worked. I suspect the problem you see is inherent in the design of the soft motor and the support records which typically use asynchronous CP links to monitor the state of the underlying real motor record. The real motor record will post the RBV update before DMOV, but because of the CP links the soft motor doesn’t know if the current RBV is really the position at the end of the move when the DINP link indicates the end of move. When the DINP indicates ‘done’, it processes the motor record and syncs VAL to RBV even if the current RBV was the value from the previous driver poll. Then, immediately afterwards, RBV is updated to the correct final position.
Although, I don’t think I’ve seen the issue myself (even in the past when we didn’t make use of LOCK=1).
A database could be designed so that it’s less likely to happen. For example, the record pointed to by DINP could be set as part of a sequence, and only set back to 1 after the underlying real motor record has finished processing.
Cheers,
Matt
From: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Sent: Tuesday, January 9, 2024 6:11 AM
To: Pearson, Matthew <pearsonmr at ornl.gov>; Torsten Bögershausen <Torsten.Bogershausen at ess.eu>; Peterson, Kevin M. <kmpeters at anl.gov>; tech-talk at aps.anl.gov
Subject: [EXTERNAL] RE: Behavior of the soft motor's DINP field
Hello Matt
Thanks! Setting the LOCK field solved it, now whenever I move the soft motors they move to the target position and stop exactly at it.
Best Regards,
Abdalla.
From: Pearson, Matthew <pearsonmr at ornl.gov>
Sent: Monday, January 8, 2024 6:25 PM
To: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>; Torsten Bögershausen <Torsten.Bogershausen at ess.eu>; Peterson, Kevin M. <kmpeters at anl.gov>;
tech-talk at aps.anl.gov
Subject: RE: Behavior of the soft motor's DINP field
Hi Abdalla,
Can you try setting the LOCK field to 1 in the soft motor, and see if that resolves the issue?
I’m not sure why the soft motor VAL sync issue is happening, but LOCK will prevent VAL being synced with RBV at the end of a move, which is sometimes necessary. We have set LOCK=1 on our slit control applications, as part of the mechanism of preventing gap/center drift.
Cheers,
Matt
From: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo>
Sent: Sunday, January 7, 2024 7:07 AM
To: Pearson, Matthew <pearsonmr at ornl.gov>; Torsten Bögershausen <Torsten.Bogershausen at ess.eu>; Peterson, Kevin M. <kmpeters at anl.gov>;
tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: Behavior of the soft motor's DINP field
Hello Mathew
Thanks for the feedback. Again, sorry for the misunderstanding but the real issue is 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. Here I attached two screenshots, one with DINP set and the other without DINP. Somehow the soft motor does not SYNC the VAL with the RBV, I tried controlling the SYNC field through the database using various technique but nothing works. Up to now, removing the DINP field seems working fine but I don't know if this would cause an issue.
Please note that I am using the exact implementation as in the sum2Diff.db in the motor record except for simpler equations of course, I am thinking there might be something to investigate in the motor record and soft motor sources, so If anyone can elaborate on this topic it is really appreciated.
P.S.: One of the slits here is moving in the negative so the equations become
Gap = A - B
Center = (A + B) / 2
Best Regards,
Abdalla.
From: Pearson, Matthew <pearsonmr at ornl.gov>
Sent: Friday, January 5, 2024 5:52 PM
To: Torsten Bögershausen <Torsten.Bogershausen at ess.eu>; 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
Hi,
Back to your problem:
There may be a timing problem of some kind,
between the poller towards the Galil and the soft “motor poller”.
It’s event driven, a CA monitor on the links defined by DINP, RDBL and RINP.
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.
I think the soft motor position will still update even though DINP=1. For example, if the encoder on an underlying real motor changes by itself (without a commanded move happening, with DMOV staying at 1) the soft motor position will still change.
· 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.
8ms update rate is fast. That’s polling the Galil controller at 125Hz. It may work, and I’ve tested close to 100Hz myself, but is it necessary for the application?
It also means both real motor records are being processed by the Galil driver at 125Hz, which means the transform and the soft motor record is being updated 2x that rate (250Hz).
Are you using UDP via the Galil driver? Perhaps the controller isn’t responding to every network request made by the Galil driver poller. Although, I’m not sure if that’s an issue here.
Cheers,
Matt
Hello