<p>It is very common that FDM 3D printers "home" their position at the start of each print (as defined by the slicers preprint g-code). This is done by deliberately running the end effector towards its expected X=0, Y=0 position until it hits the endstop switches for each axis. Could it be this behaviour you are seeing? If so, I would suggest checking that your endstops are functioning correctly.</p>

<p>You can manually activate this homing action using the G-code <a href="http://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29" rel="noreferrer">G28</a> in (for instance) <a href="http://www.pronterface.com/" rel="noreferrer">Pronterface</a>. Alternatively, you can verify that your endstops are actually working using the <a href="http://reprap.org/wiki/G-code#M119:_Get_Endstop_Status" rel="noreferrer">M119</a>-command while pressing each switch manually. </p>

CC BY-SA 3.0
2016-10-25T15:16:08.153Z
Could the axis get inverted somehow? Because instead of taking it all the way to the stop, it's taking it in the opposite direction when it starts?
R0b0tn1k
CC BY-SA 3.0
2016-10-25T15:17:16.770Z
Just found something. I was reconfiguring the Z leveling, and it's changed the behavior a bit. Now the X axis is doing the screeching, even though it's not gone off chart?
R0b0tn1k
CC BY-SA 3.0
2016-10-27T07:22:37.880Z
If you axes are going reveresed, the that certainly is something you should fix! :-) However, when you say "screeching", do you still mean the sound in the video, or just a high-pitched sound from when the motors are powered and standing still? In general, as long as stepper motors are powered (that is, they resist movement if you try to move them manually), they will often make a high pitched noise. You can try to run [M18](http://reprap.org/wiki/G-code#M18:_Disable_all_stepper_motors) to disable all stepper motors, and see it that helps.
Tormod Haugene
CC BY-SA 3.0
2016-10-31T20:58:00.447Z
No, this is the sound in the video, excuse my english. How would you call that sound? I tested the endstops, and as mentioned they work. Any other ideas on how to fix the issue?
R0b0tn1k
CC BY-SA 3.0
2016-11-01T15:19:06.953Z
@R0b0tn1k, did you figure out if it happens as part og the G28 homing command? Watching the video over again, it really looks like the endstop for the bed isn't cutting the stepper drive, so that it continues to force the bed outside it's limits. I'm guessing what you are hearing is the stepper motor or some gear constantly skipping as a result.
Tormod Haugene
CC BY-SA 3.0
2016-11-05T20:58:55.933Z
It's definitely a part of the homing command..
R0b0tn1k
CC BY-SA 3.0
2016-11-05T21:00:10.887Z
However, I pressed the triggers manually, and they work. So i'm at a loss as to why this happens. If the triggers dont trigger, then the horrible sound would continue forever. So it does hit that stop at some point?!?
R0b0tn1k
CC BY-SA 3.0
2016-11-05T21:01:08.320Z
I'm thinking it's trying to go outside of the configured build bed (150x150x150). Actually, i'm not sure at this point. If it were to go outside of 150, the trigger would trigger? :)
R0b0tn1k
CC BY-SA 3.0
2016-11-05T21:26:41.273Z
If working correctly, the triggers should absolutely prevent the printer from going beyond the physical bed limits. :-) This is also what it tries to do when homing the bed, but the motors should stop immediately after hitting the triggers. Could it be that the carriages don't hit the endstops correctly? The reason why is stops after a while is because it will be ordered to move to some point beyond its limits when homing, but it is never actually expected to reach that point as it should trigger the endstops first. ;-) Side question, could a software lag be the issue?
Tormod Haugene
CC BY-SA 3.0
2016-11-06T19:26:33.977Z
How do I check for software lag? This did not happen before I went on vacation. After I came back it went crazy...
R0b0tn1k
CC BY-SA 3.0
2016-11-06T19:50:19.670Z
Btw, whole thing is working on OctoPi
R0b0tn1k
CC BY-SA 3.0
2016-11-11T12:40:55.487Z
Ok, I seem to be noticing a bit of lag in Octopi when I press certain commands. Any cure?
R0b0tn1k
CC BY-SA 3.0
2016-12-05T16:26:10.600Z
@R0b0tn1k lag can come physically and digitally. Physical lag (although unlikely) can come from excessively long cables (USB, RJ45, etc). Digital lag can come from a number of sources. Double check that you have the minimum set of applications running in the background. Try to free up CPU and RAM usage as much as possible. Are you running true OctoPi or just OctoPrint on a PC?
tbm0115
CC BY-SA 3.0
2016-10-23T17:34:01.623Z
2016-10-23T17:34:01.623Z
Tormod Haugene
<p>I have a strange problem with my Printrbot Simple Metal.</p>

<p>When I start printing it's suddenly trying to go off axis before starting to print. All is fine once it actually starts to print, but it's very annoying to hear the sound on the start and end of each print.</p>

