@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
- Replies:
- Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Pearson, Matthew R.
- Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Torsten Bögershausen
- 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
- 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
- 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 Torsten Bögershausen
- Navigate by Date:
- Prev:
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Torsten Bögershausen
- 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
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Torsten Bögershausen
- Next:
Re: Motor Module, Deferred Movement, .VAL field set to .RBV after motion Pearson, Matthew R.
- 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·