Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 3 Aug 2018 12:30:14 +0000

Correction: I think the critical parameter the driver needs to set is motorStatusDone_=1.  motorStatusMoving_=0 should probably also be set, but I think the motor record is looking at Done_.

These parameters correspond to these bits in the MSTA field:

MSTA    R       Motor Status    ULONG   The motor status as received from the hardware.  The MSTA bits are defined as follows:

  1.  DIRECTION: last raw direction; (0:Negative, 1:Positive)
  2.  DONE: motion is complete.
  3.  PLUS_LS: plus limit switch has been hit.
  4.  HOMELS: state of the home limit switch.
  5.  Unused
  6.  POSITION: closed-loop position control is enabled.
  7.  SLIP_STALL: Slip/Stall detected (eg. fatal following error)
  8.  HOME: if at home position.
  9.  PRESENT: encoder is present.
  10. PROBLEM: driver stopped polling, or hardware problem
  11. MOVING: non-zero velocity present.
  12. GAIN_SUPPORT: motor supports closed-loop position control.
  13. COMM_ERR: Controller communication error.
  14. MINUS_LS: minus limit switch has been hit.
  15. HOMED: the motor has been homed.

The record is put into MAJOR STATE alarm if either SLIP_STALL or PROBLEM bits are detected. If HLSV is set, then the record is put into HIGH alarm if either a high soft limit or hard limit (PLUS_LS) has been reached. Similary for the low limits.

Mark

________________________________
From: Mark Rivers
Sent: Friday, August 3, 2018 7:16 AM
To: [email protected]; [email protected]; Mark Davis
Subject: Re: Re: Delta Tau motor control problem

The model 3 motor driver communicates its status information to the motor record via these status parameters:

asynMotorController.h:  int motorStatusDirection_;
asynMotorController.h:  int motorStatusDone_;
asynMotorController.h:  int motorStatusHighLimit_;
asynMotorController.h:  int motorStatusAtHome_;
asynMotorController.h:  int motorStatusSlip_;
asynMotorController.h:  int motorStatusPowerOn_;
asynMotorController.h:  int motorStatusFollowingError_;
asynMotorController.h:  int motorStatusHome_;
asynMotorController.h:  int motorStatusHasEncoder_;
asynMotorController.h:  int motorStatusProblem_;
asynMotorController.h:  int motorStatusMoving_;
asynMotorController.h:  int motorStatusGainSupport_;
asynMotorController.h:  int motorStatusCommsError_;
asynMotorController.h:  int motorStatusLowLimit_;
asynMotorController.h:  int motorStatusHomed_;

Note that there is no "in position" parameter.

It seems to me that if a move is stopped it is the driver's responsibility to detect when the motor is actually no longer moving and set the motorStatusMoving_ parameter to 0.  I suspect the driver is not doing this in its polling thread.  If it were then I don't see why the motor record would refuse to send any more demand positions.  Of course the other status parameters also need to be set correctly (LowLimi, Hight Limit, PowerOn, etc.).

Mark

________________________________
From: [email protected] <[email protected]> on behalf of [email protected] <[email protected]>
Sent: Friday, August 3, 2018 7:03 AM
To: [email protected]; Mark Davis
Subject: Re: Re: Delta Tau motor control problem

Mark,

As per Alan Greer's earlier email, the power pmac with default configuration won't ever achieve 'in position' status if you hit stop during a move.

In your scenario, it is the motor record that decides to send a stop command as part of its NTM processing. It is also the motor record that then refuses to take any more demands until the driver reports in position. If you had used the 'DirectDemand' feature of pmac driver you should not see the behaviour.

Again, it would be useful to have a dumb mode on the motor record where it trusts the underlying driver/controller to cope with these scenarios.

Regards,

  giles.

________________________________
From: [email protected] <[email protected]> on behalf of Mark Davis <[email protected]>
Sent: 03 August 2018 12:35:05
To: [email protected]
Subject: Fwd: Re: Delta Tau motor control problem

(I accidentally sent this just to Lewis yesterday...)

Hi Lewis,

Interesting question.

I just tried giving it a new setpoint and then setting STOP to 1 before
it finished moving.  But the same problem occurs:  It stops, the done
moving bit is till clear, and it won't take any new setpoints.

It does, however, provide one more clue regarding the source of the
problem:  Unlike the case of writing a new setpoint to the motor record
before it finishes moving, the value of NTM doesn't make any
difference.  If I set STOP to 1 before it has finished moving, it stops
sending new setpoints to the controller regardless of the value of NTM.

So it would seem that the problem has to do with stopping the current
movement before it finishes.  And since this is not a problem when I
give commands directly to the controller (using the same type of
connection the driver is using), the problem must lie either in the
driver or the motor record (the motor record being very unlikely given
its widespread use for many years).

Of course, even if this didn't have the same problem, it would still
mean wrapping logic around the motor record to insert writes to the STOP
any new setpoint is written to the motor record.

Of course, the "problem" with the driver may simply be that it is
issuing different commands than I am when I bypass the driver and motor
record and give commands to the controller directly.  I am simply giving
the "jog" command 2 different absolute target values with a short delay
in between, while the driver may be sending some kind of stop command in
between, which (just a guess) might need something else before the next
target position is sent or it won't act on it.

I did use the asyn trace output to examine this when I first had a
problem, I ai seem to recall that it did indeed send some sort of stop
command and that the 2nd setpoint was never sent.  But I apparently
didn't save the result, so I will have to repeat that test when I can to
see if there is anything in the trace that may shed some more light on
this issue.

Mark

Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
On 8/1/2018 3:45 PM, J. Lewis Muir wrote:
> On 08/01, Mark Davis wrote:
>> I assume that the driver SHOULD still work with the default Yes
>> value.  Using the No value is not only less efficient, but could be
>> a real problem.  If someone makes a typo when entering a new
>> setpoint, it wouldn't matter if they realized their mistake and
>> quickly entered the correct setpoint before the device has moved
>> very much - It would still go all the way to the incorrect setting
>> before starting to move to the correct position.

> Couldn't you just stop the move?
>
> Lewis
>

--
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System