1. About
  2. Features
  3. Explore

I'm trying to line up the physical print bed of my printer (Printrbot Simple Metal) to the virtual print area of the slicer (Cura). So far, they've never been properly aligned. It was never that big a problem because, worst case scenario, my print would simply not be dead-center on the bed. But I've decided to try and fix it.

Here are pictures of a test model in Cura, and the resulting physical print:

model in Cura printed model

What's the proper way to align the two? It seems I just got lucky with the x-axis here (though note that the BuildTak surface is a bit off center). But obviously the y-axis needs fixing. The print needs to start a little lower, because print-head couldn't reach the highest point, and the y-axis motor slipped to compensate.

Ideally, the fixed parameters of the print bed size and offset would be set by the Marlin firmware (EEPROM?). But I also need to be able to do a little offset tweaking on the software side for when I need to replace the BuildTak mat.


Edit: I tried M206 (home offset) commands, but the result is definitely not what we want. I cancelled these early.

M206 Y-15 M206 Y15

The upper print has M206 Y-15, the lower print has M206 Y15. What seems to happen is that the coordinate system is not physically shifted. Instead, the area is 'cropped'. All filament that should go outside the boundaries is actually extruded 'on the edge', resulting in an ugly blob.

1 Answer 1

The problem you are experiencing is because the position where the y endstop is triggered does not correspond to y = 0, but perhaps corresponds to y = 15 (replace 15 by the offset you're seeing). You can perhaps solve this by adjusting the endstop to trigger at the correct point, but you can also adjust this behavior in software: In your start G-code, after the homing (G28) command, insert a G92 Y15 to tell the printer that the current position (reached after homing) is actually y = 15.

Another option is to use the M206 command to permanently store the offset in EEPROM (rather than needing to provide it in the start code each time).

If your printer moves towards max rather than min, the same applies, but consider that the offset may be caused by the bed size defined in your firmware not corresponding to the bed size set in your slicer.