Acceleration is ignored with cloned axis

[gpstone]

Hello. I am stuck and need some help on a strange issue where GRBL is ignoring axis acceleration value only on certain sequential G0/G1 commands. When this happens at full speed/acceleration, the stepper motors physically skip steps (usually just on one axis) and in severe cases the machine jams if one of the cloned axis skips and the other tries to continue. The problem started after upgrading my machine to GRBL Mega from GRBL 1.1f (Uno). I have a gantry CNC with dual X axis motors and limit switches for gantry squaring.

Originally I thought the problem was due to acceleration or axis speed being set too high. However, I was able to rule this out by slowing down the acceleration to an extremely slow speed (i.e. 5mm/s^2) and with things slowed down I could clearly see and hear the missed deceleration/acceleration curves on the G0 commands. The steppers made a 'hard' stop/start 'clunk' instead of a gradual decel/accel.

I have ruled out hardware issues by disabling axis cloning in config.h and physically wiring both X axis controllers to the same step/dir pins. When I do this, the problem goes away (Although I lose self-squaring). Also, what points me to a config or software issue is even when I physically have the axis wired to the same X outputs but then re-enable cloning of the X axis in config.h (nothing is physically connected to those pins), the issue with missed acceleration comes back.

Everything else seems to be setup and working fine. Homing works for all 4 axis. Everything is moving in the right direction. I can run Gcode programs (Except for occasional skipped steps due to this issue). What's very frustrating is the issue only happens on certain types of G commands. It is very repeatable with the same command, but some other combinations will work just fine.

Example gcode where acceleration is ignored

G21G0X25Y25 //Misses decel/accel between this line and next
G21G0X755Y25

G21G0X-153.968Y93.316
G21G0X-124.362Y40.107 //Misses decel/accel between this line and next
G21G0X-41.833Y-17.287

Troubleshooting I have tried:

