[FR] Prusa MK42/52 Skew Correction

[felixekman]

With 1st and 3rd parties coming out with the MK42 heatbed for use in other machines and other motherboards than the original Prusa i3 MK2, I would suggest a adoption/merge/pull to add support to the MK42 heatbed from Prusa's firmware.

https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/

[andy-pi]

I agree with this. I couldn't work out how to use the prusa firmware with my i3 Mk2 clone (with Mk42 heatbed), couldn't seem to find how to set it up to connect to ramps 1.4. There seems to be much better community support for Marlin... I'm more of a python guy but brand new to 3d printing. So ... if anyone has any tips / starters I'm would like to have a go at adding mk42 support for the Prusa i3Mk2 clones with Ramps 1.4 boards.

[boelle]

@felixekman
we dont need any special support, it can be done just by selecting the correct settings

make sure that when you send G0 X0 Y0 after G28 that the nozzle is PRECISE in the 0,0 corner

these need to be correct:

#define X_PROBE_OFFSET_FROM_EXTRUDER 23  // X offset: -left  +right  [of the nozzle]
#define Y_PROBE_OFFSET_FROM_EXTRUDER 9  // Y offset: -front +behind [the nozzle]
#define Z_PROBE_OFFSET_FROM_EXTRUDER -0.26   // Z offset: -below +above  [the nozzle]

then

#define AUTO_BED_LEVELING_BILINEAR
#define GRID_MAX_POINTS_X 3
#define GRID_MAX_POINTS_Y GRID_MAX_POINTS_X
#define LEFT_PROBE_BED_POSITION 35
#define RIGHT_PROBE_BED_POSITION 238
#define FRONT_PROBE_BED_POSITION 7
#define BACK_PROBE_BED_POSITION 202.4

at least on my printer that makes the probe hit the 9 probe points.

the numbers should be pretty close but you might need to play a bit with it

[boelle]

on the other hand, prusa does more than just probing for these points, the do a search where they go back and forth over a point while move the bed, i think this is to "search" for the precise center of each point

and they also do it from a bit up first so it only triggers over the points where there is more copper and hence the probe will still triggere here even thou higher up

[brandstaetter]

The calibration point detection changed massively over the last Prusa firmware iterations. The current one does some really sophisticated stuff.

[boelle]

yes, but could we not be even as sophisticated? or is it a lot of work to hack out what they did and put it in marlin?

[michielbaird]

I have a MK42 board I'd like to use in a non-prusa setup. So I've been looking around into perhaps doing this. There are some cool things happening here. The "sophisticated stuff" is all in how the skew, rotation and shift off center is calculated.
From and operational point of view, it'd need to store 6 additional floats in configuration and add a new option in the skew/unskew code.

• Two 2d correction vectors for x and y for rotation and skew
• The position of the actual center, used to calculate the shift

Is there anyone I can talk to to get a better feel of the naming conventions and how you structure your features? Or should I give it a go and have fix things up during code review?

[boelle]

@michielbaird i think @thinkyhead is the one to talk to, but he is busy as hell so maybe just submit a PR against bugfix 2.0 and see what happens

[michielbaird]

I've spent some time digging, my time is limited during the week, but here is what I have found so far.

The Prusa code and the Marlin code has diverged quite a bit. Once the vectors are calculated the are fairly easy to use. In the Prusa code, however, during the calibration they disable the stepper interrupts altogether and manually toggle the pins.

This is done so that they can directly move the probe laterally in X and Y and stop immediately when the Z Pinda probes triggers or un-triggers (used to find the edges of the pad). The commits are not documented super well so navigating it has been a bit tricky.

I don't think this approach is necessary. G38.3 actually provides most of the functionality I need. But I think I'd also need G38.5.

Is there a reason G38.X it is disabled for CORE machines?

[thinkyhead]

Is there a reason G38.X it is disabled for CORE machines?

There may be some legacy reason that it couldn't work, but AFAIK it should work now.

[michielbaird]

I think I am going to start by adding G38.{4,5}

[boelle]

i see your initial work has been added

have you done more work since then?

[boelle]

@michielbaird any news on this one?

[michielbaird]

I started on this, was a tricky to translate given how Prusa directly toggles the pins which is not great for a generic implementation. Then life got in the way. I need to rethink this. My need for this has decreased somewhat but I still want to do it at some point.

[alromh87]

@boelle Looking for MK42 support on marlin I saw you where interested on getting it done, haven't been able to find out if it's implemented already and most of the info I find is pre 2020, so I did like to ask, is it already working out should I take a look into getting it done, I just updated my MK2 so I have a spare MK42 to get it done.

[thisiskeithb]

Automatic skew correction with MK42/52 beds has not been implemented yet.

[alromh87]

Seems like a non trivial task but I will deep into it, will start on
https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/mesh_bed_calibration.cpp

Report back when I have something

[3d-gussner]

@alromh87 Look at the MK3 branch instead the MK2 (old) https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/mesh_bed_calibration.cpp there are also forks that support the MK42 bed.
Or better Buddy firmware https://github.com/prusa3d/Prusa-Firmware-Buddy as that is based on Marlin 2.x and the MK3.5 still uses the PINDA