Experimental Physics and Industrial Control System
Ronaldo,
I'm copying you in on this because it is another issue that we find with using an intelligent motor record with an intelligent controller and it might be worth discussing at the EPICS Meeting motor TWG this week.
Mark,
My first thought as to the cause is that your motors are jittering a little after a move and perhaps especially when you kill them.
The motor record will always copy the current readback into the current demand when the DMOV value goes from 0 to 1 (i.e. it perceives the motor has finished moving).
In the pmac driver, we report DMOV up to the motor record based primarily on the InPos status for the axis.
If your motors are jittering for some reason and it is enough for the controller to decide that InPos should be 0, then the motor record will briefly see the axis is moving and then copy its new position to the demand field.
One possible solution is to simply increase the controller's in position band for these axes. This would be acceptable if the amount of jitter is smaller than the smallest move you need to make.
-------------------------------------------------------------------------------------------
I have been looking at your suggestion re changes to the 'makeCsConsistent' function. I don't think we can use a tolerance because it will affect the ability to switch between using real and virtual motors. However, I am investigating a different approach that modifies PROG10 depending on which axes you have commanded. If this works then it will no longer require 'makeCsConsistent' and will allow you to kill motors between moves without affecting demands.
Regards,
giles.
________________________________
From: Davis, Mark <[email protected]>
Sent: 31 May 2019 21:01:45
To: [email protected]; Knap, Giles (DLSLtd,RAL,LSCI)
Subject: more setpoint oddities with pmac driver and CS axes
Hi Giles,
I have run into yet another odd behavior with coordinated motion using
the pmac driver with a Power Brick controller.
As you know, I already discovered that disabling the motors between move
commands causes the driver to change the current setpoints for all the
CS axes to the current reading just before triggering the next move.
But now I have found that, even if I don't disable the motors, the
setpoint values in the motor records still tend to change for a short
time after I write a new value to the motor record for one of the CS axes.
But this is different than that problem because the change is not real.
What happens is that, I write a new value to the motor record for one of
the CA axes, the motors move, and then frequently (but not always), the
setpoint values (VAL, RVAL, etc) for one or both the CS axes motor
records change by a little bit (sometimes multiple times). But the Q7x
values in the controller do not change, the motors stay put, and the
setpoints for the motor records for the actual motors don't change.
Example:
The output of camonitor after I changed the setpoint for my SLHCEN motor
record for the center axes (with the motor amplifiers enabled the whole
time, before, during, and after the changes):
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:22.513686 50000
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:25.708162 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:26.268574 49992
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:26.268644 30018
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:26.508426 49998
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:26.508506 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:26.960236 49998
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:26.960282 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:27.584892 49986
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:27.584968 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:28.257009 49992
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:28.257094 30018
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:28.896481 49992
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:28.896567 30018
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:29.641618 49986
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:29.641702 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:29.979076 49986
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:29.979135 30006
SCR_BTS35_:SLHCEN_D1541.RVAL 2019-05-31 13:11:30.554313 49998
SCR_BTS35_:SLHGAP_D1541.RVAL 2019-05-31 13:11:30.554364 30006
The values of the Q7x and Q8x values on the controller after the values
stopped changing show that the setpoint ones (Q7x) still have the values
most recently written to the SLHCEN and SLHGAP CS axes records, even
though the motor records show slightly different values:
Q71=5
Q72=3
Q81=4.99921767845749798
Q82=2.99932463437318786
I have looked over the doco for the motor record multiple times and the
only thing I found that seemed even possibly related was the LOCK value,
which I tried setting to YES for both axes but that made no difference.
So for the moment, I am assuming this is due to something in the pmac
driver.
Any ideas what could cause this? That fact that the setpoint value for
the motor record changes when the driver DOES change the setpoints after
the motors were disabled at least meant that the operators would be able
to tell when the actual in-use setpoint "creeped" a bit too far, and
they could "fix" it by simply reasserting the original setpoint. But at
the moment the value being shown is often NOT the real in-use setpoint,
so even that option is not a practical workaround (they REALLY want the
motors disabled between moves).
--------------------
Mark Davis
NSCL/FRIB
Control Systems Software Engineer
[email protected]
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- References:
- more setpoint oddities with pmac driver and CS axes Davis, Mark via Tech-talk
- Navigate by Date:
- Prev:
Re: Camonitor with client dictated update rate Matt Newville via Tech-talk
- Next:
RE: Scanning 101 tom.cobb--- via Tech-talk
- 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
- Navigate by Thread:
- Prev:
more setpoint oddities with pmac driver and CS axes Davis, Mark via Tech-talk
- Next:
Re: more setpoint oddities with pmac driver and CS axes Davis, Mark via Tech-talk
- 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