Cannot correct bed skew - M852 disabled

[krcm0209]

See: https://forum.prusaprinters.org/forum/assembly-and-first-prints-troubleshooting/bed-skew/

In order provide more options for correcting print issues, especially with the Mini which is a cantilevered design, I believe that M852 should be properly supported in the Prusa Firmware to correct for bed skew.

The XZ-axis assembly of my Mini is tight and flush with the aluminum extrusion of the bed frame, so I cannot think of a reason that I would be experiencing XY skew unless there is a warp defect on the printed part(s) at the bottom of the XZ-axis assembly. Right now I think the hard fix would be to loosen the XZ-axis assembly from the Y-axis assembly and gradually shim it until the skew is gone, but this seems like a band-aid solution.

[geoper2]

Same problem here. Even though the parts of the printer are screwed together as shown in the guide there is an error in all axes. Shimming is a temporary fix and this feature must be enabled since its crucial!

[ntmaster26]

I am also having this issue....

[pelanj]

I have the issue as well - on a 100 mm square the diagonals are off by 0.6 mm. The misalignment cannot be seen by eye, but can be measured and is large enough to matter with construction parts. I will try mechanical adjustement by shims. On my other non-prusa printer I am able to print perfect squares.

[olistrik]

I also have this issue, the skew is bad enough to cause issues with hinges and large multi-print objects.

Until skew compensation is implemented you might find Gskewer useful. In Prusa slicer there is a section for post-processing scripts in "Print Settings" -> "Output options", it can be used there to automatically correct all your slices. Edit: There is bug when using prusa slicer, Gskewer doesn't allow for the negative gcode parameters used for the filament purge line at the beginning of the print. I have fixed this and made a pull request from this branch if you need this to work now. Edit 2: This has now been merged.

Alternatively if you use OctoPrint, I am currently in the process of implementing Gskewer as a plugin as I couldn't find an alternative. I haven't tested it yet so there might be bugs, I'll be finishing it up over the next couple of days. Edit: It works now for the prints that I have tested.

[kiesel-electronics]

I have the same issue. My printer is out by ablout 1.5mm.

[flxs]

Also having this issue, I'd like to use the Mini to print housings, and anything larger than approx. 3x3cm just won't fit because of bed skew. Can't seem to get it aligned with shims, it's always either too little or too much.

[Iqwertz]

I have the same issue and there seem to be no fixes - hardware as well as software wise so it would be greate if some correction could be implemented! For now it would be greate to be able to manually adjust the xy skew!

[OccasionalThingMaker]

Same issue here. It makes it impossible to print multi part prints.

[flxs]

As I read it, the original issue was talking about XY skew, not XZ skew. I'm seeing XY skew myself, i.e. printing a flat square on the hotbed turns out as a parallelogram when looked upon from above. My Mini has no measurable XZ skew, so at least for me, that procedure doesn't fix the issue.

[krcm0209]

Here is the link to manually calibrating xz skew: https://help.prusa3d.com/en/article/xz-axis-skew-correction-mini_158518 Power off, Slide hotend to one end of x-axis that is lowest, manually adjust z to a known thickness (I use a 2mm thick gauge), slide to opposite end, use above link to adjust to same height (2mm in my case). … On Mon, May 3, 2021 at 2:09 PM OccasionalThingMaker < @.***> wrote: Same issue here. It makes it impossible to print multi part prints. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#385 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQKHUZS53WHVUDBVK3MCUEDTL4GEDANCNFSM4MQEKNTA .

This issue is about XY skew, not XZ skew.

[matthewlloyd]

I need this too. On my brand new factory-assembled Mini+, after printing a calibration square from https://www.thingiverse.com/thing:4140075/files, I'm seeing XY skew on the order of 1%. My diagonals measure 111.84mm and 112.70mm. That's fine for printing benchies and whistles but I was hoping to use this for parts that require some precision.

I could easily adjust for this in software if M852 was enabled. Instead, I will have to partially dismantle and reassemble the machine tediously, perhaps several times, to fix something that I paid Josef Prusa extra to have correct out of the box. To make things worse, I can't enable M852 in the firmware myself without breaking the appendix to install my own custom firmware build, thereby voiding the warranty and reducing resale value.

I don't understand why this isn't enabled by default given that the Mini is inherently, by nature of its physical design, prone to skew. All it would take is uncommenting these lines in include/marlin/Configuration_A3ides_2209_MINI.h:

//#define SKEW_CORRECTION
...
// Enable this option for M852 to set skew at runtime
//#define SKEW_CORRECTION_GCODE

Looking at what this does (adds an unskew method to the planner, which performs 3 additions and 3 multiplications), this would add an extremely small amount of binary size and performance overhead to the firmware.

