<p>The problem you are experiencing is because the position where the y endstop is triggered does not correspond to <code>y = 0</code>, but perhaps corresponds to <code>y = 15</code> (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 (<code>G28</code>) command, insert a <code>G92 Y15</code> to tell the printer that the current position (reached after homing) is actually <code>y = 15</code>.</p>

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

<p>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.</p>

CC BY-SA 3.0
2016-06-12T17:12:18.057Z
Great answer Tom. Is this something seen very often, where the 'bounds' of the printer do not match the software? And what is the most common method for solving this problem? Thanks in advance.
J. Roibal - BlockchainEng
CC BY-SA 3.0
2016-06-12T17:53:45.497Z
Hi @Tom: I'd like to put this in EEPROM, but the `M206` command is not the way to go, it seems. I edited the question to show the results.
mhelvens
CC BY-SA 4.0
2018-10-02T07:13:28.733Z
I tried this solution (two years ago) and it failed. I attached pictures to show the result.
mhelvens
CC BY-SA 4.0
2018-10-28T07:06:49.380Z
@mhelvens Sadly you failed, but it is the solution. It is very easy to fix your problem with the solution presented. Alternatively read and execute the link I put in comments earlier. You do not necessarily need to print a square from the link, you could have measured the location of the first square of your failed print to update the bed position. All that is needed is to get the offsets from endstop positions to the corner of the bed.
0scar
CC BY-SA 4.0
2018-10-31T21:17:40.427Z
@0scar: I followed the instructions, and they did not fix the problem. You telling me that it is nonetheless the correct solution doesn't really change much. Reality wins. :-) I suppose it's possible you're right. Perhaps I made a mistake. But I can't accept the answer based solely on that possibility. And I'm afraid that printer is currently out of commission, long term, so I can't try anything new with it for the foreseeable future.
mhelvens
CC BY-SA 4.0
2018-10-31T22:24:48.700Z
@mhelvens Too bad the printer is out of commission and too bad you did not succeed. This is the solution for the problem, hence the link to a question (explaining a little more in detail) above in an earlier comment. We would have liked to help you out! Just edit your question once you are trying to get it to work and it will pop up for us to see it.
0scar
CC BY-SA 3.0
2016-06-12T16:16:18.623Z
2016-06-12T16:16:18.623Z
Tom van der Zanden
<p>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.</p>

<p><strong>Here are pictures of a test model in Cura, and the resulting physical print:</strong></p>

<p><a href="https://i.sstatic.net/JuYNG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/JuYNG.png" alt="model in Cura"></a>
<a href="https://i.sstatic.net/z2jB9.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/z2jB9.jpg" alt="printed model"></a></p>

<p>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.</p>

<p>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.</p>

<hr>

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

<p><a href="https://i.sstatic.net/8H6iu.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8H6iu.jpg" alt="M206 Y-15"></a>
<a href="https://i.sstatic.net/N2pL3.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/N2pL3.jpg" alt="M206 Y15"></a></p>

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

CC BY-SA 3.0
2016-06-12T15:11:49.790Z
I have not used cura software, but is there a 'calibration' function?
J. Roibal - BlockchainEng
CC BY-SA 3.0
2016-06-12T15:25:50.920Z
The word 'calibration' is usually used for the number of stepper-motor steps per mm, or bed-leveling (z-axis). That's what Cura uses that term for, anyway, and it doesn't look like it can play with the Firmware. (Also, Cura is not actually connected to my printer in any way. My printer runs from an OctoPrint server.) In any case, I know how to change the EEPROM values, but I don't know which values to change and how.
mhelvens
CC BY-SA 3.0
2016-06-12T15:52:02.750Z
If there were lines connecting the squares (horizontal and vertical) to make a grid, where would the error begin to be seen? May need to be tested.
J. Roibal - BlockchainEng
CC BY-SA 3.0
2016-06-12T15:59:49.830Z
Also--what if the upper-left most square (where the extruder is rattling) was lower (say, 2 cm), would the squares still become offset?
J. Roibal - BlockchainEng
CC BY-SA 3.0
2016-06-12T16:10:00.993Z
I recall experiencing a bug with Marlin, where the auto leveling feature can cause a shift in the axis positions. Basically, if the probing positions aren't symmetric with respect to the bed (e.g. you probe at y=20 and y=160 with a 200mm wide bed) it would offset the y axis. Changing the probe positions to be symmetric (e.g. y=40 and y=160 or y=20 and y=180) fixed this for me. If this turns out to be the issue I can add it to my answer.
Tom van der Zanden
<software><slicing><firmware><build-plate>
How to line up (x,y) print area between hardware and software?
mhelvens
# How to line up (x,y) print area between hardware and software?

(Asked by: username_0 on 2016-06-12)

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](https://i.sstatic.net/JuYNG.png)](https://i.sstatic.net/JuYNG.png)
[![printed model](https://i.sstatic.net/z2jB9.jpg)](https://i.sstatic.net/z2jB9.jpg)

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](https://i.sstatic.net/8H6iu.jpg)](https://i.sstatic.net/8H6iu.jpg)
[![M206 Y15](https://i.sstatic.net/N2pL3.jpg)](https://i.sstatic.net/N2pL3.jpg)

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.

**Tags:** software, slicing, firmware, build-plate
> **Comments:**
> **username_1**: I have not used cura software, but is there a 'calibration' function?  
> **username_0**: The word 'calibration' is usually used for the number of stepper-motor steps per mm, or bed-leveling (z-axis). That's what Cura uses that term for, anyway, and it doesn't look like it can play with the Firmware. (Also, Cura is not actually connected to my printer in any way. My printer runs from an OctoPrint server.) In any case, I know how to change the EEPROM values, but I don't know which values to change and how.  
> **username_1**: If there were lines connecting the squares (horizontal and vertical) to make a grid, where would the error begin to be seen? May need to be tested.  
> **username_1**: Also--what if the upper-left most square (where the extruder is rattling) was lower (say, 2 cm), would the squares still become offset?  
> **username_2**: I recall experiencing a bug with Marlin, where the auto leveling feature can cause a shift in the axis positions. Basically, if the probing positions aren't symmetric with respect to the bed (e.g. you probe at y=20 and y=160 with a 200mm wide bed) it would offset the y axis. Changing the probe positions to be symmetric (e.g. y=40 and y=160 or y=20 and y=180) fixed this for me. If this turns out to be the issue I can add it to my answer.  

---

## 1 answers

### Answer by username_2 on 2016-06-12. Score: 5

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.

> **Comments:**
> **username_1**: Great answer Tom. Is this something seen very often, where the 'bounds' of the printer do not match the software? And what is the most common method for solving this problem? Thanks in advance.  
> **username_0**: Hi @Tom: I'd like to put this in EEPROM, but the `M206` command is not the way to go, it seems. I edited the question to show the results.  
> **username_0**: I tried this solution (two years ago) and it failed. I attached pictures to show the result.  
> **username_3**: @mhelvens Sadly you failed, but it is the solution. It is very easy to fix your problem with the solution presented. Alternatively read and execute the link I put in comments earlier. You do not necessarily need to print a square from the link, you could have measured the location of the first square of your failed print to update the bed position. All that is needed is to get the offsets from endstop positions to the corner of the bed.  
> **username_0**: @0scar: I followed the instructions, and they did not fix the problem. You telling me that it is nonetheless the correct solution doesn't really change much. Reality wins. :-) I suppose it's possible you're right. Perhaps I made a mistake. But I can't accept the answer based solely on that possibility. And I'm afraid that printer is currently out of commission, long term, so I can't try anything new with it for the foreseeable future.  
> **username_3**: @mhelvens Too bad the printer is out of commission and too bad you did not succeed. This is the solution for the problem, hence the link to a question (explaining a little more in detail) above in an earlier comment. We would have liked to help you out! Just edit your question once you are trying to get it to work and it will pop up for us to see it.  

---

