missing steps

[ozntyr]

A few years ago, I started a CNC project using an ESP32. Initially, I started developing my own G-Code interpreter but later found about and integrated it with GRBL_ESP32. I also discovered FluidNC after a while but decided not to migrate. While the system had some minor issues, they didn’t significantly affect the output. However, I recently noticed major defects in the produced items. Upon investigation, I found that the machine occasionally misses a single step during execution.

Previously, I assumed that the slight discrepancy on the screen (e.g., showing 0.03 instead of 0.0) wasn't really important. However, I’ve now determined that this issue can accumulate, resulting in errors of up to a millimeter in certain cases.

I’ve conducted detailed tests and identified scenarios where the issue occurs. While I have some theories about the root cause, I’d like to know if this is a known problem and whether there are any existing solutions or suggestions for addressing it.

Test Cases and Observations:

Case 1: Single G-code Line Execution

G-code: "G1 G91 F100 X10", wait for GRBL state to return to idle, then "G0 G90 X0".
Result: The machine returns to the exact zero point. No issues observed regardless of feed rate (F value).

Case 2: Two Consecutive "Low" Feed Rate G-code Lines

G-code: Two lines of "G1 G91 F100 X10" executed without waiting in between, then wait for GRBL state to return to idle and "G0 G90 X0".
Result: The machine still returns to the exact zero point. No issues observed.

Case 3: Higher Feed Rate with Two G-code Lines

G-code: Two lines of "G1 G91 F500 X10" executed without waiting, then wait for GRBL state to return to idle and "G0 G90 X0".
Result: The machine misses a single step during the forward movement, causing it to return to 0.003 instead of zero. The issue begins occurring at feed rates (F) exceeding 250.

Case 4: Multiple G-code Lines at High Feed Rate

G-code: Multiple lines of "G1 G91 F500 X10" executed without waiting, then wait for GRBL state to return to idle and "G0 G90 X0".
Result: The machine misses one step for each line after the first, accumulating errors.

Case 5: Recovery Behavior

If an axis has missing steps, performing a soft reset followed by "G0 G90 X0 Y0 Z0" correctly returns the machine to zero. Both the planner position and physical axes synchronize, and the axes move as expected.

Additional Notes:

I’ve not modified the planner or stepper calculation code. The only changes I made were adding new motors, spindles, and custom G/M codes. I also removed some unused Wi-Fi and Bluetooth functionality, which shouldn’t affect planner calculations.

From my investigation:
-The planner appears to calculate movements correctly at the start.
-The stepper timer executes movements as intended initially.
-At some point, the stepper’s calculations appear to diverge, corrupting the data stored in the planner.
-Performing a soft reset seems to synchronize the planner and machine positions, temporarily resolving the issue.

I’m not expecting a full solution, but if this rings a bell for anyone or this happens to be a known issue or there are typical causes for step inaccuracies at higher feed rates, I’d appreciate any information or tips on debugging this further.

Thanks in advance for any thoughts!
Oz

[MitchBradley]

We aren't supporting Grbl_Esp32 so you are on your own. If you were using FluidNC, I would investigate the problem. We don't have time to support code that was superseded a long time ago.

[ozntyr]

I just found out what the cause was. I forgot that, in the very early stages, I tried to do something stupid with the axes but later decided it was... well... stupid. 😄 I thought I had removed everything related to it, but apparently, I missed a part where I modified an if statement that checks the step count. For some reason, it doesn’t cause any problems at lower feed rates and didn’t cause any noticeable issues until recently.