RE: Printing head calibration going wild
Is this head banging done as part of a G28 command?
Yep, as Jürgen said. The g code just calls a G28 and I'll have to "follow the code" until I hit a function like "void homingBangAverage()"
There should be some algorithm that averages the values of the bangs and stops at some point.
Increase the tolerances, set the max. banging to 2, save, compile, flash, happy printing.
After that, I'll look into disabling the hotend heating in the G29 functions, to stop heating between the Z-moves during probing.
That should keep the nozzle temp. within a few degrees and solve nozzle cleaning errors and probing points multiple times.
It might be total chaos in the firmware and be way more complicated, than I'm anticipating, but I hope for the best.
I did such editing for esp32 and Arduino microcontrollers, so I'm confident.
I suggest connecting a terminal (Octoprint, Pronterface) and trying a G28 command.
The messages likely are good targets for searching the code.
/lib/Marlin/Marlin/src/module/prusa/homing_corexy.cpp seems to be the module in use.
Send: G28 Recv: echo:endstops hit: X:9.38 Recv: echo:endstops hit: X:10.00 Recv: echo:Backoff ipos:688 Recv: T:25.00/0.00 B:23.30/0.00 X:23.82/36.00 A:27.53/0.00 @:0 B@:0 C@:23.20 HBR@:0 Recv: echo:endstops hit: X:250.00 Recv: echo:endstops hit: X:250.00 Recv: echo:Backoff ipos:1609 Recv: echo:endstops hit: X:252.12 Recv: echo:endstops hit: X:242.07 Recv: T:25.00/0.00 B:23.30/0.00 X:23.82/36.00 A:27.50/0.00 @:0 B@:0 C@:23.20 HBR@:0 Recv: echo:busy: processing Recv: echo:endstops hit: X:252.12 Recv: echo:endstops hit: X:242.03 Recv: home point is unstable Recv: echo:endstops hit: X:252.12 Recv: echo:endstops hit: X:242.43 Recv: echo:endstops hit: X:252.12 Recv: echo:endstops hit: X:242.39 Recv: calibrated home cycle A:31 B:-1
RE: Printing head calibration going wild
I suggest connecting a terminal (Octoprint, Pronterface) and trying a G28 command.
That's a good idea, thanks!
When connecting the lower USB connector to the computer it shows up as a serial port and a serial terminal emulator does the job (my favorite is CoolTerm). This also makes it easier to count the number of head bangs.
It always shows X and no Y. I think it's a bug in the firmware.
G28 echo:endstops hit: Y:0.00 echo:Backoff ipos:471 echo:busy: processing echo:endstops hit: X:250.00 echo:endstops hit: X:250.00 Y:-10.08 echo:Backoff ipos:2169 echo:endstops hit: X:242.32 echo:busy: processing echo:endstops hit: X:242.28 echo:endstops hit: X:252.16 echo:endstops hit: X:242.60 echo:endstops hit: X:252.08 echo:endstops hit: X:242.60 echo:endstops hit: X:252.16 echo:busy: processing echo:endstops hit: X:242.60 echo:endstops hit: X:252.08 echo:endstops hit: X:252.16 echo:endstops hit: X:242.60 echo:endstops hit: X:252.16 calibrated home cycle A:31 B:-1 echo:busy: processing echo:endstops hit: Z:60.00 echo:busy: processing echo:busy: processing echo:endstops hit: Z:60.00 echo:busy: processing echo:endstops hit: Z:60.00 echo:Starting probe at 1 echo:busy: processing echo:busy: processing echo:busy: processing echo:Probe classified as clean and OK X:245.00 Y:0.00 Z:2.00 E:0.00 Count A:24500 B:24500 Z:800 ok Done printing file
RE:
I believe that the command G28 I does imprecise homing with only a few head bangs.
The relevant code is at line 344 of G28.cpp
Here is the gcode log:
G28 I echo:endstops hit: Y:-19.00 echo:Backoff ipos:481 echo:endstops hit: Y:-19.22 echo:busy: processing echo:Backoff ipos:2153 echo:busy: processing echo:busy: processing echo:busy: processing echo:endstops hit: Z:60.00 echo:busy: processing echo:endstops hit: Z:60.00 echo:Starting probe at 1 echo:busy: processing echo:busy: processing echo:endstops hit: Z:61.25 echo:busy: processing echo:Probe classified as clean and OK X:245.00 Y:0.00 Z:2.00 E:0.00 Count A:24500 B:24500 Z:800 ok Done printing file
RE: Printing head calibration going wild
I believe that the command G28 I does imprecise homing with only a few head bangs.
Now there's a find -- thank you!
Looking at the log file, it seems a bit strange that the initial (coarse) homing only homes the Y axis. When you do a "G28 I" from a cold start (printer freshly reset or powered on), does the command also home Y only then? And does the printer know where it is in X and Y afterwards?
RE: Printing head calibration going wild
Awesome! I guess when I'll have the time to dive into the code, you others will already have it done, haha.
About only homing X with the standard code: I think that's not a bug, it's using the X-motor only, doing a 45° move with just one motor. The firmware then uses both coordinates and calculates the rest.
You just need 2 points, the 45° angle and the measurements of the XY-frame to calculate everything.
The X-Motor will always be at that position of his 45° line movement, when the front is hit.
You can then use the distance between the two bang-points with the fixed 45° and calculate the other end-stops.
Of course, the end-stop positions of the Y-motor are functions of the X-motor coordinates then.
RE: Printing head calibration going wild
About only homing X with the standard code: I think that's not a bug, it's using the X-motor only, doing a 45° move with just one motor. The firmware then uses both coordinates and calculates the rest.
You just need 2 points, the 45° angle and the measurements of the XY-frame to calculate everything.
The X-Motor will always be at that position of his 45° line movement, when the front is hit.
I was not concerned about the "X only" movement during the precision homing. As you wrote, this must refer to the X motor (not the X axis on the gantry) and is consistent with the diagonal movement during the multiple bumps.
But before that happens, the print head moves orthogonally, bumping the right side and the front via a combined movement of the X and Y motors. In the log file for the regular G28 command, this is reflected by the "endstops hit: Y:0.00; endstops hit: X:250.00" echos. But in the G28 I log, there is only an "endstops hit: Y..." -- which does not seem enough to let the printer know where it is.
But never mind -- I tried this on my Core One in the meantime, and the first G28 I command after a new start will do the expected X + Y axis homing. Two bumps on the right, two bumps in front, done. And the printer will know where its print head is.
This is exactly what I was hoping for, and it solves the entire "headbanging" issue for me. I will just change my startup GCode to use "G28 I" instead of "G28", and get the non-precision homing I had been asking for since April. Why the heck could Prusa not be bothered to tell us that it's already available -- neither here in the thread nor in the Github issue discussion?!
RE: Printing head calibration going wild
I believe that the command G28 I does imprecise homing with only a few head bangs.
Now there's a find -- thank you!
Looking at the log file, it seems a bit strange that the initial (coarse) homing only homes the Y axis. When you do a "G28 I" from a cold start (printer freshly reset or powered on), does the command also home Y only then? And does the printer know where it is in X and Y afterwards?
That IS an excellent find. It really makes one wonder why someone from Prusa couldn't simply have responded to the Github issue and/or all the complaints in this forum, that you can add an "I" after the G28 command in the start g-code if you're not interested in being able to precisely restart after a power failure.
I suppose you'd still be left with the head banging when the head homes for a filament swap, but it's a start.
Perhaps the Github issue could be amended to request that 'imprecise' becomes the default, and it can be over-ridden with a different flag for precise homing, should the user choose.
RE: Printing head calibration going wild
This is exactly what I was hoping for, and it solves the entire "headbanging" issue for me. I will just change my startup GCode to use "G28 I" instead of "G28", and get the non-precision homing I had been asking for since April. Why the heck could Prusa not be bothered to tell us that it's already available -- neither here in the thread nor in the Github issue discussion?!
Haha - you posted while I was typing.
RE: Printing head calibration going wild
Thanks Jürgen! I agree with the logging "issue" with the shorter homing. Glad to read, that it's working fine anyway and does exactly, what we hoped for!
I suppose you'd still be left with the head banging when the head homes for a filament swap, but it's a start.
If my memory isn't playing games on me, you can dodge the risk of loooong homing with the heater on, by doing a cold "Auto Home" from the control menu first.
It will still do the 8 bangs though.
Doing a cold homing before changing the filament will use the stored homing position and won't do it again with the heater on.
I'm not sure if that works for "Change filament" too or only if you unload it first and then simply push the new filament in and select the material/temperature.
But it's definitely possible, in my memory, to swap filaments without a "heater-homing".
RE: Printing head calibration going wild
Thanks Jürgen! I agree with the logging "issue" with the shorter homing. Glad to read, that it's working fine anyway and does exactly, what we hoped for!
I suppose you'd still be left with the head banging when the head homes for a filament swap, but it's a start.
If my memory isn't playing games on me, you can dodge the risk of loooong homing with the heater on, by doing a cold "Auto Home" from the control menu first.
It will still do the 8 bangs though.
Doing a cold homing before changing the filament will use the stored homing position and won't do it again with the heater on.
I'm not sure if that works for "Change filament" too or only if you unload it first and then simply push the new filament in and select the material/temperature.But it's definitely possible, in my memory, to swap filaments without a "heater-homing".
Good point - thank you.
RE: Printing head calibration going wild
Awesome! I guess when I'll have the time to dive into the code, you others will already have it done, haha.
@raaz-2, it would still be useful to have a user setting to have imprecise homing by default, for example, for the change-filament function that does homing.
Now that the concept of imprecise homing is officially recognized, it may be easier to convince the authorities to have a user setting, via the LCD or using a gcode command that will set/reset the flag in the non volatile memory of the CORE One.
BTW, I find it confusing that Prusa calls the core xy motor X/Y and not A/B as customary. This makes their report about 'X hit' ambiguous.
RE: Printing head calibration going wild
Absolute agree, yep. I also dislike the X and Y motor names. They both do 45° moves. But I guess it's because of the upgradability, which gives you one X and one Y motor, plus two Z motors.
I'm really curious to dive into the code, but while I do have some skills in C++/Java/Pyton, when basically doing "single file projects" (libraries just used and in the background, handled by the ArduinoIDE, SimHUB, Jupyter), I never coded or compiled a real project with multiple files.
Learning how to work with real projects (and Github) will probably take more time, than to actually edit the firmware..
RE:
Learning how to work with real projects (and Github) will probably take more time, than to actually edit the firmware..
I am using Visual Studio Code. It allows you to search the entire source code tree for files and for content and to jump to definitions. The code is too complex to really understand it so you just need to dig in very narrowly and accept that you understand very little. It's a very different state of mind than dealing with a single file that you designed yourself. 😉
RE:
I have VS Code installed and tried to get a basic esp32 project with a standard library for it to work, but I couldn't get it to compile and stopped trying... And that was while using a step by step guide, that simply didn't work from a certain point and after 3 hours of Google + ChatGPT, I just lost the motivation..
I did program a festo belt drive during my first year of engineering, with a sorting ramp/flip, height measurement, metal detector, light barriers and a few buttons, which contained about 14 h/cpp files.
But that was with a very old IDE called Netbeans, partly pre-setup for us and there aren't really any modern guides/tutorials or helping threads for it. In clion, I couldn't even figure out how to import a working project...
Usually I'm the one in the room, who "intuitively knows what to click" etc.", but this stuff makes me feel like my grandma, when I'm helping her with her smartphone 🤣
Not the code itself, just getting the IDE etc. configured to compile.
RE: Printing head calibration going wild
Not the code itself, just getting the IDE etc. configured to compile.
Having the tool chain and the project configuration to have a simple 'hello world' running is indeed a pain.
For ESP32 and similar, I highly recommend using platformio, it makes the configuration much simpler. For Visual Studio Code you just need to install the platformio extension. Platformio even support real ESP32 debugging with single step and breakpoint using a debugger that costs less than $20. As a second choice, the Arduino IDE also makes setting a project very easy, including for ESP32, but it lacks the flexibility of VSC.
RE: Printing head calibration going wild
286 head bangs in a single G28 homing. Is it a world record or what?
RE: Printing head calibration going wild
Here is a hack in case you want to use the filament functions to change the filament but it causes an endless print head banging.
Create a test file called HOME.gcode and have in it a single line with a single command:
G28 I ; Safe homing
An upload the file your printer.
Before performing a filament change command, if the head is not already homed, e.g. from a previous print, use the LCD screen to 'print' the HOME file and this will perform a safe homing of the printhead. Then use the filament change commands as usual.
(This is my first Prusa and I never expected that I will need to deal with this long standing bug that they deny and classify as an 'enhancement request'. Prusa disappointed me.).
RE: Printing head calibration going wild
There is an indication from Prusa that they actively work on this issue.
https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4582#issuecomment-3122045640
RE: Printing head calibration going wild
... also, it seems that a good place to communicate with Prusa devs is here (I didn't try it yet):
RE: Printing head calibration going wild
holy cr*p this is getting annoying.
cold printer is ok, doing second print keeps banging for minutes on end.
again, loose the belts, square the gantry (again), use the (and let us be honest crap) sound app and get readings all over the place.
1000 euros for a banging object that is unable to print is a bit excessive. Could have bought me a djembe....