Resonance Compensation - failure to accelerate

General Discussion
1

Basic Information:

Anycubic Mega Zero 2
ATmega1284p & R-pi4B V1.4 w/4GB
Klipper: v0.11.0-41-g9b60daf6
Octoprint 1.8.6
Python 3.7.3 (although line 146 in Klippy.log reports Python 2.7.16)
Octopi 0.18.0
Superslicer 2.4.58.5
klippy.log (1.8 MB)

Describe your issue:

The subject calibration procedure has been performed 3-times and each time the printer movement acceleration was never incremented after completing each 5mm section. Acceleration remained constant throughout the entire print.

Before the third print I halved the height of the stl (to save filament) and changed the command increment from 500 to 1000 just to get Ringing into the ballpark if the acceleration did indeed increment. It didn’t though.

Is the Tuning command post-processing the gcode to establish the correct accelerations, e.g., G1 F1000, G1 F2000, G1 F3000, etc. Can these be verified somehow prior to starting the print? To check this, after starting the print, I downloaded the gcode file from Octo and compared with the original. Notepad++ found no alterations. The files are identical.

Before starting the 3rd run I manually verified that both X and Y respond as expected to terminal movement accelerations from 1000 up to 10000 in increments of 500 so it doesn’t appear to be anything in the command or print movement chains.

How to troubleshoot this issue?
Sample Terminal output at layer change.

Send: N7684 M117 Layer: 133 of 150*108
Recv: ok
Send: N7685 G1 F1171*116
Recv: ok

I see in the Klippy.log that MAX_ACCEL is being incremented 6 times as expected for my shortened stl version so I’m left scratching my head.

Pic from second run…

20230102_095058
20230102_0950582187×951 130 KB

TIA, Greg

2

Can you share the (zipped) gcode file you use?

3

I’m not sure what you are reporting.
Judging from the klippy.log the print started off at an acceleration of 1000 and incremented up to 7000

4

Ring_Tower_short.zip (82.6 KB)
Files attached: STL & gcode

Yes, but the accelerations never increment as is evidenced by both the attached example pic and that I watched the whole thing three times.

Thx

5

Are you going with this?

https://www.klipper3d.org/Resonance_Compensation.html

6

Yes, thus the title of this thread. Sorry, had to add text to meet the 20 char min reply length.

7

Just because you see nothing on the print does not necessarily mean that the acceleration was not incremented. According to the klippy.log it was.

Edit: At which speed did you print?

8

Instructions called for 80~100mm/s so it was sliced at 100 with Exterior Wall speed set to 80%.

The XY lengths are long enuf for an audible pitch difference to be heard. No pitch changes were heard.

I’ve been trying to locate some info about the gcode acceleration change.

Send: N7685 G1 F1171*116
Recv: ok

Is this kosher? How should the printer acceleration respond to F1171*116?

9

F s not for acceleration, it’s the feed rate:

https://reprap.org/wiki/G-code#G0_.26_G1:_Move

10

Hmm, ok so the G1 F commands were not changing acceleration. My mistake, I confused Feedrate with Acceleration and lost a per second. :face_with_diagonal_mouth: Before we put that one completely aside I’m still curious about the command’s format. It is unfamiliar.

G1 F1171*116

From the link you provided I see that Klipper either doesn’t support the acceleration M201~M204 commands and/or they are all not present in the gcode file anyway. Edit: M204 is supported according to the Klipper G-Code page.

So, the G1 F was my mistaken rabbit hole and it leaves me no closer to solving this issue. Hmm…

11

All else being equal I ran the same shortened version thru Cura 5 rather than SuperSlicer with command
TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1000 STEP_DELTA=1000 STEP_HEIGHT=5
and the acceleration increments did take effect. :face_with_monocle: The only difference of note is that Cura does not have a Klipper setting so RepRap was used as the gcode flavor.

20230102_164809
20230102_1648093696×1293 415 KB

Any SWAGs as to what is going on here?

12

Hint: Klipper supports M204:

https://reprap.org/wiki/G-code#M204:_Firmware_dependent

13

For me it just looks like an mis-configured slicer. The first gcode file you posted seem to have been sliced at 15 mm/s.
That’s likely the reason why you did not see any acceleration effects.

Some unsorted notes:

  • Without good reason gcode files typically do not contain acceleration changes
  • Acceleration changes are called via M204 (standard gcode) or SET_VELOCITY_LIMIT (Klipper)
  • The TUNING_TOWER does not modify gcode files. This is a Klipper internal change during print time
  • Gcode flavor in Super Slicer makes no big difference
  • You initial problem could have come from a minimum layer time setting
14

The last picture reminds me on my fisrt attempts an my voron: the motors skipped some steps the whole print looked like yours (the step). The rest seems just to be not enough energy in the Hotend so the flow was too big for the heatblock. Sorry I did not go through the logs but I think you just went over your physical limits with this print.
You use the standard hotend? EV5 Type? This should do 10-15mm³/s reliably and maybe 20-30mm³/2 peek performance. Maybe you are over this? Calculate: Layer width[mm] * layer height[mm] * speed [mm/s] this should be (in case my guessing was right) be above 15mm³/s…(for constant flow ofer some seconds).
More or less: this looks ok, no problem just above physical limits. The Mega-“System” should do 60mm/s max (of course, this can be set to 120 but what happens then?)? I only got an Mega S from 2020 and the max speed was 60mm/s @0,4mm nozzle (no layer heigth given: honit soit qui mal y pense)…
You use the original bowden printehead?