To test my hypothesis please send the value of the motor record MSTA field when it is in the "hung" state and won't accept new move commands after a stop is issued.
________________________________
From: [email protected] <[email protected]> on behalf of Mark Rivers <[email protected]>
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
- References:
- Fwd: Re: Delta Tau motor control problem Mark Davis
- Re: Re: Delta Tau motor control problem [email protected]
- Re: Re: Delta Tau motor control problem Mark Rivers
- Navigate by Date:
- Prev:
Re: Re: Delta Tau motor control problem Mark Rivers
- Next:
Re: streamDevice 32-Bit ULONG endianess Dirk Zimoch
- 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:
Re: Re: Delta Tau motor control problem Mark Rivers
- Next:
Re: Re: Delta Tau motor control problem Mark Rivers
- 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
|