<p>I know this is incredibly old at this point, but in case anyone stumbles upon this post like I did, I wanted to point out that there is no semicolon behind your G29 code, so it's not being read properly</p>

CC BY-SA 4.0
2020-12-04T16:04:52.787Z
This answer is incorrect, there is no need to put a semicolon behind the G-code; G-code is parsed by line where the semicolon denotes that everything after the semicolon needs to be discarded.
0scar
CC BY-SA 4.0
2020-12-08T04:18:26.040Z
You only need the semicolon if you'd like to leave a comment on the line.
kolosy
CC BY-SA 4.0
2020-12-04T15:58:42.233Z
2020-12-04T15:58:42.233Z
Infamous Inc
<p>The problem with the Tevo Tornado design is that the design is as such that the Z-axis is powered by a single stepper (under the assumption that you have not added a second Z stepper).</p>

<p>This means that the level relies on the rigidity of the X-axis assembly, more specific the play on the guide wheels. Apparently the BL-Touch level determination suffers (the up and down movement while probing) from this design as can be seen from the tilt around the Y-axis direction. This effect causing the tilted level plane is called <a href="https://en.wikipedia.org/wiki/Hysteresis" rel="nofollow noreferrer">hysteresis</a>. Now that the Z-axis moves up and down you experience much more problems than using a mechanical switch. The effect is more pronounced when the mass of the hot end carriage is furthest from the Z-axis lead screw.</p>

<p>Note that an extra stepper can also cause tilted level when the second stepper does not move in sync (e.g. missing steps). In such designs, a single stepper (geared) belt driven 2 lead screw has better performance in that respect.</p>

