Bed probe positions.

[GilesBathgate]

Hi, I don't understand how these positions are derived.

MK404/parts/components/PINDA.cpp

Lines 186 to 189 in 029cc59

	};
	static float _fMK2Cal[18] = {
	13.f + 22.f, 6.4f + 3,
	13.f + 22.f, 104.4f + 3,

We have the definitions here:

https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/mesh_bed_calibration.cpp#L53

const float bed_ref_points[] PROGMEM = {
    13.f  - BED_ZERO_REF_X,   6.4f - BED_ZERO_REF_Y,
    115.f - BED_ZERO_REF_X,   6.4f - BED_ZERO_REF_Y,

but BED_ZERO_REF_X is #define BED_ZERO_REF_X (- 22.f + X_PROBE_OFFSET_FROM_EXTRUDER)
and BED_ZERO_REF_Y is #define BED_ZERO_REF_Y (- 0.6f + Y_PROBE_OFFSET_FROM_EXTRUDER)

I get that you set the pinda offset from extruder as 0,0, so ignore those, but where does the magic 3 come from? surely it would be:

static float _fMK2Cal[18] = { 
	 13.f -  -22.f,	  6.4f - -0.6f, 
	 13.f - -22.f, 	104.4f - 0.6f, 
	 //...

?! 🤷‍♂️

[vintagepc]

That is the Y offset. In the firmware there's some trickery that makes the bed front (prime line) be at Y = -3, out of the normal printable region - the bed is actually a few mm longer than the printable area.

This offset is to correct between the simulated motor position, which goes from 0 to 213 to place the probe points in the correct region from 0-210. In other words, the values in the firmware are relative to bed zero, whereas the simulator values are relative to the motor travel "zero".

[vintagepc]

Simulated motor positions should never go negative. This would suggest the axis length might be incorrect or that "home" is not at zero then and the printer expects to be able to travel slightly more once the endstop is triggered.

[vintagepc]

Any idea how many steps it tries to overtravel?

[GilesBathgate]

Sorry, the simulated motor positions don't go negative. Only the firmware Y.

Previously X and Y were displaying 10

[GilesBathgate]

Hmm, if I add a check for the Axis and ensure z cannot go negative I have the same issue. So not the correct fix :(

[vintagepc]

What happens if you change the tripping point for the MIN_OUT IRQ from <0 to something like 0.5/1mm (50/100)?

That way the endstop triggers before we run off the end of the motor travel but leaves some "squishy' homing room.

[GilesBathgate]

@vintagepc Well, I think I've found a bug. (maybe an old MK2 firmware bug, or simulation bug. )
I use a stock MK2S 3.2.3 firmware image (from prusa download page https://help.prusa3d.com/en/downloads/)

$ ./MK404 -f ~/1_75mm_MK2-RAMBo13a-E3Dv6full.hex Prusa_MK2_mR13

If I run selftest immediately after starting the printer up, no problems, but if I run auto home first, and then selftest:

[vintagepc]

Hmm... that almost sounds like the firmware is not moving away from the axis end after a home and allowing the virtual endstop to "untrigger". Then when it attempts selftest the endstop is already set and it doesn't like that.

[GilesBathgate]

@vintagepc The bad news is that this is not a firmware bug. I've just flashed stock MK2 to my physical MK2, and it seems to work fine.

What I can say though is that after an autohome, if I click Settings -> Move Y, the reading is -001.1. If I then do the same on the sim, I get -001.9

[vintagepc]

iiiiiiiiiiiiiiinteresting. I'll see if I can find some time to look into what's going on today... unless you beat me to it 🤣

might be interesting to do a VCD dump of the step count and step pins to see if we're somehow continuing to step into a region we shouldn't and hitting undefined behaviour

[vintagepc]

Interesting. Alas I'm not an expert in that area of the FW so no idea why here either...

[GilesBathgate]

Maybe @leptun has an idea, (if you are not too busy)

[leptun]

Sorry, no idea. The offsets and calibration points have always confused me and honestly made little sense. I'm too afraid to touch that code :)

[GilesBathgate]

Well thanks for taking a look. I guess its either a bug in the sim, or a problem with my understanding. Maybe I will get to the bottom of it someday ;)

[GilesBathgate]

@leptun So it seems to be that when the endstops are enabled the XY move doesn't happen in the sim, but it does happen on real hardware. This change fixed it: GilesBathgate/Prusa-Firmware@6c23305