Z motors won't go negative past zero with BLTouch firmware

PROBLEM: Any action which requires Z Home hangs.

X home, Y home, move X/Y +/- all work fine.

Home * also works correctly, until the negative Z move is supposed to start; It does move X+4, home X, home Y, then stops.

I thought I wired something wrong, but here’s the weird part, Move Z+ and Move Z- both work, as long as the Z value does not try to go below zero. I can move it up as high as I want from the LCD, and move it all the way back down. Once Z=0, pressing Z- does nothing. I can still exit the screen and do other things. It just refuses to go lower than zero. In terms of failure, this is probably one of the more desirable outcomes, because the alternative is that it ignores the safety settings and crashes into the bed, or worse :fire:

As far as the sensor goes, it pushes, stows, and self-tests correctly when triggered from the LCD. It lights up red at first, and if I tap it during a test it turns blue.

Maybe I wired it wrong? I followed the guide https://community.advi3pp.com/t/add-a-bltouch-sensor/21.
I wired it exactly as pictured in step 4; EXT 1,9,10. ZProbe 2,3. One thing I wasn’t sure about was whether to leave the Z-min plugged in?
I flashed to ADVi3pp-HE180021-Mainboard-4.0.6.hex which allowed me to level the bed and print the BLTouch mount.


  • Printer: Monoprice Maker Select Plus V2 (I don’t know what the V2 means, it’s just what Monoprice’s site said when I ordered it. I haven’t actually seen it reference anywhere, and there’s no obvious difference between my printer and the ones I’ve seen on this site.
  • Mainboard: Wanhao V5.1. Probably model 15711?
  • LCD: DMT48270M043_02WT
  • ADVI3PP Firmware
    • LCD: ADVi3pp-LCD-4.0.6.img.zip
    • Mainboard: ADVi3pp-BLTouch-Mainboard-4.0.6.hex

Pictures of diagnosis and versions screens. Both seem to exactly the same whether the z-min is plugged in, and whether the version is with or without bltouch support. Should I try 4.0.5?

Diagnosis_Z-Min_unplugged Versions

Just found this post here: Z-axis will not home

This is because you have a wiring problem or a fault on your board.

Sounds about right, I’m shit with a soldering iron. Assuming I got the cables in the right order but just bad connections, did I miss anything else? Which wire is likely the problem?

Thank you for your detailed description of your problem and hardware (this is often not the case). However, there is something missing: information about your BLTouch. Which version do you have (there are many) and are you sure it is genuine (there are a lot of fake ones)?

Do you have a link to this printer? I look at Monoprice website and was not able to find it.

This is strange because this is the wrong firmware.

Are you sure? Do you have a picture of your mainboard?

You can but I think it will change nothing. It is not a problem with the firmware.

Depending of your version of BLTouch, this could be wrong.

The white one. Please provide some pictures please.

OOPS! I used ADVi3pp-BLTouch-Mainboard-4.0.6.hex. Still trying to figure out what’s what.

BLTouch is classic, not smart/v2 holy hell today is not a good day for me. It IS the BLTouch Smart V3.1

Here’s the mainboard before I took it out of the printer.

I didn’t take any pictures of it after soldering, but I struggled hard with the black wire. It’s surprising that it’s not the black wire, but white makes sense too.
Rather than taking the front panel off, I ordered a microSD extension cable which I’ll stick to the outside. When it comes in I’ll get pictures of the wiring to fully embarrass myself, and see if I can do a better job. Maybe I can bribe someone into doing it for me.

I looked through my order history with Monoprice, it’s not V2. I just can’t read.

So you took the wrong firmware. Please try with the firmware for BLTouch 3 or higher (BLTOUCH3)

heh. Oops.

I loaded
ADVi3pp-HE180021-BLTouch3-Mainboard-4.0.6.hex and
Same exact experience on each (When deployed manually, the probe stays out and the bltouch lights up blue. When attempting to home Z, it goes out then in and stops responding to Z inputs). Bad solder is sounding more and more plausible, but I don’t feel like taking the printer apart again today, and I also can’t stop fiddling with it :smiley:

I was curious if there’s any sort of debug in ADVI3PP? Is there actually a difference between the various build numbers? I found a list of Marlin commands. M928 was able to write a zero byte file to disk, but octopi terminal complained about a checksum and didn’t actually write anything. M43 doesn’t appear to be recognized.

So I did what any curious user would do, and flashed CleanEEPROM.ino.with_bootloader.mega.hex.
Then I did what any smart person would not do, and rebooted the printer. Probably shouldn’t have done that.

The screen displays the first frame of the boot animation and does a quick bltouch test, and that’s it. Running screen /dev/ttyUSB0 115200 says


and won’t respond to input (or I don’t know how to send input over serial USB).
dmesg shows

[    7.264724] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[    7.399986] usb 1-1.2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.62
[    7.400071] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    7.400135] usb 1-1.2: Product: USB2.0-Serial
[    9.936559] ch341 1-1.2:1.0: ch341-uart converter detected
[    9.971660] usb 1-1.2: ch341-uart converter now attached to ttyUSB0