[olistrik]

@matthewlloyd You may find that goSkew, octoprint-gskewer, or gSkewer may temporarily fix your issues.

I have another year of warranty left but I'm of half a mind to break the appendix and see if uncommenting that definition is enough. There has to be a reason they haven't enabled it, but given this issue hasn't had any comment from a developer in the year it's been open, I'm guessing they don't know either.

[matthewlloyd]

@Kranex Please let us know how it goes if you decide to do that. I might end up doing it too, there are too many features I'd like to add to the firmware (e-steps in EEPROM for the Bondtech extruder, add simple file upload capability using the OctoPrint API, turn off display when idle, and now skew correction.)

There has to be a reason they haven't enabled it

Not to be cynical, but I do notice that skew compensation is enabled in the firmware of the more expensive MK3S.

[olistrik]

Actually, I think the the mk3s can do it automatically. The mini has the hardware to do it afaik, the XY frame has the same magnets in seemingly specific locations. Then again, maybe they're just the magnets for the print bed.

[drhouse82]

Actually I think close to every Mini has this xy skew issue!

My preassembled Mini had it. I put it into service. After it was repaired, it still had significant skew. (Even the test prints done during service that prusa shipped back with the printer were skewed... So my bad assembly is not the reason for it). I returned it for refund and got a new one. Same story (opposite sign though)... I think a (at least manual) skew correction is crucial for a printer that has obvious design shortcomings in xy axis alignment...

[olistrik]

@drhouse82 It wouldn't surprise me, honestly I'd be more surprised if there was one that didn't have XY skew. I have to recalibrate goSkew whenever I change print heads. I try my best not to bend the Y arm, but it still shifts a little even so. I also need to recalibrate if I move the printer.

[matthewlloyd]

Broke my appendix today - it was a pain to do this sufficiently carefully to avoid damaging the board and I am really not happy with Prusa about having had to do that. Installing custom firmware also sent me back through the setup wizard and reset my live Z offset.

However, I have successfully turned on skew correction and reenabled EEPROM settings in Marlin. They were trivial and work just fine.

Patches:

• Enable skew correction: https://gist.github.com/matthewlloyd/1c5b38c7e2146eef0ee20530807dfbbc
• Enable EEPROM settings: https://gist.github.com/matthewlloyd/341907f5c20790371c3ca2df4426639b

Be cautious with the skew correction - if you set values that are too high, the X and Y axes may crash off the sides.

[krcm0209]

@matthewlloyd Thanks for taking one for the team on voiding the warranty (so to speak). I hope that your gists help get the Buddy firmware team the push they need to get this addressed. Would submitting a PR be an option for you?

[matthewlloyd]

Would submitting a PR be an option for you?

Until Prusa changes its current attitude towards open source, I am not really inclined to contribute to the main repo. At the bare minimum they need to comply with GPLv3 and release the source code for the bootloader, and it would be nice to see them put the appendix into "reverse impulse" too. The appendix doesn't violate GPLv3 in letter, but certainly in spirit.

In any case, on closer inspection of the source, it is clear that removing Marlin EEPROM settings was a deliberate choice, for simplicity, and so that all the settings are under the control of the Prusa GUI code. I expect not enabling skew correction was also deliberate, since it's too easy to end up with crashes if you put in the wrong settings. My guess is their philosophy is it's only worth doing for the Mini+ if they can make it foolproof , like the rest of the GUI, which is impressively easy to use for a 3D printer. That will require a lot more work for skew, though other things (e.g. e-steps for Bondtech) should be quite easy. They want to actively discourage and prevent users from tweaking and experimenting, because it creates support overhead and costs for them when less proficient users can't debug the issues they create for themselves. I don't think a simple PR on this would get merged.

Hopefully someone will start an unofficial community fork that adds many of the features more advanced users would want.

[matthewlloyd]

Anyone following this issue may be interested to know that I just released custom firmware that turns on skew compensation in Marlin and allows it to be configured directly through the Settings menu or with M852, amongst other goodies:

http://github.com/matthewlloyd/Llama-Mini-Firmware#readme

[krcm0209]

@matthewlloyd I'm curious and tempted to switch to your firmware. What are your plans for maintenance if any? I understand if you can't dedicate a lot of time to it, but do you feel it would be relatively easy to port in updates Prusa makes to the official firmware over time? Cheers.

[matthewlloyd]

@krcm0209 It should be easy to port in updates because I kept Llama's code and EEPROM settings as separate as possible from the official firmware. I am planning to release updates on the heels of Prusa's own releases, at least as long as I own a Prusa Mini+.

