Marlin: Hiccups in long moves (MKS_Base 1.2 and 1.4, Marlin 1.1 RC3, RC6 RC7 and RCBugfix)

[FHeilmann]

I am currently banging my head against an issue that I cannot seem to solve. I first realized it while jogging my new CoreXY machine.

Whenever I execute a long move (say I am at X0 Y0 and Execute a G1/G0 X300 Y300 at any speed) the printer will execute the move, but "trip" every now and then, where the movement stops for a split second and then continues.

The printer does not lose its position in this case, however, on my CoreXY, which is built to handle speeds over 150mm/s, this can cause the steppers to stall because of the aprupt stopping and resuming of the move, at which point the printer loses its position.

Here are my specs:

MKS_Base 1.2 and 1.4,
Marlin RC3 with simple LCD display and mesh leveling
Marlin RC6, tested with all combinations of with/without Full graphic LCD and Mesh Leveling
Marlin RC7 with the same modifications as RC6
Marlin RCBugFix, also with the same iterations.

RC3 on the MKS_Base 1.2 does it on my cheap chinese Prusa i3 knockoff and the CoreXY.
The other combinations were tested on the newer board, only on the CoreXY machine.

I am seriously at a loss right now. By my logic, it can't be a host/cable problem, since it is basically only one, long move. It happens at every speed, (i tested F3000 up to F12000), at virtually any stepper current (if extremely high or low, the steppers will simply stall sooner) with all the above mentioned software/hardware combos.

Could it be that this is an issue with MKS_Base boards in general? Or is it a "known" limitiation of the Arduino platform in general?

Bests

FH

[epatel]

Are you printing from SD card or over serial? With that high speed I would suspect serial could be drained and planner plan for stopping the motion. Oh, I just read that you also tested a long move. Maybe then it is the line splitting in MBL, maybe look at increasing the acceleration for Z?

[FHeilmann]

@epatel I am printing over serial, but, as I mentioned, the hiccups happen if I send a single command through the octoprint terminal. So there is only one command to be sent, and during the execution of that move the printer stutters.

edit: I should also mention that it happens regardless of whether one stepper or two steppers are part of the move.

So a G01 X200 Y200 will have the same issues as a G0/1 X200 or a G0/1 Y200

[epatel]

If you disable MBL?
What are your values for
DEFAULT_AXIS_STEPS_PER_UNIT
DEFAULT_MAX_FEEDRATE
DEFAULT_MAX_ACCELERATION

[epatel]

Maybe the DEFAULT_ZJERK (and the bugs we have been seeing) could also be in play here?

[FHeilmann]

Thanks for helping me out with this, here's the config I used for RCBugFix

#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 400, 154.4 }
#define DEFAULT_MAX_FEEDRATE { 300, 300, 25, 25 }
#define DEFAULT_MAX_ACCELERATION { 2500, 2500, 100, 10000 }
#define DEFAULT_ACCELERATION 2000

#define DEFAULT_XJERK 15.0
#define DEFAULT_YJERK 15.0
#define DEFAULT_ZJERK 0.4
#define DEFAULT_EJERK 5.0

The other RCs are configured with the same values where applicable. Also note that I only tested pure XY moves, I haven't tested if the same happens for Z

edit: The above values are for the CoreXY machine, here are the values currently used on my Prusa Knockoff:

#define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,398.2,154.5}
#define DEFAULT_MAX_FEEDRATE {150, 150, 10, 70}
#define DEFAULT_MAX_ACCELERATION {8000,8000,100,10000}
#define DEFAULT_ACCELERATION 3000
#define DEFAULT_RETRACT_ACCELERATION 3000
#define DEFAULT_TRAVEL_ACCELERATION 3000
#define DEFAULT_XYJERK 14.0
#define DEFAULT_ZJERK 0.4
#define DEFAULT_EJERK 5.0

[epatel]

If you have more or less the same steppers for all axis (E too) I think you can set DEFAULT_MAX_FEDERATE to { 300, 300, 60, 30 }
DEFAULT_MAX_ACCELERATION to { 2500, 2500, 500, 10000 }
DEFAULT_ZJERK to 3.0
making them more in line with the steps per unit.

Well, that is what I'd try...

NOTE: I changed the E max feedrate, keeping it lower so don't push too much into hotend to fast...

[FHeilmann]

Since the X and Y feedrates don't change (this is where the stops occur), I don't really think this would solve the issue. I went ahead and tried anyway on the prusa running RC3 and the problem persists.

[epatel]

Did you see this if you disable Mesh Bed Leveling (MBL)?
MBL will split moves on the grid boundaries so the movement can follow each grid square separately. This can cause slowdowns at the grid boundaries because a Z axis movement will be part of the movement. Thus the numbers need to be prepared for these movements, I think they usually are (though I think they can be increased some it seems).

