<p>So I discovered that the fade height must have been set to something really off.</p>
<p>I didn't know this at the time so I thought I should set the fade height to the default 10 mm just to make sure nothing was wrong and tested it. The printer now levels and compensates perfectly!</p>

CC BY-SA 4.0
2021-08-15T17:33:14.820Z
Thanks for coming back and provide an answer. It appears that not setting the fading height in firmware recently causes these problems indeed, see e.g. [this question](https://3dprinting.stackexchange.com/q/16793/).
0scar
CC BY-SA 4.0
2021-08-15T21:01:53.597Z
It's not that the fade height was not set in the firmware, it was set to something really low making the printer not compensate because the unleveled bed is out of the fade height range but I get what you mean. M420 Z[fade height] fixed it.
Artichoke
CC BY-SA 4.0
2021-08-15T07:36:31.277Z
2021-08-15T12:29:07.263Z
2021-08-15T12:29:07.263Z
Artichoke
<p>I am not the best with firmware modifications or anything like that, but you could try running your printer through OctoPrint and do the bed leveling through that and maybe that might fix the problem that you are facing.</p>

CC BY-SA 4.0
2021-06-02T21:19:38.590Z
OctoPrint is an interface to the printer controller board, if the board/firmware doesn't work, this won't work either.
0scar
CC BY-SA 4.0
2021-06-02T20:29:43.620Z
2021-06-02T21:20:05.477Z
2021-06-02T21:20:05.477Z
alexjshepler
<p>There is something not correct in your configuration file.</p>
<p>You mention the use of an upgraded controller board from an MKS GEN L to a MKS GEN L v2.1.</p>
<blockquote>
<p>...the original was MKS Gen L v1.0 , the new one was an MKS Gen L v2.1...</p>
</blockquote>
<p>This change of hardware is not effectively present in your configuration.h file, it currently states the use of the old board:</p>
<pre><code>// Choose the name from boards.h that matches your setup
#ifndef MOTHERBOARD
  #define MOTHERBOARD BOARD_MKS_GEN_L
#endif
</code></pre>
<p>You should have used the board constant called <code>BOARD_MKS_GEN_L_V21</code>.</p>
<p>I honestly don't know if this could fix your problem, but at least all correct pins are then loaded and could help you start searching for the problem.</p>

CC BY-SA 4.0
2021-06-06T06:37:16.097Z
2021-08-15T16:02:19.017Z
2021-08-15T16:02:19.017Z
0scar
<p>I have the exact same printer and had the same issue using the same probe. What fixed it for me was adding a <code>M420 S1</code> after <code>G29</code>.</p>

CC BY-SA 4.0
2021-06-06T07:37:31.530Z
That should already be active if you look at the `G29` G-code sources. But, worth a try I have seen this also on a very old Marlin version happening.
0scar
CC BY-SA 4.0
2021-06-06T06:39:06.750Z
2021-06-06T07:36:29.383Z
2021-06-06T07:36:29.383Z
snug
<p>Make sure <code>RESTORE_LEVELING_AFTER_G28</code> is uncommented in <code>configuration.h</code>.</p>

CC BY-SA 4.0
2022-02-26T04:02:17.510Z
Could you please explain what this does and why it should be done?
agarza
CC BY-SA 4.0
2022-02-27T00:04:54.513Z
I fixed this problem long ago. The problem was the fade height was set wrongly causing the machine to apply no Z compensation.
Artichoke
CC BY-SA 4.0
2022-02-25T23:45:43.340Z
2022-02-26T00:06:57.187Z
2022-02-26T00:06:57.187Z
steve
<p>I have a BLTouch clone (3DTouch) on my printer (Artillery Sidewinder X1). I installed it on the printer ages ago and has been working fine since. Recently, I did a BTT smart filament sensor upgrade.</p>
<p>I updated and edited both the Marlin firmware and the MKS TFT28 screen firmware to get it to work with the smart filament sensor. The filament sensor runs through the screen not the motherboard so it is enabled in screen firmware instead.</p>
<p>The sensor works fine and every other part of the printer is fine as well, except that after the BLTouch does a <code>G29</code> (I have it do that before every print in my start G-code, followed by an <code>M500</code>), It will not adjust the Z-axis to compensate for the unevenness of the bed. I can see the Z motors not move and I cannot feel the lead screws rotate in my hand if I touch my hand against them.</p>
<p>I have been through several other forums, videos, etc. on the internet but none of them have the same problem as me and/or their solutions do not fix the problems.</p>
<p>I have also tried flashing the display with the original firmware, which did not work so I guess is that I have something wrong with the firmware.
I have checked and double-checked my firmware but maybe there is something I missed or do not know about that could be causing my problem.</p>
<p>Firmware can be found <a href="https://github.com/Smartich0ke/Artillery-Sidewinder-X1-firmware" rel="nofollow noreferrer">here.</a></p>
<hr />
<p><em>I have tried running the original firmware with changes only made to enable the BLTouch. The Z-axis does still not compensate.</em></p>
<hr />
<p><em>I have also replaced the mainboard. I don’t know if that could affect the operation or not.</em></p>
<hr />
<p><em>Recently, I needed to print a part so I put the default Marlin firmware using the Artillery SWX1 example in Marlin's collection of examples with modifications made only to work with the BLTouch. I can post this copy of the firmware but it is probably identical to the GitHub repo below. This way I could just print with no Z compensation, however, now whenever I try to home the printer or do a <code>G29</code>, the BLTouch doesn't deploy and it will crash into the bed. I posted an unlisted video on YouTube demonstrating the issue <a href="https://www.youtube.com/watch?v=lyyazOalsc8" rel="nofollow noreferrer">here</a>. Also note that in the video, I attempt to move the Z-axis by 1 mm, but instead, the stepper motors spin at full speed and the gantry comes zooming towards the bed.</em></p>
<hr />
<p><em>I tried flashing the firmware yet again and for some reason, the BLTouch worked. it could home is and to a probing routine. I have been using the printer without the compensation and it works fine but it is really bizarre that this is happening. I know it is unlikely to solve the problem, but I am thinking of purchasing a replacement BLTouch. They are only 20 bucks to replace and I did accidental slightly bend the plastic probe before the Z stopped compensating. So is it possible the BLTouch is cactus?</em></p>
<hr />
<p><em>So recently, I noticed when running a G29 T through Octoprint or Pronterface, etc. that the printer will return a set of numbers for each probing point. Does this indicate that the BLTouch has taken the measurements but the printer will not use them to compensate the bed?</em></p>
<p>I have tried all the answers below.</p>

CC BY-SA 4.0
2021-05-28T06:09:54.393Z
Does anybody have an idea of what is wrong? Do I need to add more information? If so please let me know what I should add.
Artichoke
CC BY-SA 4.0
2021-06-04T10:19:20.570Z
Is the board exactly the same board (type, brand) you replaced the original with? I hope you are aware of the original 1.1.9 Marlin based firmware at https://github.com/artillery3d/sidewinder-x1-firmware?
0scar
CC BY-SA 4.0
2021-06-04T22:02:20.960Z
No, the original was MKS Gen L v1.0 , the new one was an MKS Gen L v2.1 .
Artichoke
<z-axis><bltouch><z-probe><3dtouch><artillery-sidewinder-x1>
BLTouch type sensor Z not compensating
Artichoke
# BLTouch type sensor Z not compensating

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

I have a BLTouch clone (3DTouch) on my printer (Artillery Sidewinder X1). I installed it on the printer ages ago and has been working fine since. Recently, I did a BTT smart filament sensor upgrade.

I updated and edited both the Marlin firmware and the MKS TFT28 screen firmware to get it to work with the smart filament sensor. The filament sensor runs through the screen not the motherboard so it is enabled in screen firmware instead.

The sensor works fine and every other part of the printer is fine as well, except that after the BLTouch does a `G29` (I have it do that before every print in my start G-code, followed by an `M500`), It will not adjust the Z-axis to compensate for the unevenness of the bed. I can see the Z motors not move and I cannot feel the lead screws rotate in my hand if I touch my hand against them.

I have been through several other forums, videos, etc. on the internet but none of them have the same problem as me and/or their solutions do not fix the problems.

I have also tried flashing the display with the original firmware, which did not work so I guess is that I have something wrong with the firmware.
I have checked and double-checked my firmware but maybe there is something I missed or do not know about that could be causing my problem.

Firmware can be found [here.](https://github.com/Smartich0ke/Artillery-Sidewinder-X1-firmware)

---

*I have tried running the original firmware with changes only made to enable the BLTouch. The Z-axis does still not compensate.*

---

*I have also replaced the mainboard. I don’t know if that could affect the operation or not.*

---

*Recently, I needed to print a part so I put the default Marlin firmware using the Artillery SWX1 example in Marlin's collection of examples with modifications made only to work with the BLTouch. I can post this copy of the firmware but it is probably identical to the GitHub repo below. This way I could just print with no Z compensation, however, now whenever I try to home the printer or do a `G29`, the BLTouch doesn't deploy and it will crash into the bed. I posted an unlisted video on YouTube demonstrating the issue [here](https://www.youtube.com/watch?v=lyyazOalsc8). Also note that in the video, I attempt to move the Z-axis by 1 mm, but instead, the stepper motors spin at full speed and the gantry comes zooming towards the bed.*

---

*I tried flashing the firmware yet again and for some reason, the BLTouch worked. it could home is and to a probing routine. I have been using the printer without the compensation and it works fine but it is really bizarre that this is happening. I know it is unlikely to solve the problem, but I am thinking of purchasing a replacement BLTouch. They are only 20 bucks to replace and I did accidental slightly bend the plastic probe before the Z stopped compensating. So is it possible the BLTouch is cactus?*

---

*So recently, I noticed when running a G29 T through Octoprint or Pronterface, etc. that the printer will return a set of numbers for each probing point. Does this indicate that the BLTouch has taken the measurements but the printer will not use them to compensate the bed?*

I have tried all the answers below.

**Tags:** z-axis, bltouch, z-probe, 3dtouch, artillery-sidewinder-x1
> **Comments:**
> **username_0**: Does anybody have an idea of what is wrong? Do I need to add more information? If so please let me know what I should add.  
> **username_1**: Is the board exactly the same board (type, brand) you replaced the original with? I hope you are aware of the original 1.1.9 Marlin based firmware at https://github.com/artillery3d/sidewinder-x1-firmware?  
> **username_0**: No, the original was MKS Gen L v1.0 , the new one was an MKS Gen L v2.1 .  

---

## 5 answers

### Answer by username_0 on 2021-08-15. Score: 1 | Accepted answer

So I discovered that the fade height must have been set to something really off.

I didn't know this at the time so I thought I should set the fade height to the default 10 mm just to make sure nothing was wrong and tested it. The printer now levels and compensates perfectly!

> **Comments:**
> **username_1**: Thanks for coming back and provide an answer. It appears that not setting the fading height in firmware recently causes these problems indeed, see e.g. [this question](https://3dprinting.stackexchange.com/q/16793/).  
> **username_0**: It's not that the fade height was not set in the firmware, it was set to something really low making the printer not compensate because the unleveled bed is out of the fade height range but I get what you mean. M420 Z[fade height] fixed it.  

---

### Answer by username_2 on 2021-06-02. Score: 1

I am not the best with firmware modifications or anything like that, but you could try running your printer through OctoPrint and do the bed leveling through that and maybe that might fix the problem that you are facing.

> **Comments:**
> **username_1**: OctoPrint is an interface to the printer controller board, if the board/firmware doesn't work, this won't work either.  

---

### Answer by username_1 on 2021-06-06. Score: 1

There is something not correct in your configuration file.
You mention the use of an upgraded controller board from an MKS GEN L to a MKS GEN L v2.1.

...the original was MKS Gen L v1.0 , the new one was an MKS Gen L v2.1...

This change of hardware is not effectively present in your configuration.h file, it currently states the use of the old board:
// Choose the name from boards.h that matches your setup
#ifndef MOTHERBOARD
  #define MOTHERBOARD BOARD_MKS_GEN_L
#endif

You should have used the board constant called BOARD_MKS_GEN_L_V21.
I honestly don't know if this could fix your problem, but at least all correct pins are then loaded and could help you start searching for the problem.


---

### Answer by username_3 on 2021-06-06. Score: 1

I have the exact same printer and had the same issue using the same probe. What fixed it for me was adding a `M420 S1` after `G29`.

> **Comments:**
> **username_1**: That should already be active if you look at the `G29` G-code sources. But, worth a try I have seen this also on a very old Marlin version happening.  

---

### Answer by username_4 on 2022-02-25. Score: 0

Make sure `RESTORE_LEVELING_AFTER_G28` is uncommented in `configuration.h`.

> **Comments:**
> **username_5**: Could you please explain what this does and why it should be done?  
> **username_0**: I fixed this problem long ago. The problem was the fade height was set wrongly causing the machine to apply no Z compensation.  

---

