After the defective step-and-direction signal path is repaired, slow jog motion should be smooth, stop when the jog command clears, and complete without a following error. Because this axis has no encoder, the alarm primarily reports disagreement inside the commanded motion chain; it does not prove that LinuxCNC measured physical motor lag.
Common Wrong Turns
Several plausible repairs fail because they do not divide the system at a useful electrical or logical boundary.
| Attempt | Why it does not settle the diagnosis | Better test |
|---|---|---|
Reseat the Mesa 5i25
|
Reseating may correct a poor host connection, but no change does not distinguish the host card, 7i76, field wiring, or configuration. |
Compare pulse and direction signals at successive points in the Y-axis path. |
| Judge wiring by appearance | A conductor can look intact while presenting an intermittent open, weak termination, lost reference, or noise-sensitive connection. | Perform powered-down continuity and terminal-retention checks, followed by an energized waveform test. |
| Replace the motor or driver immediately | The driver-input swap already points away from the motor and driver if the same logical axis remains faulty after the exchange. | Document exactly which connections moved and whether the symptom followed the physical hardware, output channel, or logical Y assignment. |
| Increase the following-error limit | A wider limit can postpone the shutdown while leaving jerky motion and continued travel unresolved. | Find why commanded and reported positions diverge before changing any limit. |
Current, Timing, and Position Error
The number that matters is the difference between the trajectory position requested by the motion controller and the position returned to that controller by the step-generation chain. When that difference exceeds the configured following-error limit, LinuxCNC stops motion and reports following error.
With an encoder, returned position can represent measured mechanical position. This installation has no encoders, so the controller cannot directly see a stalled motor, slipping coupling, or lost mechanical steps. Its feedback is generated within the command system. A following error therefore directs attention first to command updates, step-generation state, channel assignment, host-interface communication, or related configuration.
The jerky slow jog and motion continuing after button release add a timing clue. The axis is either still receiving a motion request, receiving unwanted step pulses, or processing delayed command changes. This is pulse timing and state propagation, not proof of excess motor current or thermal overload. Motor current still matters for torque and heating, but changing it cannot correct a jog command that remains active or a corrupt pulse train.
| Quantity or state | Expected observation | Where to read it |
|---|---|---|
| Jog input state | Changes immediately when the button is pressed and released | LinuxCNC live input display or signal monitor |
| Commanded axis velocity | Returns to zero according to the configured deceleration | LinuxCNC motion display or trace |
| Commanded versus returned position | Difference remains below the configured limit | LinuxCNC live motion signals and configuration |
| Step pulse train | Regular pulses while jogging; no pulses after motion has stopped | Oscilloscope or logic analyzer at the 7i76 output and driver input |
| Direction state | Stable for a one-direction jog | Same two measurement points |
| Driver current and supply condition | Within the driver and motor ratings | Driver settings, power measurements, and manufacturer documentation |
Fault-Boundary Decisions
The earlier input exchange is useful only when its boundary is explicit. If complete driver inputs were exchanged and the fault stayed with logical Y, the motor and driver are unlikely causes. The remaining path includes the Y command, LinuxCNC signal routing, step generator, 5i25-to-7i76 interface, physical output channel, connector, and cable up to the exchange point.
An axis-specific symptom makes a shared host failure less likely than a Y-specific channel, assignment, input, or conductor fault. It does not clear the computer or 5i25: a configuration error or one channel in the signal chain can affect only Y.
Use two controlled comparisons. First compare Y with a working axis under the same slow-jog condition. Then move one boundary at a time. If malformed signaling remains on one physical 7i76 output after logical assignments are exchanged, suspect that output channel or its immediate interface. If the defect follows the logical Y assignment to another known-good output, inspect LinuxCNC routing, jog state, motion settings, and step-generator configuration.
Isolation Procedure
- Record the current configuration and label every step, direction, common, and reference conductor before moving connections. Remove power before changing terminals; an incorrect live reconnection can damage an output or driver input.
- Open the LinuxCNC live signal display. Press and release the Y slow-jog control while watching the raw jog input and commanded velocity. If the input remains asserted, repair the button, input wiring, or input mapping. If the input clears but commanded velocity continues, trace the command logic and motion state.
- Compare commanded and returned Y position during a short jog. Note which value freezes, jumps, or continues changing before the
following error. Read the active trip limit from the machine configuration rather than estimating it. - Probe step and direction at the Y driver input. Compare their amplitude, reference, edge quality, and pulse pattern with a working axis. After commanded motion reaches zero, step pulses must cease.
- Repeat the measurement at the corresponding
7i76terminals. A clean signal at the board but a defective signal at the driver locates the fault in the connector, cable, reference conductor, shielding arrangement, or termination between those points. - If the waveform is already defective at the
7i76, exchange logical assignments or physical output channels using the documented configuration method. Change one item, restart as required by the configuration, and repeat the identical jog test. - If the defect follows logical Y, review duplicated assignments, polarity, scaling, acceleration, velocity, jog input mapping, and step-generation routing. If it stays with one physical output, inspect that
7i76channel and the interface to the5i25. - Only after axis-level tests are inconclusive, test the computer’s real-time performance and host-card communication. Look for timing or communication diagnostics during the same motion that produces the alarm.
Corrective Actions by Test Result
| Test result | Corrective action |
|---|---|
| Jog input stays active after release | Repair the input device or field wiring, then correct the LinuxCNC input mapping if the physical input changes but the mapped state does not. |
| Command continues with the input cleared | Correct command logic, duplicated jog sources, or motion-state handling. |
Clean output at 7i76, poor signal at driver |
Reterminate or replace the affected conductors and restore the required signal reference. Route signal wiring away from noise sources where practical. |
| Fault follows logical Y to another output | Correct the Y-axis configuration, signal routing, scaling, or step-generator assignment. |
| Fault remains on one physical output | Confirm connector integrity and channel configuration, then treat the 7i76 output or its interface as the suspect hardware. |
| Multiple axes show timing disturbances | Investigate computer real-time latency, host loading, and 5i25 communication before replacing an axis component. |
Verification and Recurring Pitfalls
Run verification with the machine in a condition where unexpected axis travel cannot cause a collision. Start with repeated short slow-speed jogs in both directions. Confirm that the input clears, commanded velocity returns to zero, pulses stop, and the position difference stays below its configured limit.
Extend the test to longer jogs and normal operating speeds only after the short tests pass. Repeat from a cold start and after the machine has operated long enough to expose an intermittent connector or temperature-sensitive channel. A repair is not verified merely because the alarm disappears; motion must also be smooth and stop predictably.
Avoid compensating for the symptom with a wider following-error limit, lower acceleration, or higher driver current unless measurements identify the corresponding limit as the cause. Those changes can hide a signal fault, reduce performance, or add motor and driver heat. Preserve a record of channel swaps so that a logical-axis fault is not confused with a fault that follows physical hardware.
FAQ
Can I get a following error without an encoder?
Yes. LinuxCNC can compare commanded position with internally returned step-generation position. Without an encoder, the alarm does not confirm actual table position or prove that the motor lost steps.
Does a following error mean the stepper motor is overloaded?
No. Motor overload can cause physical position loss, but an encoderless controller cannot directly measure it. Check command state, internal position difference, and step-and-direction waveforms first.
Can I raise the following-error limit to keep the axis running?
A higher limit may delay shutdown but will not correct jerky motion or travel after jog release. Read the active limit and diagnose why the position difference crosses it.
Does swapping driver inputs prove the Mesa board is bad?
No. If the fault stays with logical Y, the swap clears only the hardware downstream of the exchange point. Channel reassignment and waveform measurements separate configuration, wiring, 7i76 output, and 5i25 interface faults.
Can I continue troubleshooting after one physical output fails comparison?
Stop machine operation if step pulses persist after the command reaches zero, signal levels are abnormal, or controlled swaps isolate the defect to a board channel. Record the configuration, measurements, and swap results, then escalate to official Mesa or LinuxCNC support; request hardware replacement guidance only after they review those results.