Re: Delta Tau motor control problem

["Pearson, Matthew R." <pearsonmr@ornl.gov>]

Hi Mark,

When the motor record and/or driver is hung up, please can you dump out the motor record fields on the IOC shell? 

eg:

> dbpr my_motor 10

That will give us the value of MSTA as well as all the other fields that may be affecting this.

Cheers,
Matt

Data Acquisition and Controls Engineer
Spallation Neutron Source
Oak Ridge National Lab


> On Aug 6, 2018, at 7:29 AM, Mark Davis <davism50@msu.edu> wrote:
> 
> 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 davism50@msu.edu
> 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
>> 
>