Experimental Physics and
Industrial Control System

Mark Davis <[email protected]> · Mon, 6 Aug 2018 07:29:30 -0400

Hi Lewis,

Sorry if my response was a bit confusing.  I did realize what you were

asking, and I agree that having a stop button on the UI makes sense and

would generally be a faster and safer alternative to correcting a typo

in a setpoint.

But it is true that (prior to my setting the InPosBand value on the

controller to a non-0 value) that using the STOP field of the motor

record to stop a movement would also result in the motor record waiting

for the status value from the controller to indicate the last

movement-related command had completed, which would never happen

unless/until I directly (via a command-line shell on the controller

itself) gave the controller a new move command and let it complete the

move (I expect doing it through the vendor's IDE would achieve the same

thing).

Mark

Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
On 8/3/2018 11:15 AM, J. Lewis Muir wrote:

On 08/02, Mark Davis wrote:

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?

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.

My main point here was just about the user scenario you described where
the user makes a mistake and then tries to quickly enter the correct
setpoint, but the motor goes all the way to the incorrect setpoint
before starting the move to the correct setpoint.  I was just suggesting
that the user could quickly stop the move rather than quickly entering
a new setpoint.  That works, right?  The motor doesn't continue moving
to the incorrect setpoint after the user has commanded a stop, right?  I
understand your bigger issue with the behavior, but just from a safety
point of view for the user scenario you described, stopping the move is
no less safe than entering the correct setpoint.  If anything, stopping
is probably a little safer just because the user wouldn't have to think
about the correct setpoint and enter it; they could just stop the move.

But then you're saying that after commanding a stop, you can no longer
command a move to a new setpoint, ever?  That seems broken.

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System