Experimental Physics and
Industrial Control System

"[email protected]" <[email protected]> · Fri, 3 Aug 2018 13:26:20 +0000

Hi Torsten,

For 'dumb mode' I would like the motor record to always send the commands that the user requests and only send those commands.

In the case of the NTM for our controller we do not need it since it handles it itself and would not require a stop. Equally if this was not the case then we could choose to handle it in the driver.

However this dumb mode would still have put-with-callback for demands so that I get a callback only when a move completes. This would allow high level systems to know when it is OK to send the next command.

The specific problem with NTM is that it sometimes it seems to fire just because jittery motors are jiggling about. I have demonstrated this by watching apparently idle motors get the message

:tdir = 0
or

:tdr = 1

from time to time.

For these motors, when using a deferred move, I cannot guarantee that all demands get through and a deffered move for 4 motors becomes one for 3 motors with unexpected results.

I discussed this on techtalk previously https://epics.anl.gov/tech-talk/2015/msg01516.php

Cheers,

  giles.

________________________________
From: [email protected] <[email protected]> on behalf of Torsten Bögershausen <[email protected]>
Sent: 03 August 2018 13:24:29
To: [email protected]
Subject: Re: Delta Tau motor control problem

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

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