Experimental Physics and
Industrial Control System

"Davis, Mark via Tech-talk" <[email protected]> · Fri, 31 May 2019 20:01:45 +0000

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]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System