Weird discontinuous movement — CoreXY

[Dabihu]

Bug Report

• Description: Weird not continuous movement at a specific speed and configuration
• Expected behaviour: Linear movement
• Actual behaviour: Discontinuous movement
• Steps to reproduce:
  Use default 1.1.6 configuration with these modification:
  #define COREXY
  #define DEFAULT_AXIS_STEPS_PER_UNIT { 100, 100, 4000, 500 }
  (M502 used, but EEPROM disabled, so M500 have no effect)

Example command:
G1 F1000 X100 Y100

More options:

• F in range: 849..1154
• Diagonal move (only one motor used (X or Y) to movement)
• CoreXY or CoreYX
• 1.1.6 or bugfix-1.1.x (Hash: 5a1f130)

F1000 video (bad movement): https://youtu.be/wIX8tTg1UyI
F1155 video (good movement): https://youtu.be/CGDx70LtVvE

Behavior is independent from motor driver. The step signal is discontinous in such settings.
Clicking noise in the good video caused by a faulty idler not by the motor.
Configuration.h.txt
Configuration_adv.h.txt

[coolio986]

I also have had this on version 1.1.3 - 1.1.5 (have not tried new versions) using CoreXY only. X/Y and E motors "pause" for a short period (100-200ms) then continue movement. I can confirm in the above post that it occurs with these conditions:

• F in range: 849..1154
• Diagonal move (only one motor used (X or Y) to movement)
• CoreXY or CoreYX

[tcm0116]

I've noticed something similar on my Cartesian machine. Long travel movements appear to be split into 2 or more movements with a slight pause between.

[thinkyhead]

@tcm0116 Does this only happen with bed leveling on? Or, does it not matter? Try adding a log line to the planner.buffer_line function so we can see whether the move is generating a single stepper block. Then, once we know whether it's a single stepper block, then we can check whether there's something in the stepper ISR that could lead to such a pause.

[coolio986]

I have bed leveling turned off. I will add a log line and report back.

[tcm0116]

For me, it was happening during printing with Bilinear leveling on during long travel movements. As such, I do think it was happening at the grid boundaries, so my issue may not be directly related to this one. However, there could be an underlying issue with the planner stitching together continuous movements in certain scenarios.

[AnHardt]

Is a display involved?

[bjarchi]

For me, it was happening during printing with Bilinear leveling on during
long travel movements. As such, I do think it was happening at the grid
boundaries, so my issue may not be directly related to this one. However,
there could be an underlying issue with the planner stitching together
continuous movements in certain scenarios.

I saw this happen for a bit after I had started using bilinear and it was quite frustrating because it showed up in my prints. I eventually realized that the problem was my z-jerk setting. At some point I had set z-jerk to 0.0 for testing and accidentally committed it with M500. With z-jerk at 0, the planner is forced to stop at any grid point where the sign of z-accel changes (at least I think that was the sufficient condition).

Resetting my z-jerk to a small non-zero value (0.3) restored continuous linear movement across grid point boundaries, even when the leveling direction changes.

[Dabihu]

Default configuration doesn't have display, eeprom or bed leveling. So nothing. But of course everything is connected, but not working.

[AnHardt]

What is the start position?

G1 F1000 X100 Y100

Is only then a 'one motor move' if the start position is somewhere with X==Y.
Is the start position in the videos constant?

[Dabihu]

Video is misleading, because it's move from X100 Y100 to X0 Y0.
In CoreXY or CoreYX setup diagonal (45 degree) move use only one motor.
Briefly dX=dY then X motor is used, dX=-dY then Y motor is used.
Start, end, length doesn't matter:
Start from X0 Y0
G1 F1000 X0 Y0 <- no move
G1 X20 <- good
G1 X120 Y100 <- bad
G1 X20 <- good
G1 X70 Y50 <- bad
G1 X0 Y0 <- BAD

New effect, if you move from X70 Y50 to X0 Y0 the movement is discontinuous. (Run twice the code)

[coolio986]

I do not have a screen attached when printing, I am not using bed leveling.
When printing at 15mm/s (900mm/m) doing a circle / square / rectangle/ anything, with 45deg infill this issue occurs for me.

The motor making the moves (X or Y, but not both), and E both pause for brief moments.

[tcm0116]

@thinkyhead my issue is definitely unrelated to this one. Mine is occurring at the bilinear grid boundaries as the printer is coming to a complete stop as it crosses the boundary. It seems to be a function of the amount of change in Z over the grid and the speed of the movement. In any case, I'll move my issue elsewhere.

[bjarchi]

@tcm0116 Did you see my earlier comment about checking your z-axis jerk setting?

my issue is definitely unrelated to this one. Mine is occurring at the bilinear grid boundaries as the printer is coming to a complete stop as it crosses the boundary. It seems to be a function of the amount of change in Z over the grid and the speed of the movement. In any case, I'll move my issue elsewhere.

This is exactly what I saw when I first set up bilinear leveling, due to accidentally having set z-jerk to zero.

Use M205 to check - 'advanced settings', z jerk will be labeled Zx.xx ...
and use M205 Zx.xx (ex M205 Z0.30) to set to a non-zero value

[bjarchi]

@coolio986 FWIW, this could occur with jerk set to 0 (or maybe even too low?) on any axis, if the planner is forced to stop due to motion constraints.

If you don't have EEPROM enabled it's not super likely - the values in configuration.h you posted look OK - but it could be getting set by a startup script or something - in which case it would still persist until the next machine restart or until it's reset by gcode. Might be worth using M205 to make sure something hasn't set one of your jerk values too low.

[Roxy-3D]

Does this issue happen when you cross over from one EEPROM version number to the next one? I'm seeing something similar except with the BL-Touch probes going wonkers and the nozzle crashing into the bed. Once I do a M502, M500, M501 everything is OK again.