BLTouch does not deploy for a print
-
@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.
