G28 is reversing extruder and increasing extruder rate ? Bug or Setup issue?

General Discussion
1

Basic Information:

Printer Model: Virtual Cartesian
MCU / Printerboard: Mega2560 + RAMPS 1.4
Host / SBC: BeagleBone
klippy.log
klippy (30).log (88.2 KB)

additional_files.zip (292.8 KB)
test_presureAdvance2.gcode (62 Bytes)

Quick pre-story:
I did want to analyze how hardware is behaving when i use pressure_advance, so I fetched my dusty Mega2560 and Ramps 1.4 and quickly build test rig, hook up cheap logic analyzer to Step/Dir pins, attached thermistor and did compile config for this virtual cartesian printer which can work without End-stops and synced Extruder rates with Axis rates 1:1 (did this by increasing nozzle diameter to same size as input - 1.75 and set same rotation distance and microstepping)

Everything start working as expected.

image
image1920Ă—1440 270 KB

But when I prepared some simple test gcode (attached), set pressure_advance to 0 and start running tests I did notice strange behavior in oscilloscope software, first move after G28 was reversing Extruder and was doing 3x steps than it supposed to do, any following moves was putting extruder in correct direction and rate.
If I did FIRMWARE_RESET and then execute the test - everything is fine, extruder is going in correct direction and have correct rate and in sync with motion, but next execution of same simple test again is producing this incorrect behavior, and all future repetitions of the test also behave incorrectly.

Test execution after FIRMWARE_RESET

image
image1920Ă—1040 60.6 KB

Test execution second time, third, …
compare DirE behavior - which represent Extruder Direction.

image
image1920Ă—1040 63.4 KB

Two sequential runs of a test after FIRMWARE_RESET in single session, changed theme and added details

image
image1920Ă—1040 90.9 KB

My Initial thoughts was - Ok, i have my own feature “Automatic extrusion” and probably I made somewhere an error and it’s causing this behavior, so I fetched latest vanilla Klipper from github, re-flashed Mega again and did tests again, and yes I still se this issue.

In Klippy log look at latest session, it represent two sequential runs of same test after FIRMWARE RESET.

I attached CSV data exports and saved sessions from Saleae Logic 2.4.6 software.

So my main question: is this a bug or my configuration and test is bad ?
Does somebody experienced some weird (short) extruder behavior on next print ?

Thanks.

2

First thing I’d check is that your PAUSE/START_PRINT macros aren’t unintentionally interfering.

Your PAUSE macro has a slight retraction in it.

Don’t know why that would run when you’re starting the print but probably better to eliminate any source of unintentional effects.

3

Nope, didn’t helped.

Removed everything, just Cancel print was left because of Fluidd requirement.

klippy (31).log (84.3 KB)

4

Have you thought about dumping the motion history for the steppers and looking into what it’s doing move by move?

https://www.klipper3d.org/Debugging.html#motion-analysis-and-data-logging

You might also dig through the extruder kinematics file if you haven’t already. That’s one I haven’t honestly dug into much but it would answer your pressure advance questions from the software side at least and might provide some insight on what that starting extruder change is.

5

Sure, I can dig around and spend there few days/weeks :slight_smile:

But maybe somebody else already have all required knowledge to quickly identify the issue.

6

I found an answer - which actually did surprise me :face_with_symbols_over_mouth:
G28 is not resetting the Extruder, and on second print extruder is reversing from last position E60 to commanded position E15
Ant it’s not a bug because in documentation for G28 is described following way:

  • Move to origin: G28 [X] [Y] [Z]

The fix is easy, I just added G92E0 after G28 and issue went away.

2 Likes