Experimental Physics and
Industrial Control System

"Pearson, Matthew R." <[email protected]> · Thu, 30 Jun 2016 17:50:21 +0000

FYI, I don’t see this for a normal move (with or without UEIP, with or without non-zero RTRY), but I do see this for these conditions:

* STOP field was set to 1 during the move
* the move was externally generated
* the move stopped due to a limit switch

jog based moves should also cause it.

Here is a normal move:

BL100:Mot:shutter.DMOV         2016-06-30 12:48:03.536661 0  
BL100:Mot:shutter.VAL          2016-06-30 12:48:10.133930 11  
BL100:Mot:shutter.RBV          2016-06-30 12:48:10.486333 9.99375  
BL100:Mot:shutter.RBV          2016-06-30 12:48:10.974228 10.3125  
BL100:Mot:shutter.RBV          2016-06-30 12:48:11.460077 10.8063  
BL100:Mot:shutter.RBV          2016-06-30 12:48:11.945679 10.9719  
BL100:Mot:shutter.RBV          2016-06-30 12:48:12.434507 10.9781  
BL100:Mot:shutter.DMOV         2016-06-30 12:48:12.434507 1  
BL100:Mot:shutter.RBV          2016-06-30 12:48:12.935817 10.9719

and a small externally generated move:

BL100:Mot:shutter.RBV          2016-06-30 12:49:19.644680 12.075  
BL100:Mot:shutter.DMOV         2016-06-30 12:49:19.644680 0  
BL100:Mot:shutter.RBV          2016-06-30 12:49:20.129310 12.5125  
BL100:Mot:shutter.RBV          2016-06-30 12:49:20.614913 12.6156  
BL100:Mot:shutter.VAL          2016-06-30 12:49:20.614913 12.6156  
BL100:Mot:shutter.DMOV         2016-06-30 12:49:20.614913 1  
BL100:Mot:shutter.RBV          2016-06-30 12:49:21.919218 12.5906

It seems to be the postProcess() function in the motor record that would cause VAL to be changed, but I can’t see how that is called for a normal move caused by writing to VAL.

Cheers,
Matt