To be clear, I know I fucked up. Any help would be appreciated, but I’m mostly documenting this because I had already settled on trashing this printer and buying a Prusa, and because I don’t like leaving threads unsolved.

Edit: I gotta say, anyone doubting whether to hop on this train should absolutely not be afraid. Damn near every scenario is covered and documented. I was able to recover from bricked back to usable by flashing the source via the alternative flashing methods. I’m extremely comfortable with what I’m doing here, but there’s no way I would have figured this out without andrivet’s research. Definitely worth the subscription.

Still wish I could get BLTouch working without soldering though.

Edit 2: I found the instructions for compiling in vs code with platformio. When I do home *, this is interesting:

echo:enqueueing "G28 F6000"
echo:busy: processing
echo:busy: processing
echo:busy: processing
Error:STOP called because of BLTouch error - restart with M999
Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
X:123.00 Y:137.00 Z:4.00 E:0.00 Count X:9840 Y:10960 Z:1600

Oh no, I’ve awakened something in myself. I’m having more fun than I planned.

Please do not load random firmware. HE180021 firmwares are NOT for your printer. You may DAMAGE your printer by doing this.

Which build numbers?

There is not much memory in the microcontroller of this printer. So it is not possible to support all possible Marlin commands.

Following your last message (Error:STOP called because of BLTouch error), you probably have a soldering issue.

Right, I got tripped on the filenames and loaded HE180021 on accident.
Can I recommend changing the naming convention so that the files sort more logically? Just swappaing the BLTouch-Mainboard positions would make it much cleaner.



Recv: Error:STOP called because of BLTouch error - restart with M999
Changing monitoring state from "Operational" to "Error: STOP called because of BLTouch error - restart with M999"
Send: M112
Send: N2 M112*35
Send: N3 M104 T0 S0*34
Send: N4 M140 S0*97
Changing monitoring state from "Error: STOP called because of BLTouch error - restart with M999" to "Offline (Error: STOP called because of BLTouch error - restart with M999)"
Connection closed, closing down monitor

no change after re-soldering the wires. I’m pretty sure I burned up the solder point on the board for z-probe pin 3. That’s just ground right? Can I put that somewhere else?

The probe has power. I’ll look through the source (thanks for that btw :smiley:), but maybe I can recompile to use the z-stop wires pins instead of the z-probe pins?.
Nope BLTouch wired through original Z endstop

In the User Manual, there is a table describing precisely which file is for which printer:
I think it is clear enough so I will not change the file names.

This could explain your problems. Do you have a multimeter to check if it is connected?


There are other ground points on the board. Like Z end-stop #1.

I put a full description of the board here:

Power is through the red and brown wires.

