[BUG] Ender 3 Pro, BLTouch + SKR E3 Mini V2/3 not working when using pin PC14

[LazeMSS]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

I wrongly made this bug report (https://github.com/MarlinFirmware/Marlin/issues/23390) - this is the correct one.

Basically this is the problem - using the "config-not-working.zip" configuration to enable BL Touch on PC14:

//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define USE_PROBE_FOR_Z_HOMING
#define Z_MIN_PROBE_PIN PC14

The last part should be redudant as it is already set in the "pins_BTT_SKR_MINI_E3_common.h" #define Z_MIN_PROBE_PIN PC14 // PROBE

It compiles okay but the auto home (G28) is randomly working (sometimes the printer comes to a halt - sometimes it works). But when running UBL its get even more crazy - where it keeps probing the same point again and again - and octoprint reports a probing failed.

Tried the following:

• Turning BLTOUCH_HS_MODE on and off
• Turning SOFTWARE_ENDSTOPS on and off

The strange part is it works if I do the following: In "pins_BTT_SKR_MINI_E3_common" change: #define Z_STOP_PIN PC2 to #define Z_STOP_PIN PC14

And in configuration.h:

#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define USE_PROBE_FOR_Z_HOMING
//#define Z_MIN_PROBE_PIN PC14

Then everything works as expected

Bug Timeline

Found the bug in the prev. release and also in the bugfix

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

Marlin 2.0.9.3 - Dec 30 2021 11:00:34

Printer model

Creality Ender 3 Pro

Electronics

No response

Add-ons

No response

Bed Leveling

UBL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

OctoPrint

Additional information & file uploads

config-not-working.zip

[thinkyhead]

With PINS_DEBUGGING enabled and the M43 command do you see any conflicts involving that pin? If you send M119 repeatedly, do you see inconsistent results? Does increasing the ENDSTOP_NOISE_THRESHOLD have any effect?

[LazeMSS]

Sadly my board died - I will try when the new board arrives

[LMBernardo]

Check your cables - I had a very similar issue with my CRTouch until I unplugged the cable on both ends, and then plugged them both back in quite firmly.

[LazeMSS]

Check your cables - I had a very similar issue with my CRTouch until I unplugged the cable on both ends, and then plugged them both back in quite firmly.

If that was the problem then it should be a problem no matter what pin configuration etc

[LazeMSS]

I found this guide https://www.makenprint.uk/3d-printing/3d-firmware-guides/marlin/consolidated-marlin-guide/ - it has the same "fixes" I have found.

I bought the new SKR MINI E3 V3.0 board and it has the same problems - now building a firmware with PINS_DEBUGGING enabled and will provide the data asap.

[LazeMSS]

With PINS_DEBUGGING enabled and the M43 command do you see any conflicts involving that pin? If you send M119 repeatedly, do you see inconsistent results? Does increasing the ENDSTOP_NOISE_THRESHOLD have any effect?

When compiling with PINS_DEBUGGING i get this: `Compiling .pio\build\STM32G0B1RE_btt\src\src\gcode\control\T.cpp.o from Marlin\src\gcode\config\M43.cpp:29:

Marlin\src\gcode\config../../pins/../HAL/STM32/pinsDebug.h: In function 'int8_t digital_pin_to_analog_pin(pin_t)': Marlin\src\gcode\config../../pins/../HAL/STM32/pinsDebug.h:164:14: error: 'NUM_ANALOG_FIRST' was not declared in this scope; did you mean 'PNUM_ANALOG_BASE'?

164 | Ard_num -= NUM_ANALOG_FIRST; | ^~~~ | PNUM_ANALOG_BASE *** [.pio\build\STM32G0B1RE_btt\src\src\gcode\config\M43.cpp.o] Error 1`

And I just found this: https://github.com/MarlinFirmware/Marlin/pull/22896 :)

[LazeMSS]

@thinkyhead M119 seems to be pretty stable

[LazeMSS]

Here is a way to repeat it:

Clean marlin install with bltouch connected to z-probe input on the board (not the z-end stop) Z-offset configured to zero

Run autohome(G28)

• Nozzle goes to center, probe out, lowers z-axis. Triggers probe, up and down then triggers probe again. Z-axis returns to Z=10

Change Z-offset to -2.1 Nozzle is now perfect height to bed (paper method)

Then run autohome(G28) again:

• Goes to center, probe out, lowers z-axis. Triggers probe, up and down then triggers probe again. Z-axis returns to Z=10
• Display now shows "Endstops Z"

The nozzle is now back at same position as first autohome - so if i move the z-axis down to zero it is now 2.1 mm above the bed and not tight against the bed.

[LazeMSS]

Can now confirm that pin swapping fix works on SKR e3 Mini like I posted in the original post. It seems to either a marlin or mainboard error - somehow the priority of the z-endstop and the z-offset is confused when using the probe as endstop with the default pinouts.

[pandaboy6621]

I have this same problem with the PB1 (5.Pin Port) on my Stock Ender 3 Pro with the v4.2.2 board.

[meteoro]

I have same issue with "bltouch 3.1" and "skr mini e3 v2.0", change Z_STOP_PIN to PC14 and other settings like first post not solved the issue. And reverse in z-stop pin.

I make a test with M43 S and the test is complet 4 times but dont trigger pin on touch, i change ENDSTOP_NOISE_THRESHOLD for 2, 3, 4, 5, 6, 7... same problem.

I have test in z-probe PC14 and z-stop pin PC2, change the cable for another, two boards one in cr-10s and another in ender 3 pro.

Any idea? Thanks.

[GJSchaller]

Reporting the same issue, Ender 3 Pro, BTT SKR mini E3 v2, discussed w/ @ManuelMcLure in Discord chat. In my case, everything homes properly, but Bed Leveling Visualizer puts the entire bed about 2mm lower than Z=0. This only happened when I moved from using the Z Endstop port to the Z Probe port due to a change in cabling

.

[descipher]

Questions: Are all the CPUs GD32F103x chips? Is the BLTouch white signal pin in position 1 or 2 on the 5pin connector?

[GJSchaller]

Questions: Are all the CPUs GD32F103x chips? Is the BLTouch white signal pin in position 1 or 2 on the 5pin connector?

I'll need to open mine up - I'm using a Creality CR Touch cable, so the colors don't quite correspond, but I'll do my best to determine it via photos. As for the CPUs, can I easily tell by looking at the board? If not, is there another way to get that information? I do have Octoprint if I can pull data that way.

[pandaboy6621]

Questions: Are all the CPUs GD32F103x chips? Is the BLTouch white signal pin in position 1 or 2 on the 5pin connector?

I’m not sure what you mean about GD32F103x chips. I have an ender 3 pro with a 4.2.2 motherboard. Attached is a picture of the cable on my probe side.

[ellensp]

The main large black chip on the controller has a number written on it is probably one of these STM32F103 GD32F103 GD32F303 the gd chips are not supported in marlin

eg of a GD chip

[descipher]

I have a Creality 4.2.7 and no issues here with that exact config. It is an STM32F103RE on pin PB_1. BBT schematics show ground is on pin 2 of that connector. The black wire of the black and white pair is ground on the BLTouch. Creality uses an STM32F103 so that should rule out a clone issue.

[descipher]

People should avoid buying boards with clone STMs. It is supporting China's rogue STM market.

[descipher]

The BLTouch ground wire is not on frame ground inside the touch so it could work reversed but I would suspect a noise problem would surface. So make sure its not reversed. PC_14 is a odd pin in that it is a low power oscillator input so its a special case where it can be defined as an alternate function but there isn't a handler in Arduino for it. Also I am not sure the 4.2.2 board issue is actually the same problem as the BBT Mini E3. My intuition leans me towards hardware issues so that's why the "is it a clone or not".

[descipher]

@GJSchaller Did you say you did a teardown setup and then saw this issue? Also did you do a firmware update at the same time? Are you able to go back to say 2.0.9.1 and rule out firmware? Can you verify the Z is parallel (Trammed) to the bed +- 1mm?

[thisiskeithb]

People should avoid buying boards with clone STMs.

With STM shortages, vendors have no choice but to find alternatives. Crealtiy & other vendors are now shipping printers with GD chips in them.

[descipher]

Yes and if it's a GD chip issue we cannot fix the code to specifically work with them without violating the STM library license unless GD has an agreement with STM that allows them to use the library which they don't.

[thisiskeithb]

we cannot fix the code to specifically

That is still being worked out now that the shortages have affected the larger vendors.

[ellensp]

First step is to identity the chip the user is using, this GD discussion is pointless until then.

[GJSchaller]

[GJSchaller]

This is a stock BLTouch / CRtouch cable from Creality I got specifically as it had a pre-crimped 5-pin JST on the board end - my crimping skills suck, and this (in theory) would have made cable management easier with everything going to one connection, after I messed up my older cable which had the 3 & 2 configuration. I was running 2.0.9.3 under the old wiring, and the issue began when I swapped in the new wire and recompiled with the flags for the endstops updated - same version of Marlin (2.0.9.3 stable).

Edit: Looking at this, the colors are reversed from my former (Antclabs) cable, but they're reversed consistently on both ends, so that shouldn't make an impact.

[descipher]

@GJSchaller The BLtouch wiring is good and we have confirmed the CPU is an STM32F103. Thank-you for the info. Any chance you can check the tramming state of the bed. Also I found that running back to back octoprint plugin bed visualizers is buggy and displayed inconsistent reports. Using console a text output did not have the inconsistent behaviors.

[descipher]

@GJSchaller One other item I found was the EEPROM code is only working using #define SDCARD_EEPROM_EMULATION on the Creality build environment. There may be a problem with FLASH_EEPROM_EMULATION on the 4.2.2 board, it silently fails to save any settings.

[thisiskeithb]

There may be a problem with FLASH_EEPROM_EMULATION on the 4.2.2 board, it silently fails to save any settings.

With FLASH_EEPROM_EMULATION enabled, add these defines to your config and see if you can get some more output while playing with M502/M500/M503:

#define DEBUG_EEPROM_READWRITE
#define EEPROM_CHITCHAT

[GJSchaller]

I'm running a BTT SKR mini E3 v2, so I can't do any testing on the Creality boards.

Tramming seems to be working fine, I am getting a consistent result (the entire bed being 2mm too low, but even otherwise) every time I run a Bed Level, even after cold booting the Printer and the Pi.

@thisiskeithb, @descipher - I am in the Pateron Discord for the rest of today if you want to chat with me, or go into Voice Chat - I can share my screen and run tests as needed.

[descipher]

@GJSchaller Ok, thanks. @pandaboy6621 you have the 4.2.2, can you please verify your EEPROM is working.

[pandaboy6621]

@GJSchaller Ok, thanks. @pandaboy6621 you have the 4.2.2, can you please verify your EEPROM is working.

How can I check that?

[descipher]

@pandaboy6621 set the probe offset to a new value, save it, power cycle. Check if the new value was restored.

[GJSchaller]

At the suggestion of @EvilGremlin, I edited the Pins for the BTT SKR mini E3 v2, and swapped the Probe and Z-Stop pins. When I did this, the bed leveling worked as expected, even though the wiring was the same as before (connected to the probe port pin). We have a workaround for now, but hopefully that will help narrow down the issue so it can be corrected.

EDIT: the workaround was this - File is:

/Marlin/src/pins/stm32f1/pins_BTT_SKR_MINI_E3_common.h

Edit Line 51 to be:

define Z_STOP_PIN PC14 // Z-STOP (Edited)

[bigtreetech]

I bought the new SKR MINI E3 V3.0 board and it has the same problems - now building a firmware with PINS_DEBUGGING enabled and will provide the data asap.

Hello, Does the latest version of bugfix solve this problem?

[descipher]

@LazeMSS Took a look at your originally posted configuration.h file. You have USE_ZMIN_PLUG defined but your were not using it based on the desired config. The definition USE_ZMIN_PLUG and a defined Z_STOP_PIN will result in HAS_Z_MIN = 1 and that will attach an IRQ to the pin which is not what should be setup.

Please undefine it and retest.

[Dids]

You may also want to turn ADAPTIVE_STEP_SMOOTHING off with this particular board, as this is known to cause frequent probing failures with the BLTouch, at least from what I've heard and seen for myself (https://github.com/MarlinFirmware/Marlin/issues/23958).

[LazeMSS]

I will try all this ASAP

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.