[1.1.7] Travel deceleration instantaneous resulting in extreme vibrations

[playlet]

Hi, guys. I have something strange to report.

Bug Report

• Description: Slowing down from travel move to printing move is instantaneous resulting in extreme vibrations & noise. Not to mention that my extruder can be seen in 3 places at once during. :)
• Expected behaviour: Gradual slow down according to the acceleration setting.
• Actual behaviour: Instantaneous, ignoring travel acceleration setting.
• Steps to reproduce:
  • No special steps, happens at every print no matter what settings used in slic3r or marlin.

Prusa i3, Ramps 1.4

This is the same in 2.0 version.

Attached configuration files here. Configs.zip

Thanks and best regards,

Ivan

[Spawn32]

"3 places at once during" ? try: //#define time_warp :D

[playlet]

Haha, exactly! :)

It stops so violently that it vibrates 5mm left-to-right a couple of times

[thinkyhead]

Last-minute changes were made to the jerk algorithm in an attempt to address an occasional stutter on CoreXY. Apparently it has unanticipated side-effects.

@Bob-the-Kuhn Perhaps it would be prudent to revert the new jerk code.

[thinkyhead]

Please test #8810 (this branch) to see if it restores proper movement.

[playlet]

Thank you @thinkyhead . Please give me 30 min to an hour to finish a print currently in progress and then I will test this.

[thinkyhead]

Thanks! If the revert solves it, we'll just patch the release and call it "1.1.7 (as it always was)."

[playlet]

Reporting back...

No, this did not fix it. Still violent decelerations.

I only downloaded planner.cpp to my folder with 1.1.7. Do I need to download entire branch?

[Bob-the-Kuhn]

Also download planner.h. I don't remember which PR also modified planner.h

Try setting all your accelerations to the same value.

Is this new behavior? If yes, what was the last one that was well behaved?

[playlet]

I downloaded the whole branch in a second test, it did not help. Still the same. 1.1.6 works fine and (the last bugfix I tried before 1.1.7) 1.1.x bugfix from November 26th also works fine

[thinkyhead]

@playlet Are you testing with some form of leveling enabled, and do you see the same behavior if leveling is disabled (M420 S0)?

[Bob-the-Kuhn]

• 1.1.6 works fine.
• 1.17 has problems.
• The new branch that Scott created has problems. NOTE - This branch is different than the 1.1.7 or bugfix-1.1.x
• The same configuration file (with DEFAULT_ACCELERATION different than DEFAULT_TRAVEL_ACCELERATION) was used in all the above.

Could you provide a gcode snippet that shows the problem?

[Bob-the-Kuhn]

Scott - AUTO_BED_LEVELING_BILINEAR is enabled in his config.

[thinkyhead]

Could you provide a gcode snippet that shows the problem?

I second that. @Bob-the-Kuhn Are you unable to reproduce the issue?

I've posted some dated branches for testing... Please try each one. I'm away from my printer or I'd get into testing myself…

• December 8
• December 4
• November 31
• November 27

AUTO_BED_LEVELING_BILINEAR is enabled in his config.

@playlet Please test both with and without this enabled during moves.

[thinkyhead]

@Bob-the-Kuhn One thing to note is that when I first adopted the Jerk code from the Prusa MK2 fork it led to the Jerk values changing their meaning, so that you had to basically cut your jerk in half. I wonder if our recent jerk changes have led to the meaning of the jerk value changing again.

[playlet]

Ok, so far I have tested M420 S0 with 1.1.7 (+ changes from @thinkyhead's test branch) and travel deceleration is then fixed. Now off to testing these branches.

Any gcode with objects spaced far apart will make it do that. Here's the gcode. testing-accel.zip

[thinkyhead]

Interesting. Another thing you should try (with 1.1.7) is to disable SEGMENT_LEVELED_MOVES and see if that fixes it too. It's starting to look like that may be contributing, so it may not the new jerk code, per se.

[playlet]

1.1.7 - Disabling SEGMENT_LEVELED_MOVES fixes it (leveling enabled & disabled).

[thinkyhead]

@playlet That's just plain interesting. I've been staring at the segmenting code for a while and can't see anything wrong with it. It merely splits up any linear move into small segments. By default these segments are 5mm in length.

Something you could try is to test (segmented) linear moves that are 50mm (an even multiple of 5mm) then test lines that are 50.05mm, 50.1mm, 50.25mm, 50.5mm, 51mm, 52.5mm, etc., and see if the problem goes away and comes back depending on those extra little segments.

[thinkyhead]

@Bob-the-Kuhn We're not out of the woods with the new acceleration/jerk code yet. Segmentation alone shouldn't cause unusual changes in speed.

@playlet Before your next test, be sure to do M502, M500. Might as well do an M501 afterwards too. This will make sure that there are no bad values in the EEPROM contributing.

[playlet]

Sure.

Just need a little help with this part:

Something you could try is to test (segmented) linear moves that are 50mm (an even multiple of 5mm) then test lines that are 50.05mm, 50.1mm, 50.25mm, 50.5mm, 51mm, etc., and see if the problem goes away and comes back depending on those extra little segments.

I need to make stl with lines scattered on the bed, 50.05mm, 50.1mm, 50.25mm, 50.5mm and 51mm long? Did I understand correctly? :)

[thinkyhead]

@playlet I notice that your G-code sets a pretty high rate for those travel moves…

G1 X59.487 Y120.711 E0.6618 F1650
G1 X59.763 Y120.825 E0.6804
;. . .
G1 X48.875 Y120.711 E3.6971
G1 X135.510 Y120.572 F10000

