EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Motor Module, Deferred Movement, .VAL field set to .RBV after motion
From: "Mooney, Tim M." <[email protected]>
To: Jacob DeFilippis <[email protected]>, "Rivers, Mark L." <[email protected]>, "Sluiter, Ronald L." <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Wed, 29 Jun 2016 20:42:52 +0000
The good news is that .RBV is tracking the motor's actual motion, and gets to very nearly the right value when "the controller command that moves the motors synchronously to the commanded target" finishes.  What happens after that command finishes?  Can you delay the apparent completion until after the next motor update?

Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: [email protected] [[email protected]] on behalf of Jacob DeFilippis [[email protected]]
Sent: Wednesday, June 29, 2016 3:14 PM
To: Rivers, Mark L.; Sluiter, Ronald L.
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



Replies:
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
References:
Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Ron Sluiter
RE: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Mark Rivers
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis

Navigate by Date:
Prev: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
Next: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
Next: Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Jacob DeFilippis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·