Probe hits the deck during X/Y/Z re-calibration
My MK3 printer has been working cheerfully for a year or so now but I've recently started to have more trouble than usual getting ASA to stick to the heat bed evenly so I thought I'd re-run the X/Y/Z calibration. My problem is that during calibration the nozzle always pushes through the protective sheet of paper on the first corner of the heat bed every time, no matter what I do. I've re-adjusted the Pindar probe height using the "cable-tie" method, so that it is definitely a cable-ties-thickness higher than the nozzle but that hasn't helped. I tried setting it slightly lower than that but then Z-axis calibration fails. This is with printer SW version 3.8.1-2869 "MK3S firmware detected on MK3 printer [tick]". I've not touched the nozzle and the printer has suffered no shocks that I'm aware of. And yes, the heat plate is removed. And the setup-checks all pass. And it is normal thickness paper.
Any suggestions as to what I'm doing wrong? Remember that the printer was printing PLA perfectly fine until I deleted the calibration...
Best Answer by vintagepc:
Yes, really. It's not an informational message, it's a note you need to fix it.
The different variants are built with different constants for various aspects of the printer defined in their files and the 3S firmware does not have the correct ones for the Mk3. The way C defines work, that data is not there for it to fall back on in a 3S build. The 3S firmware only knows what it needs to operate a 3S, not any other model.
RE: Probe hits the deck during X/Y/Z re-calibration
Z height is slightly different for 3S and 3. Flash the correct firmware, based on your description, you have the wrong one.
RE: Probe hits the deck during X/Y/Z re-calibration
When you reflash the firmware - do a master clear.
You will have to run through setup again.
RE: Probe hits the deck during X/Y/Z re-calibration
@vintagepc
Really? Since the firmware knows it's "MK3S firmware running on MK3", which the switch-on message displays, I kinda assumed that this was fine. Surely it shouldn't even load if it's not gonna behave, or should say instead "MK3 needs MK3 firmware and this is MK3S firmware, go sort yourself out!".
RE: Probe hits the deck during X/Y/Z re-calibration
Yes, really. It's not an informational message, it's a note you need to fix it.
The different variants are built with different constants for various aspects of the printer defined in their files and the 3S firmware does not have the correct ones for the Mk3. The way C defines work, that data is not there for it to fall back on in a 3S build. The 3S firmware only knows what it needs to operate a 3S, not any other model.
RE: Probe hits the deck during X/Y/Z re-calibration
Hmmm, I think maybe it needs re-wording. I'd assumed PRUSA had update their embedded code to work with variants rather than having to mess with #defines, especially since MK3S appears at the top of the pritner support page and MK3, having looked more carefully, is buried somewhere a lot further down the page, nowhere near it, as a legacy thingy.
Anyway, thanks for the swift information, will fix.
RE: Probe hits the deck during X/Y/Z re-calibration
Alas it's a complicated business as there is a lot of optimization to account for the einsy's available storage and program space. I'm guessing they don't want to penalize everyone's space for future features to create a mega-blob firmware that supports all hardware. It also makes testing and SQA a nightmare if you need to ensure each specific printer is executing the correct control flow path. Far simpler to have it guaranteed to only get a specific value and no possibility of anything else. KISS principle, after all.
But this is also the general layout of Marlin - printer specific constants are #defined in a configuration.h file specific to your variant, you customize that and don't need to dive deep into the C code to add an if/else/switch/whatever for your variant that isn't supported.
There are additional message constraints w/r/t sizing and spacing of messages I'm not intimately familiar with, but you could certainly file a github issue suggesting the wording be improved. At the very least, you'll probably get an answer why it is the way it is.
https://github.com/prusa3d/Prusa-Firmware/issues
RE: Probe hits the deck during X/Y/Z re-calibration
@vintagepc
Good idea, will do.