Fwd: Re: Delta Tau motor control problem

[Mark Davis <davism50@msu.edu>]

(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