CC BY-SA 4.0
2019-05-16T13:22:50.120Z
So is that the solution then? Add a second stepper?
kolosy
CC BY-SA 4.0
2019-05-16T13:23:42.013Z
Also - wouldn't this effect be present during calibration too, making the whole thing compensate for this?
kolosy
CC BY-SA 4.0
2019-05-16T14:52:01.997Z
@kolosy The hysteresis causes the tilted plane and the effect is more pronounced the further from the lead screw. No, it will not compensate as it measured wrong due to the design and the movement during the determination of the bed level. Yes, a second stepper would be a solution, a belt driven second lead screw is even better. The single stepper/single lead screw designs are cheap, but low quality solutions for Prusa i3/portal style printer designs
0scar
CC BY-SA 4.0
2019-05-16T19:04:26.003Z
Do you have any links to details on how to upgrade to a belt driven second lead screw? Web searching for that gives results on belt driven instead of lead screw z axis.
T. M.
CC BY-SA 4.0
2019-05-16T19:33:27.083Z
@T.M. You could design your own. Or try [this mod](https://www.thingiverse.com/thing:2668969).
0scar
CC BY-SA 4.0
2019-05-16T07:18:08.413Z
2019-05-16T14:51:25.287Z
2019-05-16T14:51:25.287Z
0scar
<p>I have a Tevo Tornado that I've outfitted with an official BL-Touch auto level sensor. I can see the bed probing run, and I can see the Z axis slowly adjust during x/y moves, so it's doing <em>something</em>. However, you can see that there appears to be a systematic tilt:</p>

<p><a href="https://i.sstatic.net/sacY6.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sacY6.jpg" alt="BL-Touch tilted bed plane"></a></p>

<p>Any ideas what could be causing this? The bed, gantry and print head is tight, no wobble. Here's my start code:</p>

<pre><code>G28 ; home all axes
G29
G1 Z5 F5000 ; lift nozzle
</code></pre>

<p>I have mesh leveling enabled with a 5x5 grid and correct probe offsets. The bed itself is on PETG printed standoffs instead of springs to eliminate any jitter.</p>

CC BY-SA 4.0
2019-05-16T05:34:08.793Z
would be good to know how it was before you've installed BL device :) was it better or worse before? as i suppose it was better than it is so my first idea is that the "correction" your device is giving has the opposite direction so it roughly doubles the difference
darth pixel
CC BY-SA 4.0
2019-05-17T03:38:27.427Z
@darthpixel not sure why you think this made it worse, i made no mention of that. the behavior with the bltouch is better than manual calibration without.
kolosy
CC BY-SA 4.0
2019-05-20T08:58:07.493Z
i've said "as i suppose it was better..." as i supposed the problem "appeared" after installation of BL
darth pixel
<bed-leveling><bltouch>
BL-Touch bed leveling seems to produce tilted bed level around Y-axis
kolosy
# BL-Touch bed leveling seems to produce tilted bed level around Y-axis

(Asked by: username_0 on 2019-05-16)

I have a Tevo Tornado that I've outfitted with an official BL-Touch auto level sensor. I can see the bed probing run, and I can see the Z axis slowly adjust during x/y moves, so it's doing something. However, you can see that there appears to be a systematic tilt:

Any ideas what could be causing this? The bed, gantry and print head is tight, no wobble. Here's my start code:
G28 ; home all axes
G29
G1 Z5 F5000 ; lift nozzle

I have mesh leveling enabled with a 5x5 grid and correct probe offsets. The bed itself is on PETG printed standoffs instead of springs to eliminate any jitter.

**Tags:** bed-leveling, bltouch
> **Comments:**
> **username_1**: would be good to know how it was before you've installed BL device :) was it better or worse before? as i suppose it was better than it is so my first idea is that the "correction" your device is giving has the opposite direction so it roughly doubles the difference  
> **username_0**: @darthpixel not sure why you think this made it worse, i made no mention of that. the behavior with the bltouch is better than manual calibration without.  
> **username_1**: i've said "as i suppose it was better..." as i supposed the problem "appeared" after installation of BL  

---

## 2 answers

### Answer by username_3 on 2019-05-16. Score: 3 | Accepted answer

The problem with the Tevo Tornado design is that the design is as such that the Z-axis is powered by a single stepper (under the assumption that you have not added a second Z stepper).

This means that the level relies on the rigidity of the X-axis assembly, more specific the play on the guide wheels. Apparently the BL-Touch level determination suffers (the up and down movement while probing) from this design as can be seen from the tilt around the Y-axis direction. This effect causing the tilted level plane is called [hysteresis](https://en.wikipedia.org/wiki/Hysteresis). Now that the Z-axis moves up and down you experience much more problems than using a mechanical switch. The effect is more pronounced when the mass of the hot end carriage is furthest from the Z-axis lead screw.

Note that an extra stepper can also cause tilted level when the second stepper does not move in sync (e.g. missing steps). In such designs, a single stepper (geared) belt driven 2 lead screw has better performance in that respect.

> **Comments:**
> **username_0**: So is that the solution then? Add a second stepper?  
> **username_0**: Also - wouldn't this effect be present during calibration too, making the whole thing compensate for this?  
> **username_3**: @kolosy The hysteresis causes the tilted plane and the effect is more pronounced the further from the lead screw. No, it will not compensate as it measured wrong due to the design and the movement during the determination of the bed level. Yes, a second stepper would be a solution, a belt driven second lead screw is even better. The single stepper/single lead screw designs are cheap, but low quality solutions for Prusa i3/portal style printer designs  
> **username_4**: Do you have any links to details on how to upgrade to a belt driven second lead screw? Web searching for that gives results on belt driven instead of lead screw z axis.  
> **username_3**: @T.M. You could design your own. Or try [this mod](https://www.thingiverse.com/thing:2668969).  

---

### Answer by username_2 on 2020-12-04. Score: 1

I know this is incredibly old at this point, but in case anyone stumbles upon this post like I did, I wanted to point out that there is no semicolon behind your G29 code, so it's not being read properly

> **Comments:**
> **username_3**: This answer is incorrect, there is no need to put a semicolon behind the G-code; G-code is parsed by line where the semicolon denotes that everything after the semicolon needs to be discarded.  
> **username_0**: You only need the semicolon if you'd like to leave a comment on the line.  

---

