BLTouch does not deploy for a print
-
@JoergS5 that makes me wonder if I wired something wrong but there is only one pin for in and one for out. And if I was on the wrong pin it shouldn’t work at all.
-
@baird1fa my explanation would be something crazy like "the double pullup sets too low voltage, the bltouch is blocked because inversed setting and released after next reboot". But crazy and probably makes no sense at all.
Maybe step back and recheck the config and wiring. I saw an image in the internet where black and white was exchanged, you can check whether the colors are correct at the 5-pin connector of the bltouch.
-
@baird1fa said in BLTouch does not deploy for a print:
@JoergS5 that makes me wonder if I wired something wrong but there is only one pin for in and one for out. And if I was on the wrong pin it shouldn’t work at all.
I am confused, do you mean you connected only two pins? You should connect all 5 cables. The other pins are needed as reference for ground and max voltage. 2 of the cables are together at ground, one for signal, one 5 V and one for the endstop.
-
@JoergS5 yes two pins one in one out. I obviously connected the power and ground leads.
-
@baird1fa ok, I thought you only connected two pins...
-
@baird1fa I read in one forum something very similar to your problem. In this case it was a wiring problem of the black wire.
-
@JoergS5 any chance you could point me to that post?
-
@baird1fa I found it, thanks to chrome history function...
the connection on the board being the cause, maybe due to heating up and unstable soldering.
-
@JoergS5 Well I just tested the removal of the I1 and the probe still deploys and retracts. I have gone through my deploy.g and retract.g and removed he I1 and anywhere else I was using the M280 command. The probe functions. I will have to start a print and either let it complete or cancel it to see if that has solved the issue. With any luck it has.
-
@baird1fa said in BLTouch does not deploy for a print:
tested the removal of the I1
In RRF3 inversion of pins is handled by ! in the M950 commands. So the I1 is just ignored. So I don't think it will have an effect either way, but maybe.
@baird1fa said in BLTouch does not deploy for a print:
M401 G0 Z10 F700 ; Bring up Z M402I'm not sure what that's trying to accomplish.
This is just deploying the probe well before the bed gets to the print head so I know if it will deploy or not. The G0 Z10 is just a rapid move to bring up the bed because it’s a 22.75” or travel between home and the probe. Then the probe gets retracted, again just so I can see if it is going to work so I have time to hit the E-Stop.
If I can get this issue resolved the M401 and M402 will be removed. I’ll leave the Z10 in there.
Yes I understood that after seeing your homeall file. That's totally fine.
@baird1fa said in BLTouch does not deploy for a print:
I could plug BLTouch into the board but I wouldn’t be able to have it mounted where it could touch the bed. It would work purely to see if there is interference.
Yes obviously you wouldn't be able to operate like that, but it would be a good test to eliminate any crosstalk interference with the BLtouch wiring. Perhaps slow down your probe speed dramatically so that you have extra time to react incase you need to power off the printer.
-
Well good news I found the problem. it is EMF interference caused by the stepper motor(s) for the extruder. I systematically when through a test Gcode file where I pulled out all but of few of the slicer tool movements and left in the start and end scripts. I then went through and added a bunch of M401 and M402 commands to see when exactly it stopped working. I was able to narrow it down to the very first E move. I'm now able to disable E0:1 using the M18 command and then use the probe again. So I can now either add M18 to my stop.g, or add it to my starting script before my G30 G29 commands.
Also it looks like there is nothing wrong with the servo pin at all. If I issue an M401 before I issue an M18 command, as soon as I issue the M18 command the probe deploys.
Finally.
Thanks for all your help.
-
Glad you were able to track it down.
-
@baird1fa thanks for the info, this was really tough and to my knowledge the first occurence of extruder emf producing this error. I am glad that you found the reason and you had the patience to search for it!
-
@JoergS5 agreed. My hands are bit tied too with how the wiring is as this is a modified Evo22 so I’m using much of the factory wiring, I just replaced the board and the extruder. The rest is inherited from the manufacturer. So I’m glad I can work around the issue.
