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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion |
From: | Jacob DeFilippis <[email protected]> |
To: | "Mooney, Tim M." <[email protected]>, "Rivers, Mark L." <[email protected]>, "Sluiter, Ronald L." <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Wed, 29 Jun 2016 14:11:31 -0700 |
@TimWhen the synchronize command is issued, the motors move synchronously, but the motors report their position and their moving status the same way as if they were to move individually via the poll function in the epics driver. The completion is determined by the moving status that is reported back from each motor. I have tried to delay the DMOV field from going high with the DLY field set to some value, but this is hard to tune and sometimes will not work the way I want.
Jacob On 6/29/2016 1:42 PM, Mooney, Tim M. wrote:
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