An ecmc motion system usually contains three cascaded loops:
For many applications, default drive parameters are already good enough. For higher performance requirements, expect iterative tuning.
Which loop is tuned in ecmc versus drive depends on operation mode:
CSP: trajectory in ecmc, control loops in driveCSV: trajectory + position loop in ecmc, velocity/current loops in driveCSP_PC (dual position loop): position loop active in both ecmc and driveCST exists for some drives, but it is not a standard ecmc axis-object mode.
For full mode details, see CSV/CSP/CSP_PC modes.
Feedforward is used to push known motion demand directly into the control chain so the PID loops only need to correct residual error. In practice this reduces following error and improves response, especially during acceleration/deceleration.
Because the position trajectory is known, its derivatives are also known:
This means less corrective work for feedback loops and usually smoother, more accurate tracking.
Feedforward behavior is tightly coupled to scaling. If drive/encoder scaling is wrong, feedforward is applied wrong and PID tuning becomes misleading. For scaling details, see drive and encoder scaling.
The ecmc position controller chain can be read as:
e = setpoint - actual (actual value is mapped through encoder scaling).e using one of two parameter sets:e > tole < tol (fine positioning near target)Kff) scaled by drive scaling (num/denom).e < tol for configured time/cycles).Mode-specific behavior:
CSV: drive command is typically set to 0 at target.CSP_PC: ecmc PID can be frozen at target to avoid loop fighting near standstill.flowchart LR
SP["Position setpoint"] --> SUM["(-) error: e = setpoint - actual"]
ACT["Actual position"] --> ES["Encoder scale<br/>num / denom"] --> SUM
SUM --> SEL{"Error vs tolerance"}
SEL -->|e > tol| OPID["Outer PID set<br/>Kp, Ki, Kd"]
SEL -->|e < tol| IPID["Inner PID set<br/>Kp, Ki, Kd"]
OPID --> PSUM["(+)"]
IPID --> PSUM
TRJ["Known trajectory<br/>(position, velocity, acceleration)"] --> FF["Feedforward term"]
FF --> KFF["Kff"]
KFF --> PSUM
PSUM --> DB["Deadband / shaping / limits"]
DB --> DS["Drive scale<br/>num / denom"]
DS --> MODE["Mode behavior near target<br/>CSV: cmd -> 0<br/>CSP_PC: PID freeze"]
MODE --> PROC["Process / drive / mechanics"]
PROC --> ACT
AT["At-target condition:<br/>|e| < tol for configured time/cycles"] -.monitor.-> MODE
Bad tuning behavior is often caused by scaling or backlash issues, not PID gains.
Recommended quick check:
Kp=0, Ki=0, Kd=0 (keep Kff/feedforward active).These controller/feedforward parameters can be adjusted at runtime with the ecmc_cfg_tool cntrl app.
The position loop parameters are available through PVs. For many axes, pure P control is enough.
For runtime inspection and tuning of controller-related parameters via the ecmc command parser, use ecmc_cfg_tool, especially the dedicated controller app (cntrl).
Typical sequence:
mtn app is convenient for this).Kp until oscillation starts.Kp to about 40% of that oscillation threshold.Ki and Kd only when needed (for example backlash handling or CSP_PC).Sometimes an axis stops close to its requested position and the remaining error
does not decrease over time. This can happen when the position error is so small
that, after multiplication by Kp and conversion to the drive’s velocity
setpoint, the controller output is rounded or quantized to zero. With no
effective velocity command, proportional control alone cannot remove the
remaining error. If stall monitoring is enabled, this condition can also lead
to ERROR_MON_STALL.
Possible remedies are:
Kp so the remaining error produces a non-zero drive command.Ki so the residual error accumulates and is corrected. Increase
it carefully to avoid overshoot or oscillation.controller.Kp causes problems during the main part of a move,
keep that gain at a stable value and configure a higher
controller.inner.Kp for final positioning. Set controller.inner.tol
larger than monitoring.target.tolerance so the more aggressive inner gain
becomes active before the axis enters the at-target window. Tune the gain and
transition tolerance carefully to avoid oscillation near the switching point.controller.deadband.tol so the controller continues correcting closer
to the target.For a P-only controller in CSV mode with an integer velocity-setpoint entry, the
risk can be estimated from the configured values. At a position error e, the
raw drive command due to the P term is approximately:
raw_command = Kp * e * abs(drive.denominator / drive.numerator)
ecmc rounds this command to the nearest integer. Therefore, a magnitude below
0.5 raw counts becomes zero. To check the configuration, substitute
monitoring.target.tolerance for e and use the Kp that is active close to
the target (controller.inner.Kp when the error is inside
controller.inner.tol, otherwise controller.Kp):
Kp_near_target * monitoring.target.tolerance
* abs(drive.denominator / drive.numerator) >= 0.5
If this condition is false, the proportional output can already be zero at the edge of the at-target window. Equivalently, the smallest error that reliably produces a non-zero raw command is approximately:
minimum_correctable_error = 0.5 * abs(drive.numerator / drive.denominator)
/ Kp_near_target
Treat 0.5 as the mathematical rounding boundary; requiring at least one full
raw count gives a more conservative check. This calculation only detects
controller-output quantization. Friction, backlash, drive-side deadbands, output
limits, integral and derivative terms, floating-point setpoint entries, and
CSP_PC mode require a runtime check of the actual controller and raw drive
outputs.
The controller deadband and monitoring.target.tolerance serve different purposes:
the deadband determines when control action stops, while the monitoring
tolerance determines when the axis reports atTarget. If correction must
continue after atTarget becomes true, configure the controller deadband
tolerance smaller than the at-target tolerance. See the
controller YAML settings.
These control loops need to be tuned in the drive.
For EL70x1, see EL70x1 tuning. For other drives, consult the dedicated manual.
EL7062 provides autotune and can identify:
Kp/TiKp/TiSee EL7062.
Tuning systems with backlash can be difficult. Sometimes a D-part helps to reduce spikes in the centralized ecmc position loop controller output, and a small I is almost always needed to reach the final position. To conclude, the following is normally good:
Backlash diagnosis should start with identifying where the mechanical play is located:
Always evaluate backlash size against required positioning tolerance/accuracy before selecting compensation strategy.
If the system cannot be tuned, it may be necessary to run the system in open loop (with the option of using motor record retries). Note, this is not a good option for axes involved in a kinematic system.
The motor record backlash compensation fields can be used if needed. Basically they ensure that the system always approaches from the same direction by issuing two move commands:
target + BDST or shorter target - BDST (depending on which direction to approach from)For synchronized systems, see the constraints in the next section before enabling backlash compensation.
For synchronized systems, treat compensation features with extra care:
For setup patterns, see:
cntrl app.Most systems should run in closed loop. Open loop can be used as a fallback strategy for stepper systems together with motor-record retries.
Open-loop-with-retries workflow (high level):
RTRY, RMOD, RDBL, RDBD, URIP) and test carefully.For synchronized axes, follow the constraints in the synchronized-systems section above.
Detailed configuration examples: