[bugfix-1.1.x] Motors are clacking and clicking after G29. Without G29 they are silent

[ikarisan]

I am using a MKS Gen1.4 board together with three TMC2130 drivers for X, Y and E.

Every time I print, the motors are starting to clack all the time. First I thought I am too close to the bed but even without filament / extruding it clicks and clacks during the print. Now I am sure that not the extruder motor is the problem but the automatic (bilinear) bed leveling causes this problem!

Use the attached GCODE files to comprehend:

clicktest.gcode.txt clicktest_withG29.gcode.txt

The first GCODE file (clicktest.gcode) simply homes all axis and moves the extruder around the bed. You must have at least a 200x200 bed (or change the coordinates!). These movements are very silent, as expected!

The second GCODE file (clicktest_withG29.gcode) homes all axis, runs an auto leveling process (G29) and moves the extruder around the bed. These movements are filled with clicking and clacking all the time.

The same happens if I recall the last leveling data with "M420 S1"!

And this is reproducible every time!

I made two YT videos. The first one shows the movements without G29 and the second one after G29.

Silent moves: https://youtu.be/TcR7T8kjJM4 Clicking moves: https://youtu.be/sVny98SFDNc

Here is another video, made when I thought the extruder was the problem: https://www.youtube.com/watch?v=LmIRYhW3xMk

My current configuration: Marlin_Configuration.zip

[thinkyhead]

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see if we fixed this issue. If the problem has been solved then we can close it. If you still see the bad behavior we should investigate further.

[VanessaE]

@thinkyhead I wonder if this is the same issue we talked about elsewhere, where low acceleration causes stuttering when bed leveling is enabled?

[thinkyhead]

I recall seeing something like this at the beginning of a print last time I used ABL, but it seemed to go away after the first layer.

Since @ikarisan is using ABL this issue might be resolved by disabling SEGMENT_LEVELED_MOVES. That seemed to work for UBL, but the author of that feature didn't look any further into the issue. I'd like to look into it closer if that ends up resolving this.

Also it may be worth testing whether enabling or disabling Z Fade (M420 Z) has any effect.

[VanessaE]

I dunno what he's using, but I can confirm that disabling segmented moves fixes the majority of the stuttering for bilinear leveling, though straight moves are still being bisected, regardless of direction, length, starting position, or axis.

[thinkyhead]

straight moves are still being bisected

A single move from X0 to X100 will stop in the middle?

[VanessaE]

Something like that, yes. It accelerates from its starting point, moves to X=50, decelerating as it gets there, immediately accelerates again, and continues to X=100, as if I had issued G1 X0 / G1 X50 / G1 X100. Even happens during G29 as it moves from point to point.

I'm having trouble reproducing that effect reliably, though.

[VanessaE]

Here's something that may be reliable: whatever gcode the test pattern generator is creating, if you start a print, just abort it after a few lines, and some axis moves from then on will behave as if bisected. The effect seems to favor moves that have some pause between them, so G1 X0<0x0a>G1 X100 will make a bisected move as it goes to X=0, and a singular move back to X=100.

Also, X/Y may start skipping steps and stalling out as it's printing the numbers at the end. Not sure why it's doing that.

This is bugfix-1.1.x, commit 9c658906, by the way (I jumped over after the LA1.5 PR went in, kinda anticipating your request :wink:). EDIT: switched back to @Sebastianv650's fork, and the skipping/stalling doesn't happen there. Incidentally, I used the usual commit/format-patch/am trio to port my config from there over to bugfix-1.1.x before doing any tests, so the two trees are, for all practical purposes, configured identically, save for segmented moves.

Configs for bugfix-1.1.x: Configs-9c65890.zip G-code where I saw the problem: kfactor.gcode.zip

[thinkyhead]

Are you seeing the same issue I describe in #9360 ?

[VanessaE]

With the g-code you presented there, the first four sides of the square move fine, the next three sides are "drawn" with two distinct segments apiece, the fourth of that set is done in one move, then the last four sides have one long move and one short move each.

[thinkyhead]

Try adding M420 S1 after the G28 and see if it worsens.

[VanessaE]

Ultimately, a little worse - more of the moves are segmented then, but the division is not even, each side is one long move and one very short move.

[thinkyhead]

The issue there is that the last move in the planner is always detached and done as a separate move instead of being chained to its predecessor.

[VanessaE]

Now, if I load the kfactor gcode linked earlier, add in that M420 S1 right after home, I don't see any obvious difference in how it prints, but as I'm using Sebastianv650 fork at the moment, and SEGMENT_LEVELED_MOVES is enabled here, I can't say if it should behave differently or not.

[thinkyhead]

The Kfactor code probably has no M400s in it.

[VanessaE]

ok, fair enough

[thinkyhead]

M400 does a "synchronization" between moves, so it makes the previous move the last one in the buffer, and so it is the detached one.

This particular last-move-not-joined issue is in all versions of Marlin, btw.

[VanessaE]

Ah, I understand. Now, with SEGMENT_LEVELED_MOVES turned off (which would be appropriate here since my bed is nice and flat anyway), the stalling/skipping on X/Y that happens during short moves when in that mode is a showstopper. :frowning_face:

[thinkyhead]

Now, with SEGMENT_LEVELED_MOVES turned off … the stalling/skipping … that happens … when in that mode is a showstopper.

I'm having trouble parsing this. When SEGMENT_LEVELED_MOVES is off? Or "in that mode" (on)?

[VanessaE]

Sorry, I blame lack of coffee. :smile: With SEGMENT_LEVELED_MOVES disabled/commented out, I get stalls/skips.

[thinkyhead]

Hmm! That is weird, alright.

switched back to @Sebastianv650's fork, and the skipping/stalling doesn't happen there

Well clearly we should compare his to ours, try putting a few things the way they are in his branch, and see if any of those reversions fixes the issue.

[VanessaE]

I just did. I can reproduce the stalling in both branches by just commenting out that setting. As of right now, my config should be identical between his branch and upstream/bugfix-1.1.x, aside from that setting. Sorry if I'm being confusing.

[thinkyhead]

Oh, so it's just a setting. Poo.

[VanessaE]

Yup.

[thinkyhead]

So, stalling is noticeable during a normal G-code print, or just when doing synthetic moves?

[VanessaE]

Noticeable (actually quite severe) during regular print moves e.g. the numbers at the end of the K-factor calibration pattern, but I can't be sure if it happens during...er... what do you mean by synthetic moves?

[thinkyhead]

Typed-in moves for testing purposes.

[AnHardt]

@thinkyhead What we see in your test squares is a not joined last move/segment regardless of the SEGMENT_LEVELED_MOVES setting. The difference is just the size of the last segment. When short, it is hard to distinguish it (acoustically) from the normal end of the line.

[VanessaE]

@thinkyhead, ah. Well, with this sequence, with the four G1 moves repeated several times in a row,

G28
G29
G1 X100 Y100 F18000
G1 X101 Y100 F18000
G1 X101 Y101 F18000
G1 X100 Y101 F18000

... it behaves exactly as it should and doesn't cause a stall, whether I paste into the "send command" field or "print" it from a regular text file, though when pasting large numbers of commands into the "send" field, sometimes a character or two gets dropped, but I think that's Pronterface's fault.

[thinkyhead]

What we see in your test squares is a not joined last move/segment regardless of the SEGMENT_LEVELED_MOVES setting. The difference is just the size of the last segment. When short, it is hard to distinguish it (acoustically) from the normal end of the line.

Yes, I'm way too aware of the details of that issue. Except how to fix it.

[thinkyhead]

It doesn't cause a stall, whether I paste into the "send command" field or "print" it from a regular text file.

Generally speaking stalls come from a starved planner when every move is a "final move." So chaining moves together prevents it from appearing. And we now make sure to chain the first move (another longstanding issue that we hope is fixed and not leading to side-effects).

It's too bad that we don't have debugging for these lowest-level issues that could be enabled at this time.

[VanessaE]

When I say "stall" I don't mean the printer stops - I mean the X or Y motor skips a bunch of steps.

[thinkyhead]

Well that's different. Motors may skip due to too many pulses per second, overheating drivers… Generally we also use the term "skip" to mean the motor tried to move, but hit too much friction and jumped backward a whole step. If that happens easily it can mean low current. Of course, you know all this…. The fact that changes to settings eliminates or reduces the issue is telling……

With hopes for a new release soon, I very much want to solve this. But I must sleep now, so I'll check in later today.

[VanessaE]

No sleep for you! :smile:

[thinkyhead]

I'm sleeping in a bowl of soup, so…

[VanessaE]

I am suddenly reminded of the opening "scene" in Neuromancer (the old video game)

[AnHardt]

@VanessaE Have you ever tried #define ADVANCED_OK (C*_adv.h)? This will print the actual buffer states with every 'ok'. I suppose a relation of a not well filled planner buffer with the stuttering you see. To improve that you have to eiter print slower or to increase the segment sizes. SLOWDOWN also may help.

Skipping steps in these low speed conditions let me assume a to high jerk. With some luck the steps won by breaking and lost in accelerating are equal and you don't see misdimensoned parts - but.

[AnHardt]

@thinkyhead I'm well aware you are aware. In a silent hour i'll check the 'optimizer' again. But already having played with it for days, i'm probably blind for the problem.

[VanessaE]

I had not tried ADVANCED_OK before. I've turned it on now, but I don't see any appreciable difference in the P and B values whether SEGMENT... is enabled or not, during the "problem" area of the test pattern. Lots of "ok Nxxx P0 B3" during that time, in both cases.

As for jerk, I have X and Y set to 20, Z at 0.3, E at 5.0, as my machine performs well with those settings in any case. For example, I printed this over the past day or so, using @Sebastianv650's LA 1.5 branch, with those jerk settings, SEGMENT... enabled (since that is the default and I hadn't yet been made aware of the setting), 30 mm/s max speed, 0.1 mm layers, 0.6 mm line width (0.4 mm nozzle), K=0.105 (for all colors, I haven't calibrated it per-color yet):

(high resolution image, click it, then click again for 100% size)

As you can see, it has well-defined edges and corners, and the original model file's faceting is clearly visible. One of my better prints, if not for the fact that I still need to improve my layer cooling (you can see that on the edge of the side window facing the camera). What you can't see is the subtle pattern visible on the back of the display stand, caused by the accel/decel of the segmented moves.

Note that my printer has no trouble at all with high speeds (as in 200+ mm/s), other than of course being lower quality as with any printer, as I said before these jittery segmented moves and lost steps problems did not exist under Marlin 1.1.6.

All of that said, "Error:Failed to enable Bed Leveling", yet it probed the bed just fine at print start, and I can see the Z motors turning appropriately as the printer goes about its normal X/Y moves. I've never seen this error before (or at least never noticed it). EDIT: Turining off ADVANCE_OK inexplicably made that error go away.

[AnHardt]

In @thinkyhead s test pattern we let run dry the buffer by purpose with the M400s. In the LA pattern the buffer ideally should stay full, like in normal printing parts. It can fluctuate a bit but shouldn't run dry or below 3.

[VanessaE]

Here's something to try: leave SEGMENT_LEVELED_MOVES enabled/un-commented, and set LEVELED_SEGMENT_LENGTH to something ridiculously high, e.g. 999. When I do that, I get proper single-event print moves without jitter, and no skipped X/Y steps during the K-factor pattern's numbers at the end either, though aborting the test pattern will cause it to start bisecting moves as previously discussed.

I'm not sure how well that setting will work during a "real" print, but it works during the K-factor pattern.

[thinkyhead]

leave SEGMENT_LEVELED_MOVES enabled/un-commented, and set LEVELED_SEGMENT_LENGTH to something ridiculously high, e.g. 999.

Interesting. And, you only get leveling applied to the start and end of each G1 move.

[VanessaE]

That seems to be the case, yes.

[thinkyhead]

Try some experiments with your LCD entirely disabled… humor me, for curiosity's sake.

[VanessaE]

My bot doesn't have an LCD.

[thinkyhead]

Well f*** me then. I can't see what's being implicated here yet.

[VanessaE]

Heh. Sorry :smile:

[thinkyhead]

At this point all I can think is to work backwards a week at a time and try snapshots until the problem goes away, testing the worst-case scenario. And from this figure out what commit is contributing to this oddity.

[VanessaE]

Are you not able to reproduce the issue using my configs?

[thinkyhead]

I note that your Configuration.h is unchanged from the default, so maybe it's the wrong one…? And your Configuration_adv.h only has LIN_ADVANCE and FWRETRACT added to it, as far as effective settings go.

So, in short, I have not enabled LIN_ADVANCE and FWRETRACT and done some testing with the CR-10S yet. But I'm happy to take that on as my morning project tomorrow. And if you have other settings to pass on, I'll use those too.

[VanessaE]

Strange, I thought I sent the right one. Here they are again (and just to be sure, I unzipped the file to a work dir and double checked that the files I wanted were in there): ~~Configs-20180223-9c65890.zip (note: after sending that file, I had to make some minor changes to my auto-leveling positions and safe-home positions, but nothing that should affect any tests).~~ Configs-20180223-9c65890-2.zip