RE: Motor record: No longer issues a stop command when motor already stopped?

[<James.OHea@diamond.ac.uk>]

 

Thanks Ron.

 

That’s a great help.

 

James

 

 

From: Sluiter, Ronald L. [mailto:sluiter@aps.anl.gov]
Sent: 07 July 2017 15:58
To: Palaha, Arvinder (DLSLtd,RAL,TEC); O'Hea, James (DLSLtd,RAL,TEC)
Cc: Peterson, Kevin M.; EPICS
Subject: Re: Motor record: No longer issues a stop command when motor already stopped?

 

Hello James and Arvinder,

I apologize, James, for not responding to your tech-talk post. I see that I did not delete it from my inbox, so it (like so much else) must have fallen off my radar.

I am fairly confident that the change in behavior you are seeing is due to this change; or more accurately, this is a consequence of the "Allow moving out of invalid soft limit travel range toward valid soft limit travel range." change. The relevant modifications there are on lines #1341-1342 -> #1366-1368, where the limit violation error check was changed in two ways. First, the error check itself was changed from always being performed, to only being performed while commanded motion was active (jog, home or move). Second the error check was changed from using the feedback (drbv) to the reference (dval).

Ron

On 07/06/2017 10:24 AM, arvinder.palaha@diamond.ac.uk wrote:

Hello,

we posted a topic on the mailing list not long ago about a change in behaviour of motor limits, and we didn't receive any replies.

As you are both listed as owners of the motor module, I was wondering if you may have an idea as to how the changes from 6-7-1 to 6-9 would change the motor limit behaviour from regularly registering a limit violation with a jittering encoder to not registering a limit violation once the motor has stopped.

The regular limit violations was causing stop signals to be sent, which caused an in vacuum motor to heat up. In upgrading motor, this problem went away, which is good, but we don't understand why, which is not quite as good.

If you could shed any light on this, it would be really appreciated. I have copied the original email sent to tech-talk below.

Yours sincerely,

Arvinder Palaha

Beamline Control Systems

DH G.63

T: +44-(0)1235-77-8137

E: arvinder.palaha@diamond.ac.uk

---------------------------------------------------------------------------------------------------------------------

At Diamond we often implement a software PLC on the motor controllers to disable the amplifier of in-vacuum motors (sending a kill command) when they have completed a move.  This is to avoid the motors overheating in vacuum.

However, recently we had an overheating problem on an in-vacuum motor because a motor amplifier was constantly being re-energised after this PLC had de-energised it.  This was due to the motor’s flickering encoder causing it to regularly register a soft limit condition.  Whenever the motor record went into a soft limit state it issued a Stop command to the motor re-energising its amplifier.  The PLC and the motor record would then ‘fight’ each other, one disabling the motor, the other enabling it.

We were using motor record version 6-7-1 when we encountered this issue.  After upgrading to 6-9 the problem appears to have gone away.  This is good news but I would like to understand what may have changed to avoid this situation?  I see a lot of limit related changes have happened between these two release numbers.  Can anyone point me to a change which may explain the fix we see?

The change must be to do with not sending a Stop command if the motor is already stopped?

Thanks for any guidance,

James

---------------------------------------------------------------------------------------------------------------------

 

 

-- 

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