Experimental Physics and
Industrial Control System

Torsten Bögershausen <[email protected]> · Fri, 3 Aug 2018 14:24:29 +0200

On 03/08/18 14:03, [email protected] 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: [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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System