If the escapee llama turns out to be a covert operative sent by Prusa and I get e-llama-nated, the code is all open source so someone else can easily take over. It'll always be trivial to switch back to the official firmware since I added a menu option to ask the bootloader to allow a firmware downgrade, and you can do this without losing your original Prusa EEPROM settings.

[jrsall92]

Are there any plans to natively fix this? @matthewlloyd 's branch goes up to 4.3.3-Final and we're at 4.3.4, any plans to release a patch for it? Or can we just merge your source in to 4.3.4 compile and voila?

[espr14]

Are there any plans to natively fix this? @matthewlloyd 's branch goes up to 4.3.3-Final and we're at 4.3.4, any plans to release a patch for it? Or can we just merge your source in to 4.3.4 compile and voila?

Here's 4.3.4 with skew and other improvements: https://github.com/Llama-FW/Llama-P32-FW/releases Version 4.4.0 will come later (~770 000 lines added/changed).

[Prusa-Support]

Thank you all for your input. Unfortunately, there have been fewer firmware updates recently due to the big efforts put into rewriting firmware and bootloader, while working on the Wi-Fi module compatibility, and yet there is much work to do.

Our developers could consider this feature request in future firmware developments.

Michele Moramarco Prusa Research

[nobodyguy]

I don't understand the feature prioritization logic. What's the point of (optional) wifi functionality when I'm not able to print correctly?

[Prusa-Support]

I don't understand the feature prioritization logic. What's the point of (optional) wifi functionality when I'm not able to print correctly?

Not sure I understand. We expect regular users to be able to print correctly without the use of codes, and to refer to the official support in case of problems.

Unfortunately, we don't have an estimated time for the implementation of this code but the issue will remain open for our developers to look into this.

Michele Moramarco Prusa Research

[espr14]

I don't understand the feature prioritization logic. What's the point of (optional) wifi functionality when I'm not able to print correctly?

WiFi is used in MK4 and XL as well but skew calibration is for (low cost) MINI only because new print heads don't have the PINDA probe. So the priority is low. Unfortuantelly, enabling skew compensation is an easy task but it's not there. Currently, you can use unofficial FW with skew compensation enabled.

https://github.com/Snake-FW/P32-FW

[qp0n4ik]

That ridiculous that I have to edit and recompile firmware to use the skew correction every new release

[olistrik]

skew calibration is for (low cost) MINI only because new print heads don't have the PINDA probe.

The probe doesn't matter. The original probe had issues with the temperature of the printbed causing bad readings. But that didn't cause skew, that just completely wrecked the bed leveling. The new SuperPinda fixed that.

All the printers can suffer from skew, but it's more likely (basically guaranteed in my experience) in the Mini because only one side of the print axis is supported. Oddly though, the MK2 through MK3s+ all have automatic XYZ skew calibration even though they arguably need it less.

That ridiculous that I have to edit and recompile firmware to use the skew correction every new release

What's more ridiculous is you have to break the appendix, void your warranty, and potentially break the board to use your own fork of a GNU GPLv3 licenced firmware. This firmware isn't in the spirit of the GPLv3, and it's "open-source" for marketing purposes only.

If you don't want to be breaking any appendixes, I mentioned it earlier, but goSkew is a post processing software I made to compensate for this kind of skew. I won't be supporting it once I have the space for a different printer, but hopefully a ticket as mundane as this can be fixed after four years.

[Prusa-Support]

I'm afraid this is going a bit off the topic. No worries though, our forum is available for open discussions. https://forum.prusa3d.com/

Back to the issue. Our developers have a tight schedule and busy development plans but won't ignore this and the many other feature requests out there. They will look into this consistently with the company goals.

For the time being, in case of problems setting down a good first layer - and for general help with genuine Prusa hardware, design, and firmware - please refer to our Customer Support.

Michele Moramarco Prusa Research

[ivnrpi]

It has been 3 years, you could implement this feature already but the Prusa doesn't care about people with this issue, I had to spend time looking for solutions and modifying the firmware myself

[Prusa-Support]

Hello @ivnrpi, thank you for your feedback, and sorry that this made it a negative experience. Sadly, I wouldn't be able to guarantee this would be implemented in the future, although we can certainly correct a skew issue hardware-wise. If you are experiencing issues, can you please reach me via email info@prusa3d.com mentioning me, so that we can take a look at it with some pictures, and find a way to resolve the skewing issue? We can certainly achieve printer squaring hardware-wise.

Alessandro Pantaleo Prusa Research

[espr14]

HW calibration is good but not so precise. Enabling of M852 would take few minutes, adding a menu for XYZ correction would take tens of minutes. You can place it to experimental menu so there's no need to create a documentation for this. But the major hurdle is decision to do it.

[Prusa-Support]

