Ok so I have followed bttt instructions and used their config for the mini e3v3 board and probe would not trigger, so I read and watched some videos and have tried those configs and still probe and I’ll not trigger… so at this point I’m sure it’s a simple mistake as the macros work for probe down etc.
anybody have used these or have experience with this probe??
Thank you!
Ok so no concern now I found a discussion that seems like the entire group was involved and was reading and had an idea. So I switched the pc14 pin and moved it to my z stop on the board, then in the config for th mini e3v3 I changed the probe pin to the z stop pin out to ^!PC2 and magic it suddenly came works!.
So I think it may be possible that this board my pc14 pin is fried? It is an older board and has had issues before that took some time to fix. I have included a printer.cfg file for others if the have similar issues. config-20240709-121105.zip (3.7 KB)
I just looked up the datasheet for the STM32G0B1 (used in the BTT SKR Mini E3 V3) and it has a variance to the ESD CDM and is rated at 250V for this rather than the customary 500V. I haven’t killed one myself, but it’s my impression that the STM32 parts are not as robust as other manufacturer’s MCUs when it comes to static or Electrical Overload Damage (EOL/EOD).
I should point out that there is absolutely no protection built into the BTT SKR Mini E3V3 for the PC14 pin so it’s possible to damage it.
However, in my experience, it is unusual for an MCU to work normally when there is damage to one pin. You should see other issues in operation. It’s not impossible that PC14 was burnt out without affecting any other circuits on the chip but I think it’s unlikely.
I’d be interested in seeing how the adjacent pins (PC13 and PC15) operate - now it’s not impossible that the pads on the chip are not adjacent, but I would expect that if PC14 is damaged then you would see problems with these pins as well.
PC14 (and PC15) are identified as having “OSC32” functionality as well. It’s possible that something is causing the hardware inside the chip to be engaged, disabling the IO function of PC14.
The only thing I would recommend is try to Flash Klipper again and report back if it fixes the PC14 problem or you have problems with the Flashing operation. Otherwise, if everything continues to work as it does now, then live with the board until something else happens.
I had problems with this combination of hardware, moving the probe trigger to the z stop fixed it for me too.
It turns out the probe port for E3 V3 mini doesn’t have a pullup resistor so it’s prone to errant triggering with a microprobe which needs the pullup resistor to enable a stable trigger signal.
BTT seem to acknowledged that and now the microprobe comes with a split cable so it can be easily plugged into the probe port and the Z stop port easily. The cable has dupont connectors though which is a bit disappointing as they don’t seat properly and can work loose quite easily, the one they sent me was too short too and got pulled loose when the printed did it’s homing routine I switched out the dupont connectors for jst connectors and added about 15 cm of length to the cable and it’s been very reliable ever since.
I have an E3v3 and a Biqu probe. My E3v3 board is powered by a relay, controlled by a RPi 3B running klipper/mainsail. I connected my probe to the Z-endstop to deal with the triggering problem. It now works 95% of the time. However, I have also noticed the following behavior:
After an emergency stop or even after a normal power-on, the first homing can sometimes fail on the Z-axis. The probe fails to trigger and the gantry collides with the bed.
This can also happen after a successful print, when prepping for another print.
Again, this happens rarely (~5% of the time) but can be very destructive. I have mitigated the problem by putting a slightly lower “classical” Z-endstop that cuts the relay’s triggering signal, avoiding the printer’s auto-destruction.
I know this is a firmware/klipper issue because that never happened when I was still using Marlin. It feels like this is a firmware bug.
Thanks myke, sorry for such a delayed response life threw some bs my direction so took a while to sort out, good old government trying to tell Ymir how to run my business, taxes just aren’t enough for them lol.
But yes after a ton of searching and messing around I did come across a lot of what you covered, I did get it running so all good, I just feel btt should do more in support with their products like the probes etc.
Regardless thanks again, if you have time check out my newest wizard question, you might have some advice lol!