<p>That can't be good on the motors and chains either, something is going to give out at some point.</p>

<p>Here's what that sounds like: <a href="https://youtu.be/R8-FxeC6OoM" rel="nofollow noreferrer">YouTube - IMG 5600</a>.</p>

<p>My OctoPi settings are: </p>

<p><a href="https://i.sstatic.net/2Qlas.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2Qlas.png" alt="OctoPi settings"></a></p>

<calibration>
Printrbot going off axis when initializing
R0b0tn1k
# Printrbot going off axis when initializing

(Asked by: username_0 on 2016-10-23)

I have a strange problem with my Printrbot Simple Metal.

When I start printing it's suddenly trying to go off axis before starting to print. All is fine once it actually starts to print, but it's very annoying to hear the sound on the start and end of each print.

That can't be good on the motors and chains either, something is going to give out at some point.

Here's what that sounds like: [YouTube - IMG 5600](https://youtu.be/R8-FxeC6OoM).

My OctoPi settings are:

[![OctoPi settings](https://i.sstatic.net/2Qlas.png)](https://i.sstatic.net/2Qlas.png)

**Tags:** calibration

---

## 1 answers

### Answer by username_1 on 2016-10-23. Score: 4

It is very common that FDM 3D printers "home" their position at the start of each print (as defined by the slicers preprint g-code). This is done by deliberately running the end effector towards its expected X=0, Y=0 position until it hits the endstop switches for each axis. Could it be this behaviour you are seeing? If so, I would suggest checking that your endstops are functioning correctly.

You can manually activate this homing action using the G-code [G28](http://reprap.org/wiki/G-code#G28:_Move_to_Origin_.28Home.29) in (for instance) [Pronterface](http://www.pronterface.com/). Alternatively, you can verify that your endstops are actually working using the [M119](http://reprap.org/wiki/G-code#M119:_Get_Endstop_Status)-command while pressing each switch manually.

> **Comments:**
> **username_0**: Could the axis get inverted somehow? Because instead of taking it all the way to the stop, it's taking it in the opposite direction when it starts?  
> **username_0**: Just found something. I was reconfiguring the Z leveling, and it's changed the behavior a bit. Now the X axis is doing the screeching, even though it's not gone off chart?  
> **username_1**: If you axes are going reveresed, the that certainly is something you should fix! :-) However, when you say "screeching", do you still mean the sound in the video, or just a high-pitched sound from when the motors are powered and standing still? In general, as long as stepper motors are powered (that is, they resist movement if you try to move them manually), they will often make a high pitched noise. You can try to run [M18](http://reprap.org/wiki/G-code#M18:_Disable_all_stepper_motors) to disable all stepper motors, and see it that helps.  
> **username_0**: No, this is the sound in the video, excuse my english. How would you call that sound? I tested the endstops, and as mentioned they work. Any other ideas on how to fix the issue?  
> **username_1**: @R0b0tn1k, did you figure out if it happens as part og the G28 homing command? Watching the video over again, it really looks like the endstop for the bed isn't cutting the stepper drive, so that it continues to force the bed outside it's limits. I'm guessing what you are hearing is the stepper motor or some gear constantly skipping as a result.  
> **username_0**: It's definitely a part of the homing command..  
> **username_0**: However, I pressed the triggers manually, and they work. So i'm at a loss as to why this happens. If the triggers dont trigger, then the horrible sound would continue forever. So it does hit that stop at some point?!?  
> **username_0**: I'm thinking it's trying to go outside of the configured build bed (150x150x150). Actually, i'm not sure at this point. If it were to go outside of 150, the trigger would trigger? :)  
> **username_1**: If working correctly, the triggers should absolutely prevent the printer from going beyond the physical bed limits. :-) This is also what it tries to do when homing the bed, but the motors should stop immediately after hitting the triggers. Could it be that the carriages don't hit the endstops correctly? The reason why is stops after a while is because it will be ordered to move to some point beyond its limits when homing, but it is never actually expected to reach that point as it should trigger the endstops first. ;-) Side question, could a software lag be the issue?  
> **username_0**: How do I check for software lag? This did not happen before I went on vacation. After I came back it went crazy...  
> **username_0**: Btw, whole thing is working on OctoPi  
> **username_0**: Ok, I seem to be noticing a bit of lag in Octopi when I press certain commands. Any cure?  
> **username_2**: @R0b0tn1k lag can come physically and digitally. Physical lag (although unlikely) can come from excessively long cables (USB, RJ45, etc). Digital lag can come from a number of sources. Double check that you have the minimum set of applications running in the background. Try to free up CPU and RAM usage as much as possible. Are you running true OctoPi or just OctoPrint on a PC?  

---

