BLTouch does not deploy for a print
-
Yes all of my wiring for the print head run in a bundle between the board and the print head. It’s about 1m-2m if cabling.
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.
The only issue with that thought is that it does work when I first start a print and all the PWMs are pulsing and causing the most EMF and potential for signal noise. But after a print, it no longer works and everything is off (all the fans and heaters set to 0).
It’s not an ideal solution but I suppose a workaround would be to reset the board after each print. I think there is a GCode for that.
Edit: I just looked up the Gcode for a firmware reset and Yes the M999 does reset the board, and then also allows the BLTouch to start working again. I just simulated the end of my gcode script by creating a macro that turns on all the fans, then turns off the fans and the heaters and then tries to deploy the probe. That seems to work fine.
I have noticed that if the print finishes or even if I cancel a print I need to reboot the board. I wonder if there is something in how the firmware handles the "cancel" or the "end of print" code that is causing me this issue. Is that something that I can actually investigate or is that locked away in the firmware?
-
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.
-
@baird1fa One thing I found:
M950 S0 C"io4.out"
M558 P9 C"^io4.in" H3 F200 T12000
M280 P0 S160 I1In https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_BLTouch is mentioned: "On Duet 3 it is one of io4.out, io5.out or io7.out. If you use one of these pin names, you will not need to invert the output."
So you don't need the I1.
I think you will not need the ^ also. -
@JoergS5 I read that too, but the commands don’t work with out the I1. Also the ^ is for the pull-up resistor on the input isn’t it?
-
@baird1fa The sentence "The Z probe input pin will be zprobe.in on a Duet 2, or one of io4.in, io5.in or io7.in on a Duet 3. If using zprobe.in, you need to enable the pullup resistor using the ^ character in front of the pin name." seem to say, that only for zprobe.in the ^must be set.
It's strange that you need the I1 when in the documentation is explicitly said it is not needed for io4.out. There seems to be something wrong.
Could you try changing both at the same time, does the BLtouch still work then?
-
@baird1fa I looked: according to https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Duet_3_endstop_inputs each IO of Duet 3 has already pullup resistors: "Endstop devices can be connected to the IO_0 through IO_9 connectors. Each endstop input has a 27K pullup resistor, so the endstop devices only need to sink 0.12mA." so there should not be a necessity to set the ^
-
@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.