• $RST=* command (several times)
• Various $ machine settings: Step pulse timing, Arc tolerance, Junction deviation, verified all the Accel and step setting match for cloned axis, etc.
• Various config.h settings: moving the cloned 'X' axis to AXIS 4/5/6, trying different homing cycles, etc
• Downloading and using the latest edge build of Mega-5X. (Note: This issue was also happening with prior build when I first upgraded to Mega around March 2022, so it's not an edge issue)
• Full EEPROM wipe of Mega controller
• Replacing/Upgrading from a generic mega board to a genuine Arduino Mega
• Downloading latest build of UGS Sender

Any ideas on what I can try next would be greatly appreciated. Thank you in advance!

$I
[VER:1.2g.20220917:]
[AXS:4:XYZ]
[OPT:VNMGH,35,255,48]

$$
$0 = 10 (Step pulse time, microseconds)
$1 = 255 (Step idle delay, milliseconds)
$2 = 0 (Step pulse invert, mask)
$3 = 0 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 0 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 1 (Status report options, mask)
$11 = 0.010 (Junction deviation, millimeters)
$12 = 0.002 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 1 (Soft limits enable, boolean)
$21 = 0 (Hard limits enable, boolean)
$22 = 1 (Homing cycle enable, boolean)
$23 = 11 (Homing direction invert, mask)
$24 = 25.000 (Homing locate feed rate, mm/min)
$25 = 4000.000 (Homing search seek rate, mm/min)
$26 = 250 (Homing switch debounce delay, milliseconds)
$27 = 2.000 (Homing switch pull-off distance, millimeters)
$30 = 24000 (Maximum spindle speed, RPM)
$31 = 7200 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 80.120 (X-axis travel resolution, step/mm)
$101 = 80.120 (Y-axis travel resolution, step/mm)
$102 = 161.900 (Z-axis travel resolution, step/mm)
$103 = 80.120
$110 = 6000.000 (X-axis maximum rate, mm/min)
$111 = 6000.000 (Y-axis maximum rate, mm/min)
$112 = 3000.000 (Z-axis maximum rate, mm/min)
$113 = 6000.000
$120 = 5.000 (X-axis acceleration, mm/sec^2)
$121 = 5.000 (Y-axis acceleration, mm/sec^2)
$122 = 5.000 (Z-axis acceleration, mm/sec^2)
$123 = 5.000
$130 = 790.000 (X-axis maximum travel, millimeters)
$131 = 648.000 (Y-axis maximum travel, millimeters)
$132 = 200.000 (Z-axis maximum travel, millimeters)
$133 = 790.000

Config file:
Config.txt

[fra589]

Hi @gpstone,

What you are describing seems very strange to me because no one noticed it before you!
Personally, I don't use cloned axes, I programmed the cloning of axes to help others because it was requested by several users. And I know that many use it on their machine without having encountered this problem.
The section of the code that calculates the accelerations is one of the most complicated in Grbl... I just reread this code without seeing clearly where your problem may come from.
I will have to find materials to make a demonstrative model of this problem to try to reproduce it. It is very likely to take some time. In the meantime, if other readers of this subject could come and testify if they encounter the same problem, and what their configuration is, it could save time!

@++;
Gauthier.

[RaphaelDives]

Hey there,
I‘m using cloned axis on both X and Y on my MPCNC, I never had issues as described…
So I know that it can work. 😉
I can post my conf if necessary, but to be honest I can‘t see an error in your $$ output.
I once had a similar thing, when I set my steps/mm to high, the motors would just start and jam with fast moves, but I think in this case my Arduino was to slow to handle that… But that’s not the case in your config.
Strange thing, that „normal“ grbl would run…
Good luck! 😄
Raphael

(Forget about the axis thing - I was wrong there...)

[RaphaelDives]

But strange thing... this is my working (!) config.h....
I always thought that A_AXIS_LINEAR should be the real number of linear axis... but it's written different in the wiki...

#define N_AXIS 6        // Number of axes (3 to 6)
#define N_AXIS_LINEAR 3 // Number of linears axis, must be <= N_AXIS

// Axis indexing and names
#define AXIS_1 0        // Axis indexing value. Must start with 0 and be continuous.
#define AXIS_1_NAME 'X' // Axis names must be in X, Y, Z, A, B, C, U, V, W, D, E & H.
#define AXIS_2 1
#define AXIS_2_NAME 'Y'
#define AXIS_3 2
#define AXIS_3_NAME 'Z'
#if N_AXIS <3
  #error "N_AXIS must be >= 3. N_AXIS < 3 is not implemented."
#endif
#if N_AXIS > 3
  #define AXIS_4 3
  #define AXIS_4_NAME 'X' // Letter of axis number 4
#endif
#if N_AXIS > 4
  #define AXIS_5 4
  #define AXIS_5_NAME 'Y' // Letter of axis number 5
#endif
#if N_AXIS > 5
  #define AXIS_6 5
  #define AXIS_6_NAME 'A' // Letter of axis number 6
#endif
#if N_AXIS > 6
  #error "N_AXIS must be <= 6. N_AXIS > 6 is not implemented."
#endif

[fra589]

Hi Raphael,

Thanks for your post.

You are right, I wrote several times that N_AXIS_LINEAR should define the real number of linear axes.
In fact, this definition is only used when the units are defined in inches (GCode G20).
When working in inches, grbl-Mega-5X performs a loop that multiplies the given values ​​by 25.40 for all axes whose number is less than or equal to N_AXIS_LINEAR.
Inside gcode.c:

  // Pre-convert XYZ coordinate values ​​to millimeters, if applicable.
  uint8_t idx;
  if (gc_block.modal.units == UNITS_MODE_INCCHES) {
    #if N_AXIS > 3
      for (idx=0; idx<N_AXIS_LINEAR; idx++) { // Axes indices are consistent, so loop may be used.
    #else
      for (idx=0; idx<N_AXIS; idx++) { // Axes indices are consistent, so loop may be used.
    #endif
      if (bit_istrue(axis_dwords,bit(idx)) ) {
        gc_block.values.xyz[idx] *= MM_PER_INCH;
      }
    }
  }

In your case, if you ever decide to work with inch units, you will probably have a problem with the clones of X and Y. You must correct and define: #define N_AXIS_LINEAR 5.

@++;
Gauthier.

[fra589]

Hi @gpstone,

For me to better understand this problem, can you make a video of your machine that shows the problematic acceleration behavior?

@++;
Gauthier.

[gpstone]

Hi @fra589

Thanks you for taking the time to investigate this. I have made a video showing 5 tests.
https://www.youtube.com/watch?v=VNCTos-fsoo

G Code used for all tests:
[Start position at X0, Y0]

G21G0X25Y25 
G21G0X755Y25

Test 1: (This is my 'normal' machine setup)

• Cloned X axis in config.h (as shared above)
• X axis wired to pins A0/A1, Cloned X axis wired to D26/D28
• Accelerations set to 100mm/sec^2
  Result: Failed - No deceleration between G code lines. Machine locks up due to full speed acceleration change

Test 2:

• Cloned X axis in config.h (Same as Test 1)
• X axis wired to pins A0/A1, Cloned X axis ALSO wired to A0/A1, nothing connected to D26/D28
• Accelerations set to 100mm/sec^2
  Result: Same as Test 1 - Fail - No deceleration. Machine locks up.

Test 3:

• No cloning in config.h - Only 3 axis defined
• X axis wired to pins A0/A1, Cloned X axis ALSO wired to A0/A1, nothing connected to D26/D28
• Accelerations set to 100mm/sec^2
  Result: SUCCESS! Move works flawlessly. Machine decelerated/accelerated between G code lines.
  However, in this configuration I lose auto square homing function

Test 4:

• Same configuration as Test 1. Cloned X axis/Wired separately
• Accelerations set to 1mm/sec^2
  Result: No deceleration at corner. Listen to audio carefully at 0:28 and you can hear the 'hard' change in acceleration between G code lines.

Test 5:

• Same configuration at Test 3. No software cloning enabled. Both X axis are wired to same output pins.
• Accelerations set to 1mm/sec^2
  Result: Just as in test 3, the machine decelerated/accelerated between G code lines.

**Bonus troubleshooting test, done after creating the video:
I performed a slightly different version of Test 2. I still kept both X axis motors physically wired to the same A0/A1 pins. But this time in the config.h I 'virtually' cloned the Y axis instead of X. Like in Test 2 nothing was connected to pins D26/D28, this was just a software config change.

`#define N_AXIS 4 // Number of axes (3 to 6)
#define N_AXIS_LINEAR 3 // Number of linears axis, must be <= N_AXIS

// Axis indexing and names
#define AXIS_1 0 // Axis indexing value. Must start with 0 and be continuous.
#define AXIS_1_NAME 'X' // Axis names must be in X, Y, Z, A, B, C, U, V, W, D, E & H.
#define AXIS_2 1
#define AXIS_2_NAME 'Y'
#define AXIS_3 2
#define AXIS_3_NAME 'Z'
#if N_AXIS <3
#error "N_AXIS must be >= 3. N_AXIS < 3 is not implemented."
#endif
#if N_AXIS > 3
#define AXIS_4 3
#define AXIS_4_NAME 'Y' // Letter of axis number 4
#endif`

At first I thought the problem was fixed because my original g code commands worked. However upon further testing, I flipped the X and Y coordinates in my test g code and the problem came back. So it seems to be a function of the cloned axis being commanded to move a certain way.

[fra589]

Hi @gpstone,

Thanks for your detailed video! I have a better idea of ​​what can happen...
However, I have seen this type of problem before, and it can come from many different causes. I don't think it's a bug in Grbl. It will therefore be necessary to do additional tests to understand.
In most of the cases where I encountered this behavior on machines, it was about problems:

• Mechanical "hard points" on the slides of the axes which can cause a significant effort which can block the stepper motor,
• excessive acceleration which leads to the need for a strong torque on the motors,
• too high a maximum speed which generates greater effort on the guide rails,
• too high a speed which causes the processor's maximum calculation speed to be exceeded (this does not seem to be the case with you, but...),
• a current adjustment fault in the stepper motor drivers,
• a faulty stepper motor driver,
• a faulty Arduino and/or RAMPS board,
  -?...

The audio change you hear at 28 seconds in the third test is normal. It is not a modification of the acceleration but a change of the frequency of control of the stepping motors which is activated by the algorithm "DAPTIVE_MULTI_AXIS_STEP_SMOOTHING" to adapt to the differences in speed. Moreover, on the image, there is no sudden change in speed.

Here are the additional tests that would be interesting to perform:

• Disable the DAPTIVE_MULTI_AXIS_STEP_SMOOTHING in config.h by add comment on the line number 471
  //#define ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING // Default enabled. Comment to disable.
• In your video, I notice that the spindle motor is on the right, on the side that stops its movement... Can you do a test by placing the motor on the other side, on the left, and see if it's still the right axis which stops? This would require a greater effort due to the weight of the spindle, I don't really believe in it, but...

For the rest of the tests, you should place the pin in the center to avoid mass différence of both sides and see movements of both sides in the same inertial condition.

• Can you redo test number 1 by reversing the connection of the motors (from A0/A1 to D26/D28 and vice versa)? If the axis that stops changes sides, this may be due to a problem with the driver of the stepper motor concerned.
  In this case, without changing the connections again, swap the drivers connected to A0/A1 and D26/D28 to see if the problem is with the driver or the Arduino/RAMPS board.
• Finally, following your last message concerning cloning on the Y axis, try to connect the motors to the 2 cloned Y outputs...

After that, we will have new lines of thought.

@++;
Gauthier.

[gpstone]

Hi @fra589

I have tried disabling Adaptive Multi Axis Smoothing, and it didn't seem to make a difference to the tests. I also tried the motions with the spindle at different locations including center and left sides as well as the far end of the X axis, which all gave the same results as the original test video. In previous troubleshooting I had ruled out a stepper driver problem by swapping drives and then swapping output pins. Also I had previously replaced the arduino board. I am not using a RAMPS board, my setup is discrete stepper drivers connected to an arduino breakout board.

What leads me to suspect this is a software bug is that in my original test video, the only difference between Test 2 and Test 3 was a change in config.h. The machine was wired and physically configured exactly the same in both tests. Only in Test 2 I had enabled a cloned 4th axis (X) with nothing connected to it. If it were a mechanical, electrical, or controller problem I would expect it to happen in both tests, but it only happened on Test 2.

I am currently working on troubleshooting what combinations of gcode commands causes the problem. It seems to be very specific to a gcode sequence where both axis are commanded to move to a location together, and the next command moves the cloned axis. In these cases, the cloned axis does not decelerate for the corner.

[fra589]

Hi @gpstone,

Any news about your problem?
Do you made additional tests suggested in my precedent reply?

@++;
Gauthier.

[gpstone]

After a lot of testing and troubleshooting, I am convinced the problem is software related. As mentioned in my previous posts the problem only appears when there is at least one cloned axis enabled in config.h even when there have been no hardware changes. For my testing I did not have any physical motor connected to the cloned axis, I was simply enabling/disabling the setting in config.h. All other machine settings remained the same (steps/mm, max rate, accelerations, etc.)

It does not appear to be related to the number of axis enabled: #define N_AXIS 4 and #define AXIS_4_NAME 'A' does not create a problem, but as soon as #define N_AXIS 4 and #define AXIS_4_NAME 'X' (Or even 'Y' or 'Z') the problem appears.

The problem appeared any time both axis were commanded to move together, and then in the next line of g-code the cloned axis was commanded to continue moving in the same direction on it's own. It did not seem to matter the direction of the initial move, and the axis could be moving different directions (i.e. X moving positive, Y moving negative). But what was important is the cloned axis had to continue in the same direction.

For example (X is the cloned axis):
G90G0X0Y0;G0X100Y100;G0X150Y100 <--Problematic
G90G0X0Y0;G0X100Y100;G0X-150Y100 <--Not problematic

The scale of the move didn't seem to be a significant factor. There was a slight difference in how 'hard' the change in acceleration related to scale of motion, which seemed to be simply related to how fast the machine was traveling because it obviously had more time to accelerate on longer moves.
G90G0X0Y0;G0X10Y10;G0X15Y10 <--Problematic
G90G0X0Y0;G0X200Y200;G0X250Y200 <--Problematic

If the non-cloned axis was also commanded to move in the second gcode line, the problem seemed to depend on how far and which direction.
Example:
G90G0X0Y0;G0X100Y100;G0X150Y50 <-- Not problematic
G90G0X0Y0;G0X100Y100;G0X150Y120 <-- Problematic
G90G0X0Y0;G0X100Y100;G0X150Y80 <-- Problematic
G90G0X0Y0;G0X100Y100;G0X150Y200 <-- Problematic

I created the attached graphs to illustrate what was going on. These graphs use my original problematic test gcode (G90G0X0Y0;G0X100Y100;G0X150Y100) and were created by plotting the verbose output from USG Sender. The only difference (hardware or software) between the two graphs was whether or not cloned 'X' axis was enabled in config.h using N_AXIS and AXIS_4_NAME.
On the 'No Cloned Axis' graph, we see both X and Y gradually accelerate and decelerate together to the X100Y100 location, and then X gradually accelerates to X150. This is what I would describe as expected behavior.
On the 'With Cloned X' graph, we see both X and Y accelerate together, but then at X100Y100, the Y axis is suddenly stopped at Y100 with no deceleration, and the X axis continues accelerating towards X150. Based on my understanding of how planner is designed to work, I believe this is unexpected behavior.

[fra589]

Hi @gpstone,

Many thanks for these detailed tests.
It seems effectively to be a software problem...

The output graphs of UGS should allow me to focus the search for the cause of the problem in parts of the code on which I have worked relatively little and which come from the original versions of Grbl.
The sources corresponding to this behavior are in planner.c and more probably in stepper.c which performs a recalculation and an adjustment of the speeds (by a calculation of the delays of the time interrupts) according with the Bresenham algorithm...

It's a very deep and very complicated part of the code (due to the high hardware optimisation of Grbl) and it may take me a little time to understand what's going on. Be patient, I'll work on fixing it!

@++;
Gauthier.