Troubleshooting RMP Position Error and Limit Trips

Ryan Tanaka6 min read
Motion ControlOther ManufacturerTechnical Reference
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

RMP motion can show a growing position error or trip a configured limit while the drive reports its own position-deviation value or alarm. Start here: read the RMP commanded position, RMP actual position, and Axis::PositionErrorGet() in the same controller cycle. RMP Position Error is the difference between the commanded and actual positions inside the motion controller. It is not the drive's internal PID-loop position-deviation value.

Identify which position error you are reading

Symptom or reading Meaning and next check
Axis::PositionErrorGet() follows the gap between RMP command and feedback You are reading controller-level position error. Check the three values from one cycle.
A drive deviation PDO changes with RMP Position Error but does not match it exactly The two calculations are correlated but independent. Check scaling, sampling, and each device's command reference.
The drive raises a position-deviation alarm The drive's internal threshold has operated. Read its deviation and alarm settings; that alarm is not the RMP measurement.
Error changes after an immediate motion request is processed The active RMP command changed on a controller-cycle boundary. Check command arrival relative to that boundary.
Queued streaming motion does not change the error immediately The command was appended for later execution. Inspect buffer execution order rather than buffer capacity.

Some EtherCAT drives can expose their own position error through a PDO. That does not replace Axis::PositionErrorGet(). Both values represent command-following deviation, but one belongs to the motion controller and the other belongs to the drive's internal control system.

Check the controller-side calculation first

Capture these readings together:

  • RMP commanded position.
  • RMP actual position returned through the feedback path.
  • Axis::PositionErrorGet().

Compare the reported error with the commanded-to-actual difference. If the magnitude agrees, the API is reporting the RMP-level following error. If it does not, first check whether the three samples came from different cycles, whether the displayed values use different position units, and whether one value was rounded.

Do not begin by changing the drive's PID gains or its internal deviation limit. That wastes time when the mismatch is caused by asynchronous logging, unit conversion, or a controller command transition. Establish that the compared values share one sampling instant and one coordinate scale before changing control parameters.

If your application represents position in PUU, compare the RMP actual and commanded PUU values with the API result. Use the configured sign convention when checking polarity; use the error magnitude when assessing a trip threshold unless the limit function is deliberately directional.

Follow the command through one RMP cycle

RMP processes motion once per controller cycle. A motion request arriving between processing cycles does not load generated frames until the next cycle. The commanded position, and therefore Position Error, cannot change from that request before it is processed.

After processing, RMP sends the new commanded position over the EtherCAT network. For that cycle, the RMP commanded position is the command sent to the drive. This rules out a persistent interpretation in which Axis::PositionErrorGet() compares feedback against a distant endpoint stored elsewhere in the motion buffer.

Use this branch:

  • If an immediate request arrived before the processing point, expect its generated command to become active during that processing cycle.
  • If it arrived after the processing point, expect the old command and old error reference to remain until the following cycle.
  • If the motion was streamed and appended, expect it to become active later according to buffer execution, not merely when the application submitted it.

The buffer affects when an appended trajectory becomes active. It does not change the definition of Position Error. Buffer size alone is therefore not a sound basis for selecting the error limit.

Separate RMP error from drive deviation

Map the drive's internal position-deviation PDO when the drive supports that exchange, then trend it beside the RMP values. Compare shape and timing, not just one numeric sample.

  • If both errors rise during the same acceleration or load event, investigate following performance, feedback quality, mechanics, and command scaling.
  • If only the RMP error rises, check the feedback returned to RMP, controller-side scaling, coordinate transforms, and cycle-aligned acquisition.
  • If only the drive deviation rises, inspect the drive's internal command path, feedback processing, deviation configuration, and alarm record.
  • If the values have similar shapes but different magnitudes, compare units and reference points before tuning.

Yaskawa Sigma-7S drives, for example, have internal position-deviation settings that can produce alarms, as described in Sigma-7S EtherCAT Manual_SIEP_S800001_55G_6_0.pdf, Section 8.3.3. Those settings belong to the drive. A simultaneous drive alarm and RMP limit event can result from the same physical lag without proving that either device consumed the other's calculated error.

Set the limit from measured controller error

Base the RMP limit on controller-level following error and machine risk, not on motion-buffer capacity. Use RSISourceLIMIT_ERROR and Axis::ErrorLimitActionSet() within that controller-side context, then prove the behavior on the installed configuration.

  1. Record commanded position, actual position, and Axis::PositionErrorGet() from the same cycles during representative motion.
  2. Include the operating conditions that generate the largest legitimate lag: acceleration, deceleration, reversal, load changes, and the highest required production trajectory.
  3. Find the maximum normal error magnitude without converting it to a drive-internal deviation value.
  4. Determine the largest deviation the mechanics and process can tolerate before continued motion becomes unsafe or damages product.
  5. Select a threshold above demonstrated normal error but below the machine's unacceptable deviation. No fixed margin can be chosen from buffer size alone.
  6. Configure the required action with Axis::ErrorLimitActionSet(), then document the chosen units, sign treatment, and operating data used.

If normal error overlaps the unacceptable region, a threshold cannot separate normal operation from a fault. Correct tuning, sizing, load, mechanics, feedback, scaling, or trajectory demand before relaxing the limit.

Verify the resolving branch

  1. Run the same trajectory used to establish the normal-error envelope.
  2. Confirm that the RMP command observed for each cycle is the command transmitted to the drive after that cycle's processing.
  3. Submit an immediate request on each side of a processing boundary where your test equipment permits it. Confirm that the error reference changes only after RMP processes the request.
  4. Run appended streaming motion. Confirm that Position Error follows the active buffered frame, not the newest frame submitted by the application.
  5. Challenge the configured threshold under controlled conditions. Verify the selected limit action occurs at the intended controller-side error and that the drive's independent deviation protection still operates according to its configuration.

Do not validate the limit from a stationary test alone. Dynamic lag is normally highest where command rate, acceleration, load, compliance, or friction changes. Retain cycle-aligned traces so a later event can be classified as an RMP following-error trip, a drive deviation alarm, or both.

FAQ

How do I calculate RMP Position Error?

Read the RMP commanded and actual positions from the same controller cycle and compare their difference with Axis::PositionErrorGet(). Match the position units and account for the configured sign convention.

How do I tell whether the motion buffer changes Position Error?

Trend the active commanded position while submitting immediate and appended motion. The buffer changes when an appended command becomes active; it does not change Position Error's commanded-versus-actual definition.

How do I know when to escalate an RMP position error?

Stop changing limits and contact official support when cycle-aligned commanded position, actual position, and Axis::PositionErrorGet() do not reconcile after unit, timing, and scaling checks, or when the configured limit action does not follow the measured controller error. Provide the motion type, buffer behavior, EtherCAT traces, drive alarm record, and synchronized position captures.

Back to blog