[HELP] BLTouch failing despite no obvious installation flaws #562

Open
opened 2025-01-06 19:15:46 -06:00 by marvellousmarvolo · 8 comments
marvellousmarvolo commented 2025-01-06 19:15:46 -06:00 (Migrated from github.com)

Bug Description

I installed an original BLTouch unit closely following the instructions in the wiki and yet I can't get it working.
Up until the second test everything seems fine. The automatic self test on boot (pin moves up and down, red glow) works as expected. But when I launch the auto leveling from the special menu, the pin doesn't extend and the nozzle crashes into the print bed.

Steps to Reproduce

I routed the servo wires like in the pictures below. The order (+, -, S) looks correct to me.

image
image

I mounted the signal pin headers on holes G1 (black) and G3 (white) while bridging H3 and H4 ("alternative wiring"). There don't seem to be any obvious shorts or unwanted contacts (even under the plastic pin header frame).

image
image
image

I installed firmware version MEGA_S_DGUS_TMC_BLT_11_v1.5.4.hex because my printer is an Anycubic Mega S with DGUS-clone screen, upgraded stepper motors and most probably has a V1.1 board according to the placements of parts and servo port descriptions.
Executing the M280 P0 S10 command to extend the BLTouch pin does nothing.

image

Is there anything obvious I have missed? Anything left to try?
Maybe do the conventional pin header install?

Thanks in advance!

### Bug Description I installed an original BLTouch unit closely following the instructions in the wiki and yet I can't get it working. Up until the second test everything seems fine. The automatic self test on boot (pin moves up and down, red glow) works as expected. But when I launch the auto leveling from the special menu, the pin doesn't extend and the nozzle crashes into the print bed. ### Steps to Reproduce I routed the servo wires like in the pictures below. The order (+, -, S) looks correct to me. ![image](https://github.com/user-attachments/assets/901cb490-1b5d-425b-b263-fadcdd4f5cd7) ![image](https://github.com/user-attachments/assets/34981cc8-3cac-4bb2-8f7c-c76865474902) I mounted the signal pin headers on holes G1 (black) and G3 (white) while bridging H3 and H4 ("alternative wiring"). There don't seem to be any obvious shorts or unwanted contacts (even under the plastic pin header frame). ![image](https://github.com/user-attachments/assets/0df9442c-e449-4858-ac37-d4a6254aa51e) ![image](https://github.com/user-attachments/assets/dec4bdf1-bf45-4128-a8e2-1f51c92f8533) ![image](https://github.com/user-attachments/assets/a7a70471-92a2-4501-a9b3-d03d03b39530) I installed firmware version `MEGA_S_DGUS_TMC_BLT_11_v1.5.4.hex` because my printer is an Anycubic Mega S with DGUS-clone screen, upgraded stepper motors and most probably has a V1.1 board according to the placements of parts and servo port descriptions. Executing the `M280 P0 S10` command to extend the BLTouch pin does nothing. ![image](https://github.com/user-attachments/assets/454b3a17-2a63-4400-b2da-55f5b044f5b2) Is there anything obvious I have missed? Anything left to try? Maybe do the conventional pin header install? Thanks in advance!
knutwurst commented 2025-01-07 01:06:55 -06:00 (Migrated from github.com)

Hi @marvellousmarvolo ,
Are you absolutely sure that you have a Trigorilla 1.1 board? This is clearly stated on the Trigorilla logo on the board. Only if it says 1.1 do you need to use the _11 firmware. In all other cases you need the _10 firmware.

I can't see any other (obvious) error at the moment.

Your printer looks good, by the way :) You've processed everything cleanly. It's also great that you've included photos in the bug ticket. That really helps a lot. :)

Olli

Hi @marvellousmarvolo , Are you absolutely sure that you have a Trigorilla 1.1 board? This is clearly stated on the Trigorilla logo on the board. Only if it says 1.1 do you need to use the _11 firmware. In all other cases you need the _10 firmware. I can't see any other (obvious) error at the moment. Your printer looks good, by the way :) You've processed everything cleanly. It's also great that you've included photos in the bug ticket. That really helps a lot. :) Olli
marvellousmarvolo commented 2025-01-07 06:18:10 -06:00 (Migrated from github.com)

Hi Olli,
thanks for the compliment! Although I would be happier if the printer worked just as well as it apparently looks... 😅