You can try, but it is far from ideal because of capacitors on the board (to reduce noice).

I’ve got a multimeter, not sure how to use it to check connectivity on the different pins.

Orange: servo moves, so that’s probably fine.
Brown/red: bltouch lights up red/blue when it’s supposed to, so those are probably fine too.
Black: One end on the bltouch and the other just connectivity test to any other ground?

The white one is probably fine too, but just out of curiosity, one end on the bltouch and the other on the ATMega PA3?

Should the board have power when I do this? What do I set the multimeter to?

I’m seriously impressed with the amount of work that you’ve put into this from development, release, and support perspectives. You’re a hero.

No. You can damage your board.

Continuity test. But if you do not know how to do that, it is better to avoid doing this.

I’m familiar enough with a multimeter to be comfortable with a continuity test. It’s the other modes I’m clueless about.

Black wire has continuity all the way from the bltouch board to the PSU. So the problem must be the white wire.

There’s no continuity between the solder point on the board and P3 on the ATMega. I think I burned it up :frowning:

I figure at this point I have some choices:

  1. Buy a new board. Obviously I can look on ebay, but is there an “official” place for replacement parts? What if I put a completely different board? I’ve seen things like “replace the Melzi board” (not sure what that is exactly). Feel free to ignore this, I’m just using you as a Rubber Duck.
  2. Fork the github and recompile to put the white wire somewhere else. Unless you’ve done that in a branch already - I haven’t looked.
  3. Can a solder point be “repaired”? Can I solder it directly to the ATMega? Seems like a bad idea and a quick way to solution 1.

Also, my comment about the naming conventions was because “BLTouch-Mainboard” sorts differently in the filesystem than “Mainboard-BLTouch” so my severe ADHD literally did not see it.

Finally, I don’t like that the red light stays on all the time. Can the light be “turned off” when it’s not being used to level the printer? I’m tempted to snip it and install a physical switch.

It looks like, unfortunately.

There are several around the world. So it is mainly dependent of where you are living. An example in the USA: Wanhao Duplicator i3 Plus 3D Printer Parts - Mother Board, Main Board – Ultimate 3D Printing Store

This is wrong. I do not know why but several people are thinking that Wanhao is using a Melzi board for this printer. They do not. They build their own motherboard. A Melzi board is this: Melzi - RepRap

Simply put, it will not work. There are too many differences between boards. You can somehow make it work with another board but you will have to find another firmware, be sure voltages are compatible, etc. Some people have done this after burning their motherboard (the MOSFETs).

This is possible and not very difficult. However, I choose this probe pin on purpose: there is no capacitor on it. If you use another pin, there is maybe a capacitor (in order to reduce noice) and it may not work well with BLTouch 3 or higher. I think there is no capacitor for the EXT pins.

It really depend of the damages on the board. It looks difficult to solder on the ATMega. If you burn it, it is game over.

I don’t think so. Never thought about it before.

In conclusion, I would recommend solution #2 and use one of the pins on the EXT connector. Something like pin #3 (PC1, Arduino #36). I explain in a document how to compile the sources yourself:

To change the pin location, it is in pins_I3_PLUS.h: Z_STOP_PIN.

Don’t hesitate to ask me if you have some troubles.

Frankly, before spending money on a new board, it is worth trying to use another pin.

It worked! :grin:

I used pin 5 because it was as far away from anything else as I could get so I wouldn’t risk also damaging pin 1.
#define Z_STOP_PIN 34 // PC3 / AD11

Also had to use the ‘reset sensor’ button; I could manually set the z-height and go all the way down, but it wouldn’t stick and go right back up to what it thought was zero. Every time I went into the leveling menu it would move z+4. Eventually it got so high I it bumped the top of the printer frame and I was afraid it would get damaged.

Haven’t printed anything yet, but that’s a separate topic.


I am not sure to understand. Is it working now, or not?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.