This is an Open Source system. The firmware is open and the community can cooperate or make custom builds out of it. We can't promise this will be implemented unfortunately but our comments above still apply: our developers will stick to their current development plans and think about this.

On a side note, despite being lightweight, the MINI doesn't require frequent geometry tweaking. The average user is expected to solve this at the hardware level only once - except for long transportations, major manipulations or so... I don't want some parts to be cracked, deformed, or simply loose.

In case of persistent first layer and calibration problems, please contact our Support. For open discussions, please visit our official forum.

Michele Moramarco Prusa Research

[Czarnyszarf]

we'll , I was looking for fork of 5.1.2 firmware with this command enabled , anyone knows about it?

[espr14]

Working on this.

[qp0n4ik]

we'll , I was looking for fork of 5.1.2 firmware with this command enabled , anyone knows about it?

There was a Llama firmware but unfortunately, he stopped updating it, sad

[espr14]

Snake FW 5.1.0.1 with skew correction is here: https://github.com/Snake-FW/P32-FW/releases

[Raymogon]

I also want this for the XL, mine has XY-Skew of about 0.18° making diagonals about 0.3mm off

[Prusa-Support]

Please don't underestimate possible hardware correction but I see your point and I'll gladly check back with the developers.

.

About Prusa XL.

Tightening the right Y-axis rail reduces the space between the CoreXY Front Left and the X-axis on the right side but creates space on the left side, and vice versa.

https://help.prusa3d.com/article/adjusting-belt-tension-xl_401793 You may want to review the X-axis alignment. However, we may be looking at a hardly noticeable inconsistency.

Michele Moramarco Prusa Research

[Czarnyszarf]

Well, it is kinda simple solution to fix a problem.

There is no guide to fix XY skew for example on mini

[Prusa-Support]

No, unfortunately, there is no guide to compensate for XY skew on the MINI's hardware - this is not explained in the Squaring your MINI Help article. However, the process would supposedly be similar to the other hardware skew corrections.

The user can try to repeat the connection between XZ-axis and the Y-structure. For reference, please check steps 13 to 20 here.

Loosen the 3x bolts holding the Y assembly together with the XZ assembly. Observe with one eye if the X rods are parallel with the printed grid on the heatbed. If not try to compensate for it by very gently twisting the XZ or slightly rotating the X-axis while re-tightening the 3x bolts.

Also, ensure the proper alignment of the electronics box (check the notch), and that no cable or debris is stuck between the electronics box and the extrusion rod. Take this chance to check if the printed electronics box is well squared.

Michele Moramarco Prusa Research

[qp0n4ik]

Broke my appendix today - it was a pain to do this sufficiently carefully to avoid damaging the board and I am really not happy with Prusa about having had to do that. Installing custom firmware also sent me back through the setup wizard and reset my live Z offset.

However, I have successfully turned on skew correction and reenabled EEPROM settings in Marlin. They were trivial and work just fine.

Patches:

• Enable skew correction: https://gist.github.com/matthewlloyd/1c5b38c7e2146eef0ee20530807dfbbc

• Enable EEPROM settings: https://gist.github.com/matthewlloyd/341907f5c20790371c3ca2df4426639b

Be cautious with the skew correction - if you set values that are too high, the X and Y axes may crash off the sides.

For some reason links doesn't work any more

[espr14]

Author archived his repository but you can get to the last releases still: https://github.com/matthewlloyd/Llama-Mini-Firmware/releases

I've started where he ended and I continue with the FW: https://github.com/Snake-Edition/P32-FW/releases

[caitlynb]

Has there been any effort on Prusa's part to incorporate skew correction as a default feature in their firmware? My XL gantry is badly skewed, and its not being corrected by the homing sequence.
I am trying to work with support, but I feel we are going in circles.

[Raymogon]

Has there been any effort on Prusa's part to incorporate skew correction as a default feature in their firmware? My XL gantry is badly skewed, and its not being corrected by the homing sequence. I am trying to work with support, but I feel we are going in circles.

I have contacted the Prusa Support about 6 months ago because of the same issue. Haven't got any good answers, the only option I currently use is GoSkew : https://github.com/olistrik/goskew which works pretty decent. But it is a bit of work because u have to modify every GCode file with it but the results are very good.

[espr14]

@caitlynb In coreXY (Prusa XL) the gantry skew is all about belt tension. If you move the gantry to the end of the Y axis (to back of Prusa XL) both sides have to hit the end. If there's a gap (play) on the (let's say) right side, you have to loose the belt on the right side and/or tighten the belt on the left side by using the front bolts on Prusa XL. If this is not enough then you have to adjust length of the belts. In Prusa XL it's somewhere in the X carriage. Unfortunatelly, I haven't found any manual how to do that. If this is done properly, then you don't need to adjust XY skew in firmware.