As for the firmware, I also tried out the _10 version, but everything behaved exactly the same. No pin extension followed by a crash into the build plate.

Sadly, the board version marker is covered by a cooling assembly that was already installed, when I got the printer. If really necessary I can take it out and double check but there were some dead giveaways that this is infact V1.1, like the servo ports (PS, S1, S2), the smaller wire clamps for power and the top of the copyright symbol peeking out.

IMG_20250107_011739692~2
IMG_20250107_011655535~2
IMG_20250106_185202703~2

Could the BLTouch itself be the issue? I ordered this one which appears to be v3.1.

Hi Olli, thanks for the compliment! Although I would be happier if the printer worked just as well as it apparently looks... 😅 As for the firmware, I also tried out the _10 version, but everything behaved exactly the same. No pin extension followed by a crash into the build plate. Sadly, the board version marker is covered by a cooling assembly that was already installed, when I got the printer. If really necessary I can take it out and double check but there were some dead giveaways that this is infact V1.1, like the servo ports (PS, S1, S2), the smaller wire clamps for power and the top of the copyright symbol peeking out. ![IMG_20250107_011739692~2](https://github.com/user-attachments/assets/3ca605c2-f0c9-46da-8e1f-903287faf748) ![IMG_20250107_011655535~2](https://github.com/user-attachments/assets/a8d720e2-c2fe-4298-bb11-7923f3d54724) ![IMG_20250106_185202703~2](https://github.com/user-attachments/assets/6258b030-374d-4e53-9493-fc0fb28abef6) Could the BLTouch itself be the issue? I ordered [this one](https://de.aliexpress.com/item/1005006210601045.html) which appears to be v3.1.
stklcode commented 2025-01-07 08:17:31 -06:00 (Migrated from github.com)

From the position of the T in the triangle is could be a 1.1 or a 0.0.3 (though a "v0" should be visible below). So my guess would be the same.

But it looks like it’s just one screw to uncover the version number. Or simply flash a _10 build, if it works, good, otherwise it wont break anything, just switch back. Both faster than guessing around.

From the position of the T in the triangle is could be a 1.1 or a 0.0.3 (though a "v0" should be visible below). So my guess would be the same. But it looks like it’s just one screw to uncover the version number. Or simply flash a `_10` build, if it works, good, otherwise it wont break anything, just switch back. Both faster than guessing around.
marvellousmarvolo commented 2025-01-07 08:21:54 -06:00 (Migrated from github.com)

From the position of the T in the triangle is could be a 1.1 or a 0.0.3. But it looks like it’s just one screw to uncover the version number. Or simply flash a _10 build, if it works, good, otherwise it wont break anything, just switch back. Both faster than guessing around.

Thanks for your input!
Unfortunately, as I have mentioned in my previous comment, I already tried flashing a _10 firmware with absolutely no difference in behaviour.

> From the position of the T in the triangle is could be a 1.1 or a 0.0.3. But it looks like it’s just one screw to uncover the version number. Or simply flash a `_10` build, if it works, good, otherwise it wont break anything, just switch back. Both faster than guessing around. Thanks for your input! Unfortunately, as I have mentioned in my previous comment, I already tried flashing a `_10` firmware with absolutely no difference in behaviour.
knutwurst commented 2025-01-07 08:43:43 -06:00 (Migrated from github.com)

So if the sensor itself lights up, the power supply must be ok. As long as it lights up (and doesn't flash) everything is good so far. The signal on the S pin is needed to move the pin in and out. As I said, the version of the mainboard is crucial here, as the PWM signal is for the servo (or in this case the BL-Touch pin).

Would it be possible for you to try an older firmware version? (The last 1.3.x or 1.4.x). I have to admit that it is theoretically possible that a bug crept in when upgrading to the new Marlin version, even though almost everything has always been tested. Trigorilla 1.1 boards are rare and therefore not fully tested.

By the way, when I look at the layout of the servo connections, it really looks like a 1.1. But with green terminals. That's new to me too :)

So if the sensor itself lights up, the power supply must be ok. As long as it lights up (and doesn't flash) everything is good so far. The signal on the S pin is needed to move the pin in and out. As I said, the version of the mainboard is crucial here, as the PWM signal is for the servo (or in this case the BL-Touch pin). Would it be possible for you to try an older firmware version? (The last 1.3.x or 1.4.x). I have to admit that it is theoretically possible that a bug crept in when upgrading to the new Marlin version, even though almost everything has always been tested. Trigorilla 1.1 boards are rare and therefore not fully tested. By the way, when I look at the layout of the servo connections, it really looks like a 1.1. But with green terminals. That's new to me too :)
marvellousmarvolo commented 2025-01-07 16:15:45 -06:00 (Migrated from github.com)

Ok, so to clear up the mystery once and for all, I removed the cooling assembly to reveal the board logo. It is indeed a rare V1.1.

IMG_20250107_215010847

I also tried out the firmwares 1.4.8 and 1.3.1 (latest patch versions each), but still no difference. The BLTouch reacts to neither the auto leveling nor to commands entered via pronterface.

I don't know whether this is relevant or not, but I also noticed, that the red LED switches off when I manually pull out the probe. In some videos I have seen that instead a blue LED should turn on, is that correct?

IMG_20250107_212832454
IMG_20250107_231337265

Ok, so to clear up the mystery once and for all, I removed the cooling assembly to reveal the board logo. It is indeed a rare V1.1. ![IMG_20250107_215010847](https://github.com/user-attachments/assets/8ba818cc-fc58-42f4-b96c-6e49b8ec353f) I also tried out the firmwares 1.4.8 and 1.3.1 (latest patch versions each), but still no difference. The BLTouch reacts to neither the auto leveling nor to commands entered via pronterface. I don't know whether this is relevant or not, but I also noticed, that the red LED switches off when I manually pull out the probe. In some videos I have seen that instead a blue LED should turn on, is that correct? ![IMG_20250107_212832454](https://github.com/user-attachments/assets/a18d1c93-d35f-477f-be0d-fe90c1a10a74) ![IMG_20250107_231337265](https://github.com/user-attachments/assets/35911184-2c7d-474e-98fc-01433b489dee)
marvellousmarvolo commented 2025-01-10 15:42:03 -06:00 (Migrated from github.com)

@knutwurst could it be that the servo pinout is somehow incorrect? According to this diagram of the V1.1 board the pin order is 11 4 6 5 instead of 5 4 11 6.

@knutwurst could it be that the servo pinout is somehow incorrect? According to [this diagram](https://www.thingiverse.com/thing:3680634) of the V1.1 board the pin order is `11 4 6 5` instead of `5 4 11 6`.
stklcode commented 2025-01-11 03:14:31 -06:00 (Migrated from github.com)

Rightmost in the diagram is S0, so S0 S1 S2 S3 is 11 6 5 4 for 1.0 and 5 6 4 11 for 1.1

That does not match, but in either case S0 = 5 is used for the BLT on 1.1

Hard to tell if that’s incorrect. You could measure on you board or build FW versions with BLT on Servo 1/2/3 to find out which pin is actually attached...

Order in fir FW (upstream Marlin) was never changed, guess someone might have noticed if Servo 0 was incorrect (1-3 are rarely used, those might be wrong)

6734173854/Marlin/src/pins/ramps/pins_TRIGORILLA_14.h (L34-L39)
6734173854/Marlin/src/pins/ramps/pins_RAMPS.h (L65-L80)

Rightmost in the diagram is S0, so `S0 S1 S2 S3` is `11 6 5 4` for 1.0 and `5 6 4 11` for 1.1 That does not match, but in either case `S0 = 5` is used for the BLT on 1.1 Hard to tell if that’s incorrect. You could measure on you board or build FW versions with BLT on Servo 1/2/3 to find out which pin is actually attached... Order in fir FW (upstream Marlin) was never changed, guess someone might have noticed if Servo 0 was incorrect (1-3 are rarely used, those might be wrong) https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/blob/6734173854f7718539f8d0d200ef338660a7e755/Marlin/src/pins/ramps/pins_TRIGORILLA_14.h#L34-L39 https://github.com/knutwurst/Marlin-2-0-x-Anycubic-i3-MEGA-S/blob/6734173854f7718539f8d0d200ef338660a7e755/Marlin/src/pins/ramps/pins_RAMPS.h#L65-L80
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wp/Marlin-2-0-x-Anycubic-i3-MEGA-S#562
No description provided.