Firmware Bug J1 in Junction Deviation?

Hi everyone, I’m new to this forum but I’m hoping that anyone can share similar experiences and/or fixes. I’m running into a print quality issue that looks like a problem with the “M205 V10” GCode command for setting the corner velocity which I believe indirectly sets the Junction Deviation parameter of the Marlin firmware.

M201-M205 => Horrible flat areas

Here’s how my print looks like with the M201 to M205 lines in the GCode. There are clearly visible artifacts on the floor and in general things look like over-extrusion.

Remove M201 to M205 from GCode => Wavy Walls

When I manually remove the M201 to M205 lines and then print the (otherwise) exactly identical GCode, the floors turn out almost flawlessly:

However, this print has wavy walls. It’s difficult to see on the picture, but it seems to be the same smooth bump shape repeated every 0.9mm. At first I thought it might be the Gyroid infill showing through, but that one is diagonal. Picture of infill in the GCode:

The wavy walls are only in the X-Y-direction, but stay the same for all Z levels. That means they can’t be from the Infill, because the latter is diagonal in X+Z.

Here’s the GCode for the outer perimeter:

As you can see, it’s just one straight G1 extrusion where the Y coordinate remains constant. This should be a move purely along the X-axis, so it should not have any shaping or resonance or ringing. But it does. To make sure it’s not caused by vibrations, I also printed the perimeter lines with just 20mm/s but that didn’t help either.

Re-Add M205 V10 => Walls straight again, Floor bad again

If I now add “M205 V10” to the GCode again, then the wave pattern on the walls is fixed and they are straight again, as they should. But at the same time, that M205 command makes the infill lines wavy in thickness. In the Gcode, these are straight G1 extrusions along the X-axis:

And given that I’m printing with a reasonable speed of 50 mm/s and about 1mm^3/s flow rate, there is no reason why that GCode would create such a bad surface finish:

Firmware Bug in handling M205?

Since the GCode that I printed is otherwise identical between those 2 tests, the only possible explanation that I can think of is that there is a firmware issue in handling the M205 gcode command that causes the motion planner to somehow add a repeating wave pattern to what would otherwise be perfectly straight and axis-aligned perimeter lines.

I’m on the latest 2.7.2 firmware: Snapmaker J1/J1s Firmware Updates and Downloads - #16 by Alan

(and the current beta doesn’t mention any motion-related changes)

No, it’s not bad print bed adhesion

Since the otherwise identical GCode (without the M205 command) produces a perfect floor on the same printer with the same extruder and the same material, I’m pretty sure that it’s not related to print bed calibration or adhesion.

Any similar experiences?

Does anyone else have similar experiences where the printer’s speed limit GCode commands (like M205) cause straight axis-aligned lines to become wavy?

Share your observation with support please.
https://support.snapmaker.com/hc/en-us/requests/new

I CC-ed this post to Support together with the GCode and my printer Serial Info.

And, BTW, looking at the Snapmaker firmware source code, I could now confirm that M205 V will set the corner velocity and junction deviation:

Support suggested trying “M205 V5” which didn’t help. Oddly enough, lowering the V number appears to make the edges of my rounded rectangle shape worse. Here’s some additional tests I ran:

M205 V3
bad first layer, mediocre walls, bad edges

M205 V10; M593 P0 F50
very noisy, the abrupt speed changes sound pretty brutal. very good first layer. walls are still wavy, but not a repeating pattern, instead they look more like random vertical artifacts, i.e. might be vibrations. edges are bad

M205 V10; M593 P1 F50
in contrast to the P0 variant, this one was less noisy. the edges are better, but walls and first layer are a bit worse.

M205 V40
horrible first layer, but walls and edges are good again

Based on the official PrusaSlicer profile:

I get this initialization GCode:

M201 X10000 Y8000 Z100 E6000 ; sets maximum accelerations, mm/sec^2
M203 X350 Y300 Z10 E40 ; sets maximum feedrates, mm / sec
M204 P10000 R6000 T10000 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X10.00 Y10.00 Z3.00 E2.50 ; sets the jerk limits, mm/sec

followed by:

M205 V10 ;Junction Deviation (mm)

Based on the source code on GitHub:

junction_deviation_mm will end up with a value of 10×10×(√2−1)÷10000 = 0.00414213562373

But then recalculate_max_e_jerk

sets prop = 0.00414213562373×√0.5÷(1−√0.5) = 0.01
which then sets max_e_jerk = √(0.01×6000) = 7.74596669241483

and that seems to be a very high value to me, if you consider that the machine_max_jerk_e in the profile was only 2.5, i.e. the new value is 3x the old limit.

Also, the firmware source code somewhat suggests that the official PrusaSlicer profile is faulty, because it clearly states that M201 (and M203) only apply to 1 extruder at a time:

which leads me to conclude that, actually, the initialization GCode should have 2 M201 and M203 lines each, because this IDEX printer has 2 extruders.

M201 T0 X10000 Y8000 Z100 E600 ; sets maximum accelerations, mm/sec^2
M201 T1 X10000 Y8000 Z100 E600 ; sets maximum accelerations, mm/sec^2
M203 T0 X350 Y300 Z10 E40 ; sets maximum feedrates, mm / sec
M203 T1 X350 Y300 Z10 E40 ; sets maximum feedrates, mm / sec
M204 P10000 R6000 T10000 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X10.00 Y10.00 Z3.00 E2.50 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec
M205 V10

In case someone else encounters the same error, this starting GCode produces both a good first layer and non-wavy side walls.

Here’s what I changed when comparing this to the default PrusaSlicer profile:

  1. I have duplicated the M201 and M203 lines and added T0 and T1 to correctly set these values for both extruders.
  2. I have reduced machine_max_acceleration_e from 6000 down to 600. This circumvents the recalculate_max_e_jerk issue that I’ve documented above.
2 Likes