Re: Delta Tau motor control problem

[Torsten Bögershausen <torsten.bogershausen@esss.se>]

On 03/08/18 14:03, giles.knap@diamond.ac.uk wrote:
> 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.
Sorry for asking: Did Alans mail make it to this list ?
(Or is it moved away by my broken email-filtering-machine ?)
> 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.
Does it matter, who decides to send the STOP, at all ?The NTM field is 
certainly one feature that the user must know about,
and, in certain cases, switch it off.

At the same time, it should always be possible to STOP a motor,
for whatever reason.

> 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.
Yes and no.
In general, scripts and other high-level control systems want to know,
when they can send a new position/command to the controller.

When a controller "says", Oh I have been stopped, I need to rampdown,
that is OK.
But if the controller "says" forever "Oh, I am Busy", that is not a good
behavior.

Which configuration can be tweaked to "unblock" the PMAC after a STOP ?


> Regards,
>
>    giles.
>
>
> ________________________________
> From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Mark Davis <davism50@msu.edu>
> Sent: 03 August 2018 12:35:05
> To: tech-talk@aps.anl.gov
> 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 davism50@msu.edu
> 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