Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 28 Jun 2011 09:46:40 -0500

Hi John,

I'm glad to hear that setting RTRY=0 makes it work.  Since these are all DC servo motors and the XPS is closing the loop, RTRY=0 really is the correct setting.

I see a couple of other problems with your settings.  You have the base velocity, VBAS=0.1.  The XPS does not support the concept of a base velocity, and using a non-zero value can cause problems.  

This because the ACC field in the motor record has units of time.  But the value 
that gets passed to the driver is in steps/sec/sec calculated as follows:  
            double vbase = pmr->vbas / fabs(pmr->mres); /* base speed      */
            double vel = pmr->velo / fabs(pmr->mres);   /* normal speed    */
            double acc = (vel - vbase) / pmr->accl;     /* normal accel.   */

Thus, the acceleration is affected by VBAS.

In your case pmr->vbas=0.1, pmr->velo=0.3, pmr->mres=4.8828e-05, pmr=>accl=0.2  Thus vbas=2048, vel=6145, and acc = (6145-2048)/.2 = 20485.  The units are steps/sec and steps/sec/sec.  The driver then converts these back to engineering units (because that's what the XPS understands), by dividing by your scale factor, 20480.  Thus, the velocity will be 0.3, and the acceleration will be 1.0 mm/sec/sec.  That is probably NOT what you intended, since you set VELO=0.3 and ACCL=0.2, you would have expected 0.3/0.2 = 1.5 mm/sec/sec.

Also, you have NTM=YES.  This can lead to problems.  If this is YES, and if the motor record detects the motor moving in the "wrong" direction, it will tell the motor to stop.  For a stepper motor without encoders this may make sense.  But for a DC servo motor it can lead to real problems.  If your servo loop is not perfectly tuned the motor may overshoot its destination by a small amount.  This should not be a problem, the XPS will quickly correct it back to the desired destination.  But if the motor status is updated when the motor is moving in the "wrong" direction, (i.e. correcting the overshoot), the motor record will tell the motor to stop.  This prevents the XPS from moving the motor to its final desired position!  Thus, you should set the NTM field to NO for DC servo motors like this.

Mark

-----Original Message-----
From: John Dobbins [mailto:[email protected]] 
Sent: Tuesday, June 28, 2011 7:38 AM
To: Mark Rivers
Cc: [email protected]
Subject: Re: Newport XPS and Motor record

Mark,

Retry happens to be set to 1 on this stage. Stage info and record info 
below.

John

###########  From stages.ini  ###########

;--- Unit = mm
;--- Configuration_Comment =

;--- Smart stage name
SmartStageName=CMA-25CCCL

;--- Motor driver model parameters
DriverName=XPS-DRV01
DriverPWMFrequency=200;--- kHz

;--- Driver command interface parameters
MotorDriverInterface=AnalogVoltage
ScalingCurrent=3;--- A
CurrentLimit=0.1;--- A
ScalingVoltage=48;--- V
VoltageLimit=48;--- V

;--- Position encoder interface parameters
EncoderType=AquadB
EncoderResolution=0.000048828;--- units
LinearEncoderCorrection=0;--- ppm
Backlash=0;--- units
CurrentVelocityCutOffFrequency=100;--- Hz
CurrentAccelerationCutOffFrequency=100;--- Hz
PositionerMappingFileName=
PositionerMappingLineNumber=
PositionerMappingMaxPositionError=;--- units

;--- Limit sensor input plug parameters
ServitudesType=StandardEORDriverPlug
MinimumTargetPosition=-0.0001;--- units
MaximumTargetPosition=25;--- units
HomePreset=0;--- units
MaximumVelocity=0.4;--- units / s
MaximumAcceleration=1.6;--- units / s²
EmergencyDecelerationMultiplier=4
MinimumJerkTime=0.005;--- s
MaximumJerkTime=0.05;--- s
TrackingCutOffFrequency=25;--- Hz

;--- Home search process parameters
HomeSearchSequenceType=MinusEndOfRunHomeSearch
HomeSearchMaximumVelocity=0.2;--- units / s
HomeSearchMaximumAcceleration=0.8;--- units / s²
HomeSearchTimeOut=253;--- s

;--- Position servo loop type parameters
CorrectorType=PIDDualFFVoltage
ClosedLoopStatus=Closed
FatalFollowingError=1;--- units
KP=5440
KI=130000
KD=41.5
KS=0.8
GKP=0
GKD=0
GKI=0
KForm=0;--- units
IntegrationTime=1E+99;--- s
DerivativeFilterCutOffFrequency=5000;--- Hz
DeadBandThreshold=0;--- units
KFeedForwardVelocity=60
KFeedForwardAcceleration=0.3
KFeedForwardVelocityOpenLoop=60
Friction=0;--- V
NotchFrequency1=0;--- Hz
NotchBandwidth1=0;--- Hz
NotchGain1=0
NotchFrequency2=0;--- Hz
NotchBandwidth2=0;--- Hz
NotchGain2=0

;--- Motion done condition mode parameters
MotionDoneMode=Theoretical

epics> dbpr LGTLTS01_expander 10
ACCL: 0.2           ACKS: NO_ALARM      ACKT: YES           ASG:
ASP: 0x00000000     ATHM: 0             BACC: 0.2           BDST: 0
BKPT: 0x00          BVEL: 0.1           CARD: -1            CBAK: 0xc0b48c08
CDIR: 0             CNEN: Disable       DCOF: 0             DESC: Expander
DHLM: 24.9          DIFF: 1.95311999999668e-04              DINP:CONSTANT
DIR: Pos            DISA: 0             DISP: 0             DISS: NO_ALARM
DISV: 1             DLLM: 0             DLY: 0              DMOV: 1
DOL:CONSTANT        DPVT: 0xd8b48c08    DRBV: 11.099873928  DSET: 0x40593800
DTYP: asynMotor     DVAL: 11.10006924   EGU: mm             ERES: 4.8828e-05
EVNT: 0             FLNK:CONSTANT 0     FOF: 0              FOFF: Variable
FRAC: 1             HHSV: NO_ALARM      HIGH: 0             HIHI: 0
HLM: 24.9           HLS: 0              HLSV: NO_ALARM      HOMF: 0
HOMR: 0             HOPR: 0             HSV: NO_ALARM       HVEL: 0.1
ICOF: 0             INIT:               JAR: 1.5            JOGF: 0
JOGR: 0             JVEL: 0.3           LCNT: 0             LDVL: 
11.10006924
LLM: 0              LLS: 0              LLSV: NO_ALARM      LOCK: NO
LOLO: 0             LOPR: 0             LOW: 0              LRLV: 0
LRVL: 227330        LSET: 0x182bb0b7    LSPG: Go            LSV: NO_ALARM
LVAL: 11.10006924   LVIO: 0             MIP: 0              MISS: 0
MLIS: 0x68a5940858a6940803000000        MLOK: 0xd0a78608    MMAP: 0
MOVN: 0             MRES: 4.8828e-05    MSTA: 2050
NAME: LGTLTS01_expander                 NMAP: 0             NSEV: NO_ALARM
NSTA: NO_ALARM      NTM: YES            NTMF: 2             OFF: 0
OMSL: supervisory   OUT:INST_IO @asyn(XPS1,1)               PACT: 0
PCOF: 0             PHAS: 0             PINI: NO            POST:
PP: 0               PPN: 0x00000000     PPNR: 0x00000000    PREC: 5
PREM:               PRIO: LOW           PROC: 0             PUTF: 0
RBV: 11.099873928   RCNT: 2             RDBD: 2.0e-04       RDBL:CONSTANT
RDES: 0x10f67b08    RDIF: 4             REP: 227326         RES: 4.8828e-05
RHLS: 0             RINP:CONSTANT       RLLS: 0             RLNK:CONSTANT
RLV: 0              RMOD: Default       RMP: 227326         RPRO: 0
RRBV: 227326        RRES: 0             RSET: 0x20573800    RTRY: 1
RVAL: 227330        RVEL: 0             S: 30.7200786434013
SBAK: 10.2400262144671                  SBAS: 10.2400262144671
SCAN: Passive       SDIS:CONSTANT       SET: Use            SEVR: NO_ALARM
SMAX: 40.9601048578684                  SPMG: Go            SPVT: 0x00000000
SREV: 200           SSET: 0             STAT: NO_ALARM      STOO:CONSTANT
STOP: 0             STUP: OFF           SUSE: 0             TDIR: 0
TIME: 2011-06-27 16:30:11.109673000     TPRO: 0             TSE: 0
TSEL:CONSTANT       TWF: 0              TWR: 0              TWV: 1
UDF: 0              UEIP: No            UREV: 0.0097656     URIP: No
VAL: 11.10006924    VBAS: 0.1           VELO: 0.3           VERS: 6.44
VMAX: 0.4           VOF: 0

On 6/27/2011 6:58 PM, Mark Rivers wrote:
> Hi John,
>
> Yes, you are reading that correctly.
>
> The first time the command is sent it times out waiting for a response.
> That timeout is normal, because the XPS does not send a response on that
> socket until the move completes, and the driver does not wait for that,
> it uses a short timeout.
>
> The second time it sends the command it gets a -1 error response.  This
> error translates as:
> Error -1 : Busy socket : previous command not yet finished
>
> The third time it sends the command it get a -22 error response, which
> translates as:
> Error -22 : Not allowed action
>
>
> Something is not right!
>
> Here is what I see on my XPS IOC when I turn on the same asynTrace:
>
> ioc13bmd>  2011/06/27 17:48:24.701 164.54.160.83:5001 TCP write 44
> GroupMoveAbsolute (GROUP1.POSITIONER,2.1269)
> 2011/06/27 17:48:24.801 SendAndReceive, sent: 'GroupMoveAbsolute
> (GROUP1.POSITIONER,2.1269)'
> 2011/06/27 17:48:24.801 SendAndReceive, timeout on read
>
> I only see a single GroupMoveAbsolute command sent, not 3.
>
> Do you have a non-zero number of retries (.RTRY) set on the motor?  I
> wonder if those could be retry attempts, though that does not make
> sense, since a retry should not happen until the move completes.
>
> Can you send the output of
>
> dbpr "mymotor",10
>
> Mark
>
>
> -----Original Message-----
> From: John Dobbins [mailto:[email protected]]
> Sent: Monday, June 27, 2011 3:40 PM
> To: Mark Rivers
> Cc: [email protected]
> Subject: Re: Newport XPS and Motor record
>
> Mark,
>
> Thanks for the specific suggestions.
>
> The asyTrace output seems to show the move command is sent three times!?
>
> Am I reading this right?
>
> John
>
>
>
> epics>  2011/06/27 16:26:49.689 erpxps01:5001 TCP write 52
> GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225)
> 2011/06/27 16:26:49.790 SendAndReceive, sent: 'GroupMoveAbsolute
> (GROUP2.POSITIONER,11.20009791225)'
> 2011/06/27 16:26:49.790 SendAndReceive, timeout on read
> 2011/06/27 16:26:49.791 erpxps01:5001 TCP write 52
> GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225)
> 2011/06/27 16:26:49.791 erpxps01:5001 TCP read 64
> -1,GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225),EndOfAPI
> 2011/06/27 16:26:49.791 SendAndReceive, sent: 'GroupMoveAbsolute
> (GROUP2.POSITIONER,11.20009791225)'
> 2011/06/27 16:26:49.791 SendAndReceive, read: '-1,GroupMoveAbsolute
> (GROUP2.POSITIONER,11.20009791225),EndOfAPI'
> 2011/06/27 16:26:49.791 erpxps01:5001 TCP write 52
> GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225)
> 2011/06/27 16:26:49.792 erpxps01:5001 TCP read 65
> -22,GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225),EndOfAPI
> 2011/06/27 16:26:49.792 SendAndReceive, sent: 'GroupMoveAbsolute
> (GROUP2.POSITIONER,11.20009791225)'
> 2011/06/27 16:26:49.792 SendAndReceive, read: '-22,GroupMoveAbsolute
> (GROUP2.POSITIONER,11.20009791225),EndOfAPI'
> 2011/06/27 16:26:49.792 SendAndReceive unexpected response
> =-22,GroupMoveAbsolute (GROUP2.POSITIONER,11.20009791225),EndOfAPI
>
>
>
>
>
> On 6/27/2011 2:50 PM, Mark Rivers wrote:
>> Hi John,
>>
>>> If I look in the XPS web interface I don't see any errors reported
>>> there. Should I expect to see them there?
>>
>> No, you would not see them there.  You can use the terminal interface
> in
>> the Web page to translate error numbers into messages, but you won't
> see
>> messages as errors occur.
>>
>> If the motor is moving normally, but is reporting that error, then I
>> wonder if perhaps it is being told to move a second time while it is
>> already moving, for example?
>>
>> You can do
>>
>> asynReport
>>
>> to see the names of all of the asyn IP port drivers connected to this
>> XPS.  There will be several.  One is used for status on all axes, and
>> there is 1 per axis for issuing "move" commands.  You can enable trace
>> debugging on these ports with
>>
>> asynSetTraceIOMask "port",0,2
>> asynSetTraceMask "port",0,9
>>
>> That sets asynTraceIOEscape (to see ASCII messages with escape
>> sequences) and asynTraceIODriver, to see messages from the asyn IP
>> driver.
>>
>> With that level of debugging you should be able to see what commands
> are
>> being sent to the XPS, and which ones are working, and which are
>> resulting in the error you see.
>>
>> Send the output of "dbpr myMotor 10" (which will print all the motor
>> record fields) and the contents of the stage definition file for those
>> motors, so we can compare maximum velocity, acceleration, limits, etc.
>>
>> Mark
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of John Dobbins
>> Sent: Monday, June 27, 2011 1:29 PM
>> To: [email protected]
>> Subject: Re: Newport XPS and Motor record
>>
>> All,
>>
>> Thanks for the various replies.
>>
>> If I look in the XPS web interface I don't see any errors reported
>> there. Should I expect to see them there?
>>
>> The stages actually move normally. And report statuses that would be
>> expected, "Ready from Homing", "Reading from Moving", ...
>>
>> Also I have two different stage types connected and both types produce
>> this error.
>>
>> The XPS configuration was generated by the XPS using that option as
>> available in the web interface. Limits, velocities, ... appear to be
> set
>>
>> correctly. So I can't tell what the XPS is complaining about.
>>
>>
>> John
>>
>> On 6/27/2011 11:57 AM, John Hammonds wrote:
>>> I once had a problem that the configured velocity (in the motor
>> record)
>>> was not allowed by the XPS.  It returned the same error code.  This
>> was
>>> a manually configured motor.   We had to play around a bit to get the
>>> XPS configuration correct.
>>>
>>> John
>>>
>>> On 6/27/2011 10:52 AM, Pete Jemian wrote:
>>>>
>>>> John:
>>>>
>>>> What is your configuration in the XPS controller?
>>>> Can that have some influence?
>>>>
>>>> Pete
>>>>
>>>> On 06/27/2011 09:51 AM, [email protected] wrote:
>>>>> Hi,
>>>>>
>>>>> It could also be that the XPS axis is in the wrong 'state'. I think
>>>>> it needs to be in 'ready state' (states 10 to 13) to receive move
>>>>> commands.
>>>>>
>>>>> I updated the XPS driver recently. So in the next release of the
>>>>> motor support module the driver should indicate if there is a
>> problem
>>>>> (via the motor record MSTA field). So if the axis is in a state
>> which
>>>>> means you can't move it then you will be notified by the record
>> going
>>>>> into alarm state.
>>>>>
>>>>> Cheers,
>>>>> Matthew
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email protected] [mailto:tech-talk-
>>>>>> [email protected]] On Behalf Of Mark Rivers
>>>>>> Sent: 27 June 2011 15:17
>>>>>> To: John Dobbins; EPICS Tech-Talk
>>>>>> Subject: RE: Newport XPS and Motor record
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> If you translate that error code, -22, using ErrorStringGet in the
>> XPS
>>>>>> Web terminal interface you will get:
>>>>>>
>>>>>> 0,Error -22 : Not allowed action
>>>>>>
>>>>>> So there is something illegal about the request you are making.
> Is
>> it
>>>>>> possible that you are exceeding a soft limit, etc.?
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email protected]
>>>>>> [mailto:[email protected]] On Behalf Of John Dobbins
>>>>>> Sent: Monday, June 27, 2011 8:38 AM
>>>>>> To: EPICS Tech-Talk
>>>>>> Subject: Newport XPS and Motor record
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> I am using Motor Record R6-4-4 , EPICS R3.14.9, ASYN 4-9 with a
>> Newport
>>>>>> XPS controller.
>>>>>>
>>>>>> When I send a new position to an actuator I get a messages in the
>> IOC
>>>>>> like this:
>>>>>>
>>>>>> epics>     2011/06/24 12:35:35.552 SendAndReceive unexpected
> response
>>>>>> =-22,GroupMoveAbsolute (GROUP2.POSITIONER,12.00003072008),EndOfAPI
>>>>>>
>>>>>> otherwise everything seems to be working, i.e. motor responds
>> properly.
>>>>>>
>>>>>> Does someone know what this means? The XPS set-up portion of my
>> st.cmd
>>>>>> script is below.
>>>>>>
>>>>>> Regards and Thanks,
>>>>>>
>>>>>> John Dobbins
>>>>>>
>>>>>> Cornell University
>>>>>>
>>>>>>
>>>>>> The XPS set-up portion of my st.cmd script:
>>>>>>
>>>>>>
>>>>>> # cards (total controllers)
>>>>>> XPSSetup(1)
>>>>>>
>>>>>> # card, IP, PORT, number of axes, active poll period (ms), idle
>> poll
>>>>>> period (ms)
>>>>>> XPSConfig(0, "erpxps01", 5001, 3, 10, 500)
>>>>>> # asyn port, driver name, controller index, max. axes)
>>>>>> drvAsynMotorConfigure("XPS1", "motorXPS", 0, 3)
>>>>>>
>>>>>> # card,  axis, groupName.positionerName, stepsPerUserUnit
>>>>>> # PR50CC rotational stage
>>>>>> XPSConfigAxis(0,0,"GROUP1.POSITIONER",100)
>>>>>> # CMA-12CCCL linear stage
>>>>>> XPSConfigAxis(0,1,"GROUP2.POSITIONER",20480)
>>>>>> # CMA-12CCCL linear stage
>>>>>> XPSConfigAxis(0,2,"GROUP3.POSITIONER",20480)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System