That last move is 166mm/s. See if general moves at that speed are jerky. If so, lower your max feedrate for XY.

[thinkyhead]

I need to make stl with lines scattered on the bed, 50.05mm, 50.1mm, 50.25mm, 50.5mm and 51mm long? Did I understand correctly? :)

Sort of. The lines should connect end-to-end, but have direction changes. So, any regular polygons with sides of length X should work. Triangles will have strong direction changes, as will squares. Probably don't need to go beyond a pentagon.

[playlet]

Okay.

10000mm/min for a travel move on my printer is normal, no jerky moves with acceleration: 500.

[thinkyhead]

@Bob-the-Kuhn Do you think it's possible that the junctions are getting messed up because one move is capped to the max printing feedrate, while the next move is only capped to the travel feedrate, and then the next move after that is, again, capped to the printing feedrate…?

If so, we should look at the part of the planner code that involves print-versus-travel limiting and its relation to the junction code.

no jerky moves with acceleration: 500.

@playlet Thanks for testing that. I guess you may as well try those dated branches and see if the problem exists in all of them, but only after Nov 29. That's the day I added the segmentation.

• December 8
• December 4
• November 31

If the problem exists after segmentation (Nov 29) but before the new planner (Dec 4) and jerk code (Dec 6), then something else interesting is going on.

[playlet]

No problem. Although I think I'll have to delay it for a few hours. I'm getting mighty sleepy. It's 2:30 AM here :)

Dec 4th I tested earlier - leveling on, segmentation on - Travel (non printing moves) on deceleration did not stop violently but rather "with a ringing sound". In like 3-4 fast steps. Not as bad as 1.1.7 - stops instantaneously shaking the whole printer.

[thinkyhead]

Ok, you need your sleep! I'll be heading over to my workplace later tonight, so I'll do my own testing then.

[thinkyhead]

Please test the bf1_reverting_8735 branch and see if it solves the issue.

[Bob-the-Kuhn]

@thinkyhead - try the deceleration PR?

[playlet]

Hi guys,

bf1_reverting_8735 is ok, no violent decelerations

[Bob-the-Kuhn]

😉 Your bits must bad. It can't possibly be my code ...

I definitely don't understand how it could be causing problems. Please try, one at a time, the following changes in stepper.cpp to isolate the offending code:

1) change line 454 to read TCNT1 = 0;

2) add the following lines: a) change line 710 to read if (first_step) acc_step_rate = current_block->initial_rate; b) insert between line 454 & 455 first_step = true; c) insert between lines 449 & 450 bool first_step = false;

[thinkyhead]

I definitely don't understand how it could be causing problems.

Without looking too closely, it appears like the stepper ISR is taking a break (stops firing for a period of time) before it finishes the last move. My first thought is that this could be due to the ISR being set to fire at TCNT1 == big_value when TCNT1 is reset to 0. Possibly, the various variables that check when they're supposed to fire (endstop check, linear advance routine, steps) also need to be updated (subtracting the current value of TCNT1) before TCNT1 is reset to 0.

[Bob-the-Kuhn]

The stepper queue is running dry which results in 5-30mS periods of total stepper inactivity. These are all due to G92 E0 and retract commands.

Is the 5-30mS what you were seeing?

[thinkyhead]

I did very simple tests with single horizontal/vertical/diagonal moves on a Cartesian, while SEGMENT_LEVELED_MOVES was enabled with ABL_BILINEAR. I gradually increased the feed rate to test different speeds. At rates around 160mm/s, near the end of the linear move I would get a sudden stop, a pause of at least 250ms, and then what seemed like the rest of the move. There were no G92 commands or E moves used in my testing.

When I reverted the problematic commit, moves at high feed rates stopped exhibiting this behavior.

[Bob-the-Kuhn]

What commit/PR did you decide was the culprit?

[thinkyhead]

See #8819.

[e-Mole]

Same acceleration problem on my delta (marlin 1.1.7). Disabling SEGMENT_LEVELED_MOVES not help. Marlin 1.1.6 - no problem, smooth fast movement with acceleration and deceleration.

[e-Mole]

It seems this behavior is related to the activation of software endstops (MIN and MAX) and bed leveling (I use BILINEAR). If I disable SW endstops, the motion is smoother. Then when switching off leveling, movement is even smoother.

[thinkyhead]

How is it in bugfix-1.1.x @e-Mole ?

[e-Mole]

Last bugfix-1.1.x don't work with delta. The effector rises out of the print area and strikes down into the printer frame.

[thinkyhead]

Disabling SEGMENT_LEVELED_MOVES not help.

Doesn't matter on DELTA. It always uses segmented moves.

The effector rises out of the print area and strikes down into the printer frame.

Under what circumstances? My car skids.

[e-Mole]

My error, I turned off the SW endstops and at the beginning of the gcode I have a movement on the edge of the glass to wipe the nozzle (In the previous version it did not matter, now the printer behaves strangely (efector goes out completely and crashes down). However, when the nozzle wiping code is removed, the print start is OK. Unfortunately, bugfix-1.1.x behaves similarly in motion. Big jitter when printing rounded parts of the model. Straight lines are printed normally (it seems). When printing at 120 mm/s, the problem disappears. At slower speeds 60 mm/s, however, it is pronounced and the lower the speed (40 mm/s) is worse and worse.

[playlet]

Hi guys, I'm back and I'm happy to report that the latest release is working great. Thank you!

Happy holidays to all of you :)

[e-Mole]

@playlet : 1.1.8 or bugfix-1.1.x?

[playlet]

release, 1.1.8 :)

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.