Experimental Physics and
Industrial Control System

(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

Replies:

Re: Re: Delta Tau motor control problem [email protected]

Re: Delta Tau motor control problem J. Lewis Muir

Navigate by Date:

Prev: DBE_PROPERTY and Gateway Dominic Oram - UKRI STFC

Next: Re: Re: Delta Tau motor control problem [email protected]

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: Delta Tau motor control problem J. Lewis Muir

Next: Re: Re: Delta Tau motor control problem [email protected]

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