...or maybe you just hit the speed limit of how many stepper pulses can be outputted at your max speed.

[FHeilmann]

I compiled Marlin without ABL or MBL and the problem remained.

Also the hiccups happen even if I slow the movement down significantly.

[epatel]

Oh. If you try any other Marlin version expect from the RCnn branches? But very strange as you say you see this on two machines.

[FHeilmann]

I'll try that if no other suggestions come up. As far as I know Marlin 1.0.x does not have CoreXY support and I don't want to tear down my prusa just to test this since it is the only reliable machine I have at the moment.

[epatel]

I fully understand.

As you see this on two machines I'd lean to a sw problem. But then I think others should have spotted this earlier too. Tried the devel-ubl branch? @Roxy-3D is using that I believe...

[Roxy-3D]

With the UBL code, if you do a G28 and then use PronterFace to tell Marlin to move the X or Y 100mm, you will see a 'stutter'. At first I thought the pause at the first mesh line was coming from the recursive nature of the original mesh_buffer_line(). I thought the first move was getting sent to the planner, but it was taking too much computation time before the 2nd move (across the next mesh cell) was getting sent.

I know this is not the case now. With the iterative mesh_buffer_line, there is only a tiny delay before the 2nd line is sent. And once you have some lines buffered up in the planner, you don't see the pause any more. I haven't looked (yet), but my guess is the planner is doing something to smooth the transition to the next line if the next line is in the queue. If it isn't in the queue, it is going to plan for a stop at the end of the line. I think that describes what I'm seeing.

But the important point is this... Both mesh_buffer_line() routines exhibit that behavior, and the logic they use to break up the longer line into moves across mesh cells is radically different. What ever is causing the issue is below the mesh_buffer_line() routine in the software stack.

[epatel]

But, he sees this even if MBL has been disabled. And at slow speeds...

[Roxy-3D]

Yes... But if MBL is disabled, the prepare_move_to_destination_cartesian() routine still calls down to the planner.buffer_line() routine. When I get a chance I'm going to look and see how the planner terminates a line. My guess (with the information I have right now) is if there is not another move in the queue it just plans for a deceleration and stop at the correct coordinate. But if there is a follow up line, it figures out how to round the corner and keep the speed up.

I don't know if that is true. I haven't crawled around in the planner very much. But right now, that seems like the place to look.

[FHeilmann]

Maybe to add the hiccups occur at random points along the move, not at the end. Sometimes they are in the middle of the move, sometimes towards the end. I'll try to get a video of it, maybe that helps more.

[FHeilmann]

edit2: Right Video Here! in all its unedited chaotic workbench heavy breathing glory :D
It's still processing though so if you want to view it inline it may take some time.

[epatel]

Same board? MK_Base 1.2 and 1.4? They use the A4982 stepper driver it seems. Feels like it could be timing issue. I wonder if this line might become removed by the C++ optimizer. https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/stepper.cpp#L498

Maybe you could try to disable optimization temporary with a couple of #pragmas

#pragma GCC push_options
#pragma GCC optimize ("O0")

    // For a minimum pulse time wait before stopping pulses
    #if STEP_PULSE_CYCLES > CYCLES_EATEN_BY_CODE
      while ((uint32_t)(TCNT0 - pulse_start) < STEP_PULSE_CYCLES - CYCLES_EATEN_BY_CODE) { /* nada */ }
    #endif

#pragma GCC pop_options

[FHeilmann]

Yes, A4982 steppers. I'll try your suggestions ASAP

[epatel]

Might also need to change the value on this line
https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Configuration_adv.h#L546

(used to set STEP_PULSE_CYCLES here https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/Conditionals_post.h#L707)

[FHeilmann]

The pragma stuff is not allowed inside functions FYI, one would have to pragma the whole function.

[epatel]

Ah. Maybe that can be tested? (disable optimization for the whole function? https://github.com/MarlinFirmware/Marlin/blob/RCBugFix/Marlin/stepper.cpp#L330-L683)

But anyway MINIMUM_STEPPER_PULSE needs to be set so the #if STEP_PULSE_CYCLES > CYCLES_EATEN_BY_CODE becomes true otherwise no delay will be added at all.

[FHeilmann]

Ok I compiled RCBugFix with MINIMUM_STEPPER_PULSE set to 1 and I don't see the stutters anymore!

As far as I can tell this fixes ist. Seems like all the optimizations that went into RCBugFix made the Meg2560 a "fast CPU" 😄 I can close the issue or leave it open until I had some more time to test.

[Roxy-3D]

or leave it open until I had some more time to test.

Let's leave it open. We want the compiler experts to know about it and consider if something needs to be done to keep us from getting too close to the edge again.

[boelle]

Who are the compiler experts? :-)