> On Jun 30, 2016, at 11:41 AM, Jacob DeFilippis <[email protected]> wrote:
> 
> @Torsten
> It is a servo motor with an internal encoder that has 4,000 count per revolution resolution
> The problem is this not the standard behavior if the motor doesn't reach the setpoint, the setpoint should not change,
> or at least this is how I understand it. I think this would be confusing for a user driving the motors.
> 
> The MRES field is set to 0.0001. But this is arbitrary for now since setpoint values are converted to counts.
> 
> dbpr SMOTOR:AXIS:1 10
> ACCL: 0.2           ACKS: NO_ALARM      ACKT: YES           ADEL: 0
> ALST: 0             ASG: MC_MAINT       ASP: (nil)          ATHM: 0
> BACC: 0.5           BDST: 0             BKPT: 00            BVEL: 0.1
> CARD: 0             CBAK: 0x85dd6f8     CDIR: 0             CNEN: Disable
> DCOF: 0             DESC:               DHLM: 0             DIFF: 0.4905
> DINP:CONSTANT       DIR: Neg            DISA: 0             DISP: 0
> DISS: NO_ALARM      DISV: 1             DLLM: 0             DLY: 0
> DMOV: 1             DOL:CONSTANT        DPVT: 0x85e3db8     DRBV: 4.0e-04
> DSET: 0x98b960      DTYP: asynMotor     DVAL: 0.4909        EGU: mm
> ERES: 1.0e-04       EVNT: 0             FLNK:CONSTANT 0     FOF: 0
> FOFF: Frozen        FRAC: 1             HHSV: NO_ALARM      HIGH: 0
> HIHI: 0             HLM: 0              HLS: 0              HLSV: NO_ALARM
> HOMF: 0             HOMR: 0             HOPR: 0             HSV: NO_ALARM
> HVEL: 0.1           ICOF: 0             INIT:               JAR: 2.5
> JOGF: 0             JOGR: 0             JVEL: 0.5           LCNT: 0
> LDVL: 0.4909        LLM: 0              LLS: 0              LLSV: NO_ALARM
> LOCK: NO            LOLO: 0             LOPR: 0             LOW: 0
> LRLV: 0             LRVL: 4909          LSET: 0x85e5750     LSPG: Go
> LSV: NO_ALARM       LVAL: -0.4909       LVIO: 0             MDEL: 0
> MIP: 0              MISS: 0
> MLIS: b0 b0 61 08 d8 a1 61 08 49 00 00 00                   MLOK: d8 b9 5d 08
> MLST: 0             MMAP: 0             MOVN: 0             MRES: 1.0e-04
> MSTA: 2306          NAME: SMOTOR:AXIS:1 NMAP: 0             NSEV: NO_ALARM
> NSTA: NO_ALARM      NTM: YES            NTMF: 2             OFF: 0
> OMSL: supervisory   OUT:INST_IO @asyn(SM1,1)                PACT: 0
> PCOF: 0             PHAS: 0             PINI: NO POST:
> PP: 0               PPN: (nil)          PPNR: (nil)         PREC: 4
> PREM:               PRIO: HIGH          PROC: 0             PUTF: 0
> RBV: -4.0e-04       RCNT: 0             RDBD: 1.0e-04 RDBL:CONSTANT
> RDES: 0x85a6310     RDIF: 4905          REP: 4              RHLS: 0
> RINP:CONSTANT       RLLS: 0             RLNK:CONSTANT       RLV: 0
> RMOD: Default       RMP: 4              RPRO: 0             RRBV: 4
> RRES: 0             RSET: 0x98b880      RTRY: 0             RVAL: 4909
> RVEL: 0             S: 25               SBAK: 5             SBAS: 5
> SCAN: Passive       SDIS:CONSTANT       SET: Use            SEVR: NO_ALARM
> SMAX: 183.5         SPMG: Go            SPVT: (nil)         SREV: 200
> SSET: 0             STAT: NO_ALARM      STOO:CONSTANT       STOP: 0
> STUP: OFF           SUSE: 0             SYNC: 0             TDIR: 0
> TIME: 2016-06-30 08:23:12.109352047     TPRO: 0             TSE: 0
> TSEL:CONSTANT       TWF: 0              TWR: 0              TWV: 0.1
> UDF: 0              UEIP: No            UREV: 0.02          URIP: No
> VAL: -0.4909        VBAS: 0.1           VELO: 0.5           VERS: 6.9
> VMAX: 3.67          VOF: 0
> 
> The motorStatusDone_ field is updated by
> sprintf(pC_->outString_, REPORTSTATUS0, canAddr_); // Report 16-bit status word
>  status = pC_->writeReadController();
>  if (status) goto skip;
>  currentStatus_ = atoi(pC_->inString_);
>  setIntegerParam(pC_->smartStatus_,currentStatus_);
>  done = (currentStatus_ & MOVING)?0:1;  // Trajectory in progress, MOVING  is  a bit mask
>  *moving = done ? false:true;
>  setIntegerParam(pC_->motorStatusDone_, done);
> 
> If I create a public repo I will post on the thread
> On 6/30/2016 8:28 AM, Torsten Bögershausen wrote:
>> Hej again,
>> I can’t reproduce it here.
>> 
>> What does
>> dbpr SMOTOR:AXIS:1
>> give ?
>> 
>> And another question:
>> What does your driver put into
>> 
>> setIntegerParam(pC_->motorStatusMoving_
>> and what into
>> setIntegerParam(pC_->motorStatusDone_
>> 
>> Can you send us a copy of the driver code, or is it somewhere on a public repo ?
>> 
>> 
>> Am 30.06.2016 um 13:54 schrieb Mark Rivers <[email protected]>:
>> 
>>> Hi Jacob,
>>> 
>>> You did not answer this question:
>>> 
>>>> Does the controller ever report that the position is equal to the requested position, or is it always off by that small amount, i.e. even after a move is complete and the controller is reporting its position at the slow poll rate?
>>> Some more questions:
>>> 
>>> - Is this a motor that accepts and reports its positions in steps, or does it use engineering units?  If it uses steps then if you tell the motor to go to a step position does it always report that it reached that exact position?  If not then I think there is a bug in the controller.   If the controller is programmed in engineering units, then it is the responsibility of your driver to convert motor record positions (in steps) to engineering units for move commands, and to convert engineering units to steps for readback commands.  It is also your driver's responsibility to ensure that the motor record step positions are actually positions that are reachable by the controller, i.e. that they are integer numbers of controller steps.
>>> 
>>> What controller is this?
>>> 
>>> Mark
>>> 
>>> ________________________________________
>>> From: Jacob DeFilippis [[email protected]]
>>> Sent: Wednesday, June 29, 2016 7:13 PM
>>> To: Mark Rivers; 'Ron Sluiter'
>>> Cc: [email protected]
>>> Subject: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion
>>> 
>>> Okay so in the original poll function the readback is set before the
>>> status. So I changed the order. Unfortunately this did not produce
>>> better results. I then placed in a delay before  the  readback when the
>>> DMOV goes from 0 to 1. The behavior persists.
>>> 
>>> SMOTOR:AXIS:1                      2016-06-29 17:04:30.658694 30
>>> SMOTOR:AXIS:1.DMOV          2016-06-29 17:04:30.658894 1
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:31.135564 25.0821
>>> SMOTOR:AXIS:1.DMOV          2016-06-29 17:04:31.135564 0
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:33.578796 26.3076
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:36.021029 27.529
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:38.463166 28.7494
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:40.903696 29.9656
>>> SMOTOR:AXIS:1                      2016-06-29 17:04:43.142160 29.9656
>>> SMOTOR:AXIS:1.DMOV          2016-06-29 17:04:43.142160 1
>>> SMOTOR:AXIS:1.RBV              2016-06-29 17:04:45.823197 29.9996
>>> 
>>> You can see that the last readback updates a few seconds after the DMOV
>>> goes high, but the setpoint still is changed to the readback. This
>>> happened under single motion with 0 retries.
>>> 
>>> The delay works as follows, prevDone is a field of  the axis class, done
>>> is a local variable
>>>  if(done && !prevDone_ ){
>>>     prevDone_ = done;
>>>     goto skip;
>>>   }
>>>   prevDone_ = done;
>>>   pollPosition();
>>> 
>>>    ....
>>> 
>>>  skip:
>>>  callParamCallbacks()
>>> 
>>> Jacob
>>> 
>>> On 6/29/2016 2:21 PM, Mark Rivers wrote:
>>>> So this problem really has nothing to do with deferred moves.  The same undesired behavior is seen when using a normal move if retries is 0.
>>>> 
>>>> Does the controller ever report that the position is equal to the requested position, or is it always off by that small amount, i.e. after a move is complete and the motor is reporting its position at the slow poll rate?
>>>> 
>>>> In your poller are you reading the position before or after you read the done moving status?  If you are reading it before then perhaps that is the problem?  What if you read the position after the done moving status?  Perhaps even add a small delay when you detect that a move has just completed before reading the position.  I have done that in some of my drivers in the past.
>>>> 
>>>> Mark
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Jacob DeFilippis [mailto:[email protected]]
>>>> Sent: Wednesday, June 29, 2016 3:15 PM
>>>> To: Mark Rivers; 'Ron Sluiter'
>>>> Cc: [email protected]
>>>> Subject: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion
>>>> 
>>>> @Ron
>>>> Version 6.9
>>>> 
>>>> @Mark
>>>> This is not necessarily the case for example, this is a single move with
>>>> a non-zero number of retries
>>>> SMOTOR:AXIS:1.DMOV         2016-06-29 13:10:48.487763 1
>>>> SMOTOR:AXIS:1.VAL              2016-06-29 13:10:48.487763 19.9926
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:10:48.487763 19.9936
>>>> SMOTOR:AXIS:1.DMOV         2016-06-29 13:10:48.487763 0
>>>> SMOTOR:AXIS:1.VAL              2016-06-29 13:10:55.927566 25
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:10:57.765592 20.0858
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:10:59.962699 21.1839
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:02.159951 22.283
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:04.357444 23.382
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:06.555026 24.4807
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:08.753050 24.9996
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:13.147318 24.9993
>>>> SMOTOR:AXIS:1.DMOV          2016-06-29 13:11:23.890093 1
>>>> /*no setpoint change*/
>>>> 
>>>> But a single move with a zero number of retries
>>>> SMOTOR:AXIS:1.DMOV           2016-06-29 13:11:24.378107 1
>>>> SMOTOR:AXIS:1.VAL               2016-06-29 13:11:24.378107 25
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:11:24.378107 24.9993
>>>> SMOTOR:AXIS:1.DMOV          2016-06-29 13:11:24.378107 0
>>>> SMOTOR:AXIS:1.VAL               2016-06-29 13:12:26.321196 30
>>>> SMOTOR:AXIS:1.DMOV          2016-06-29 13:12:26.321564 1
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:26.795562 25.0862
>>>> SMOTOR:AXIS:1.DMOV          2016-06-29 13:12:26.795562 0
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:28.992570 26.1841
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:31.190003 27.2832
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:33.387377 28.3824
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:35.584989 29.4812
>>>> SMOTOR:AXIS:1.RBV              2016-06-29 13:12:37.782270 29.9996
>>>> SMOTOR:AXIS:1.VAL              2016-06-29 13:12:37.782270 29.9996 <-
>>>> setpoint change
>>>> SMOTOR:AXIS:1.DMOV         2016-06-29 13:12:37.782270 1
>>>> 
>>>> 
>>>> Unfortunately setting a non-zero retry does not help when it comes to
>>>> deferred motion. I should mention at this point I have been using a work
>>>> around which stops this behavior. If the OMSL field is set to
>>>> closed_loop this behavior does not show. This field is unrelated to
>>>> motion,but it will avoid the branch of logic that is executed in the
>>>> motor record.
>>>> 
>>>> I am not using an encoder the controller reports back step counts, those
>>>> are then translated via MRES (UEIP = No). I think the controller is
>>>> moving to the correct position and the setpoint is within the resolution
>>>> of the motor.  Ultimately the EPICs side should trust the controller
>>>> with is special synchronized motion algorithm.
>>>> 
>>>> On 6/29/2016 12:39 PM, Mark Rivers wrote:
>>>>> I think the motor record does always sets the VAL field to match the RBV field when motion completes.  This is true regardless of whether you are using deferred moves or not.
>>>>> 
>>>>> What happens if you do the same camonitor on a normal move of this axis, not a deferred move?
>>>>> 
>>>>> Why your controller is saying that the position is 3.993 and that the move is complete, when it was told to go to 4.000?  Does this motor have an encoder?  Are you using the encoder for readback, i.e. what is the value of the UEIP field?
>>>>> 
>>>>> Mark
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: [email protected] [mailto:[email protected]] On Behalf Of Ron Sluiter
>>>>> Sent: Wednesday, June 29, 2016 2:23 PM
>>>>> To: Jacob DeFilippis
>>>>> Cc: [email protected]
>>>>> Subject: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion
>>>>> 
>>>>> Hello Jacob,
>>>>> 
>>>>> What version (VERS field) of the motor record are you using?
>>>>> 
>>>>> The folks at Diamond are the experts in the use of the motor record
>>>>> deferred move function. I defer to them on this topic.
>>>>> 
>>>>> Ron
>>>>> 
>>>>> On 6/29/2016 1:32 PM, Jacob DeFilippis wrote:
>>>>>> Hello,
>>>>>>      I am working on implementing a multiple axis synchronized motion
>>>>>> using the motor module's asynController base class (model 3). The move
>>>>>> function is set up such that  it stores the .VAL to variables inside
>>>>>> the physical controller when the deferredMove flag is 1, and when
>>>>>> there is a transition from 1-> 0 on the flag I issue the controller
>>>>>> command that moves the motors synchronously to the commanded target.
>>>>>> 
>>>>>>      My problem is when the move completes the .VAL field is set to the
>>>>>> .RBV field.  This happens when the .DMOV is returned to 1. I tracked
>>>>>> down the cause, which is found in motorRecord.cc in function
>>>>>> postProcess(motorRecord * pmr) line 762 (In the github repo). It
>>>>>> executes "pmr->val = pmr->rbv" . I am unsure why this postprocess is
>>>>>> occurring.  Is there anything extra I should implement in my function
>>>>>> that issues synchronized motion?  or possibly something extra in the
>>>>>> polling function. Is this because the RTRY field is set to 0?
>>>>>> 
>>>>>> An example of the bad behavior:
>>>>>> SMOTOR:AXIS:1.VAL                 2016-06-29 11:05:24.259733 4
>>>>>> SMOTOR:AXIS:1.DMOV            2016-06-29 11:05:24.474977 1
>>>>>> SMOTOR:AXIS:1.RBV                2016-06-29 11:05:27.892752 3.0181
>>>>>> SMOTOR:AXIS:1.DMOV            2016-06-29 11:05:27.892752 0
>>>>>> SMOTOR:AXIS:1.RBV                2016-06-29 11:05:30.090092 3.4665
>>>>>> SMOTOR:AXIS:1.RBV                2016-06-29 11:05:32.287451 3.9155
>>>>>> SMOTOR:AXIS:1.RBV                2016-06-29 11:05:34.484984 3.9993
>>>>>> SMOTOR:AXIS:1.VAL                 2016-06-29 11:05:34.484984 3.9993
>>>>>> <--My problem
>>>>>> SMOTOR:AXIS:1.DMOV            2016-06-29 11:05:34.484984 1
>>>>>> 
>>>>>> My motor record
>>>>>> record(motor, "$(P):$(M):$(ADDR)") {
>>>>>>    field(SCAN, "Passive")
>>>>>>    field(DTYP, "asynMotor")
>>>>>>    field(DISS, "NO_ALARM")
>>>>>>    field(DIR, "$(DIR)")
>>>>>>    field(VELO, "$(VELO)")
>>>>>>    field(VBAS, "$(VBAS)")
>>>>>>    field(VMAX, "$(VMAX)")
>>>>>>    field(URIP, "No")
>>>>>>    field(PREC, "4")
>>>>>>    field(EGU, "mm")
>>>>>>    field(MRES, "$(MRES)")
>>>>>>    field(OUT, "@asyn($(PORT),$(ADDR))")
>>>>>>    field(TWV, ".1")
>>>>>>    field(ASG, "MC_MAINT")
>>>>>>    field(FOFF, "Frozen")
>>>>>>    field(PRIO, "HIGH")
>>>>>>    field(OMSL, "closed_loop")
>>>>>>    field(RTRY, "0")
>>>>>> }
>>>>>> 
>>>>>> My function that triggers synchronized motion
>>>>>> asynStatus Axis::processDeferredMoves()
>>>>>> {
>>>>>>    asynStatus status;
>>>>>> 
>>>>>>    /*resets controller flag*/
>>>>>>     status = resetFlags();
>>>>>>     if(status) goto skip;
>>>>>> 
>>>>>>    /*sends command to start synchronized motion*/
>>>>>>     sprintf(pC_->outString_,GOSYNC);
>>>>>>     status = pC_->writeController();
>>>>>> 
>>>>>>     skip:
>>>>>>     setIntegerParam(pC_->motorStatusDone_, 0);
>>>>>>     setIntegerParam(pC_->motorStatusCommsError_, status ? 1:0);
>>>>>>     callParamCallbacks();
>>>>>>     pC_->wakeupPoller();
>>>>>>     return asynSuccess;
>>>>>> }
>>>>>> 
>>>>>> Thanks in advance,
>>>>>> Jacob
>>> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System