RE: Printing head calibration going wild
The printer has no idea where things are when it powers up, as someone could have moved the extruder around while powered off (or even without).
So, calibration is needed so it has some idea where things are.
But in normal operation, the printer does not need to know ultra-precisely where it is. A single bump into the X and Y mechanical end stops, detected by the motors' stallguard function, should be enough to determine the position to within a fraction of a millimeter -- easily accurate enough to ensure that the print heads stays within the printable area.
The only reason for very precise homing that I can come up with is to support recovery after a power outage. If you want to make sure that the next layer printed after resuming a print sits nicely on top of the last layer before an outage, you need much higher accuracy. I assume that is the reason for the many bumps and whatever averaging the firmware performs.
But I am not interested in that functionality! We experience on the order of one (short) power outage per year, and I am printing far from around-the-clock. I will happily trade one lost print every few years for a quick and quiet homing procedure before every print. PRUSA, if you can't get a better handle on the high-precision homing implementation, at least allow us to turn it off!
RE: Printing head calibration going wild
... But I am not interested in that functionality! We experience on the order of one (short) power outage per year, and I am printing far from around-the-clock. I will happily trade one lost print every few years for a quick and quiet homing procedure before every print. PRUSA, if you can't get a better handle on the high-precision homing implementation, at least allow us to turn it off!
@jurgen-7 is right! No need to burden all users for a feature they don't care about.
I created a feature request for allowing users to disable the precise homing. If you agree with it, please add your support there (requires a free github account).
https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4723
RE: Printing head calibration going wild
Surely Prusa can come up with a more accurate process to produce their parts - or at least come up with a more accurate user process to correct their manufacturing shortcomings (check diagonals of XY assy are equal or provide a frame to guarantee 90 degrees in corners?).
I guess, that the brackets are designed to bend, before the Y-Axis bearing can get stuck and damage the printer.
That wouldn't really be an issue, if the calibration wouldn't be, what it is..
I have no idea who came up with the idea to bang the print head multiple times against the end-stops, without some sound dampening.
I also absolutely don't know why Prusa thought it would be a good idea to annoy 99,99% of customers for 99,99% of prints , just to get an almost invisible seam, if a power outage happens.
If no power outage happens during a single object, half a millimeter off-set wouldn't be an issue and there wouldn't be the need for more than one bang per axis. *tock* *tock*, printing.
This extra accurate banging should be an optional setting for power outage protection..
Is that really the only reason it does the stupid banging on every print ? I've had one power outage in the last 5 years.
Any way to skip this in the startup gcode?
RE: Printing head calibration going wild
I'm afraid not. G28 triggers the complete homing process in X/Y/Z. And you need some rough homing in X/Y, so the print head knows where the printable area is. It would not have to be accurate, and a single bump each against the X and Y end stops should do the trick. But I don't think you can give parameters to G28 to tell it the accuracy you want.
RE: Printing head calibration going wild
Is that really the only reason it does the stupid banging on every print ? I've had one power outage in the last 5 years.
Yes, the only reason, and cutting cost by avoiding using proper end sensors.
I would expect Prusa to chime in here and address the complaints.
RE: Printing head calibration going wild
Yes, the only reason, and cutting cost by avoiding using proper end sensors.
Using a mechanical end stop and the motor drivers' Stallguard is not a bad and "cheap" solution per se. It's accurate, can't wear out or drift out of alignment. I don't fully understand why the Core One firmware has such a hard time using the Stallguard for accurate determination of the end stop position. It's probably a combination of the long, slightly elastic belts and the dual stops (left & right) muddying the signal.
I would expect Prusa to chime in here and address the complaints.
Oh no, they never do that. Prusa employees are so consistently absent in these forum discussions that I believe there must be a company rule that requires them to keep quiet.
RE: Printing head calibration going wild
The main bug report for this issue is here
RE: Printing head calibration going wild
The main bug report for this issue is here
But Prusa's engagement there is just as unsatisfactory as it is here on the forum. I had suggested to make the precise homing optional (and mentioned the assumption that it is only required for resume-after-power-loss) as early as April 8th. Didn't get any feedback at all from Prusa.
RE: Printing head calibration going wild
But Prusa's engagement there is just as unsatisfactory as it is here on the forum. I had suggested to make the precise homing optional (and mentioned the assumption that it is only required for resume-after-power-loss) as early as April 8th. Didn't get any feedback at all from Prusa.
There is also no much commit activity in that repository. This is my first Prusa printer and I expected a more proactive customer service. Those arbitrary and unbound head bangs definitely project a poor quality.
https://github.com/prusa3d/Prusa-Firmware-Buddy/graphs/contributors
RE: Printing head calibration going wild
I'm thinking about hanging an "automatic fire extinguisher cookie" above my Core One and then dive into the firmware myself.
Due to fire insurance, it can be potentionally annoying, if there's a fire and they find out you took out the little pin on the motherboard to flash a custom firmware.
Having an automatic extinguisher should help. They are available from 25€.
The firmware code doesn't seem to be super complicated for specific function blocks, so I might be able to edit it to only bang 2x and increase the tolerance.
The firmware as a whole is way beyond my skills though...
RE:
Due to fire insurance, it can be potentionally annoying, if there's a fire and they find out you took out the little pin on the motherboard to flash a custom firmware.
It seems unlikely to me that fire safety of any Prusa printer depends on firmware functionality. I would rather assume that they have either deployed over-temperature protection in hardware, or shown that even constant power to a heater cannot ignite anything.
Getting a firmware-based safety feature accepted in a compliance audit is very difficult in my experience. And based on the company behavior that is observable from the outside, I would be really surprised if Prusa's development and testing processes are stringent enough for that.
Also, I don't think it would be acceptable for Prusa to say: "We have provided this little break-away tab. Feel free to use it, but then the product may become a fire hazard." They can limit their warranty, but not compliance with CE and UL requirements, as long as they are dealing with consumers.
RE: Printing head calibration going wild
I'd think so too, you're probably right. This is stated on their website, which gives a bit of fuel for getting anxious:
"Breaking the appendix seal won’t void your warranty, so you are free to flash custom firmware.However, since there is no way for us to verify or test every single custom firmware on the internet, we disclaim liability for any kind of damage or harm a printer with a broken seal may cause (e.g. in case of a fire). So, please, don’t mindlessly flash suspicious files! "
I doubt it would be an issue, but I'd like to sleep with a calm mind during prints and an extinguisher cookie won't hurt anyways.
RE:
I'd think so too, you're probably right. This is stated on their website, which gives a bit of fuel for getting anxious:
"Breaking the appendix seal won’t void your warranty, so you are free to flash custom firmware.However, since there is no way for us to verify or test every single custom firmware on the internet, we disclaim liability for any kind of damage or harm a printer with a broken seal may cause (e.g. in case of a fire). So, please, don’t mindlessly flash suspicious files! "
I doubt it would be an issue, but I'd like to sleep with a calm mind during prints and an extinguisher cookie won't hurt anyways.
That disclaimer seems a bit absurd. I have posted a comment on the respective support page asking for clarification.
RE: Printing head calibration going wild
... my Core One and then dive into the firmware myself.
Worth creating an new thread for it, where you and other post their findings.
Is this head banging done as part of a G28 command?
RE: Printing head calibration going wild
Is this head banging done as part of a G28 command?
Yes.
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.
RE: Printing head calibration going wild
After that, I'll look into disabling the hotend heating in the G29 functions, to stop heating between the Z-moves during probing.
Does github as an open issue for the Z/heater problem? If not, I suggest to open one.
That github repo seems stale, with no commits in the last three months and 40 open PRs.
RE: Printing head calibration going wild
Found this bug report regarding the Z/heater issue. https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4596
RE: Printing head calibration going wild
Found this bug report regarding the Z/heater issue. https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/4596
What does it mean that this issue, as well as the related #4571, are "assigned to 3d-gussner" -- apparently a non-Prusa volunteer who has not contributed anything on Github for the past three months?
RE: Printing head calibration going wild
That github repo in general seems to be stale in general, with no commits in the last three months.
Possibly Prusa declared victory and moved on.