My take on Installing a BL Touch Probe
-
Hey All.
Thanks for this post, it's coming in handy sorting out the Duet on my Hypercube build.
However I have a question regarding the BLTouch (or clone one I have) and the 3.3 volt logic requirement.
Having connected it all up, it was working in my limited testing (printer still not fully built yet), but I've gone back through the topic and thought I should be adding the 240ohm resistor across the black and white wires to drop the voltage to the Duets pins.
So I first checked the BLTouch to find the mentioned trace to cut etc, which is not present on mine. I have a Classic V2.0 according to the labelling and PCB silk screen, which outputs 3.9 volts on said black and white wires when activated.
If I poke the resistor in the back of the plug for testing purposes, the voltage drops to about 1.6 volts off the top of my head and the setup no longer works with the web interface switching from 0 to 1000 on the Z axis as mentioned.So my question is, do I need to work out the resistor value to drop the 3.9 volts to 3.3, or can I leave it as it is which seems to be working as intended?
Thanks.
Ian
p.s. Little more testing and the voltage on triggering the BLTouch jumps to 4.9 volts and then quickly drops to 3.9 volts on my DVM
-
Check that the connection from the Bltouch to +5V on the Duet is sound.
-
Thanks buddy. I'll do that today and report back.
After some playing yesterday, 3x 2k resistors in series yields 3.2x volts on the black and white wires.
Ian
-
Afternoon Mate.
Just cheked and yes there is 5 volts coming out of the Duet, 4.85 on my DVM. So that's good.
I've not yet Googled for any mroe info on the BLTouch differences, which I'm going to do. But as above, with 3x 2k resistors in series the white & black leads now provide 3.2 volts, so this is safe for the Duet?
Thanks.
Ian
-
I've got a BLTouch Smart with the LOGIC on the back. I understand that the trace needs definetly to cut for a use on the Duet Wifi? If so, how gets it cut? Just with a sharp knive?
-
Evening Guys.
I've been keeping an eye on this topic as it's been helpful in getting my setup with BLTouch working. However I have seen the first post is now removed and this has raised a question for me.
Originally doing everything that was posted still didn't work for me, there was some code missing in the bed.g file which I solved. G29 still didn't work for me mind, as the machine went through the motions but didn't deploy the BLTouch, so things got intersting quickly.
Fast-forward to a few days ago and I flashed the latest firmware V1.19 to my Duet and low and behold, G29 now works and deploys the probe.
So this leads me to my question following the removal of the posts here, are the instructions which were posted now out-dated due to the new firmware release, or other?Chatting to another member on here and he doesn't have the bed.g or meshlevelling.g files and yet his setup runs the G29 all ok, so what am I missing?
Is there a new standard to follow for the setup of a BLTouch for example when using V1.19?Thanks.
Ian
-
G29 still didn't work for me mind, as the machine went through the motions but didn't deploy the BLTouch, so things got intersting quickly.
Fast-forward to a few days ago and I flashed the latest firmware V1.19 to my Duet and low and behold, G29 now works and deploys the probe.
Hey Ian,
What you were missing was the manual deployment of the BLTouch probe before doing G29, i.e. calling M401 first, then G29, then M402 to retract when probing was done. Firmware 1.19 takes care of this automatically now, which is why your problem fixed itself.
Cheers,
Ben.EDIT: I should have also said that G29 is not related to bed.g, that file is used with G32 not G29.
-
G29 still didn't work for me mind, as the machine went through the motions but didn't deploy the BLTouch, so things got intersting quickly.
Fast-forward to a few days ago and I flashed the latest firmware V1.19 to my Duet and low and behold, G29 now works and deploys the probe.
Hey Ian,
What you were missing was the manual deployment of the BLTouch probe before doing G29, i.e. calling M401 first, then G29, then M402 to retract when probing was done. Firmware 1.19 takes care of this automatically now, which is why your problem fixed itself.
Cheers,
Ben.EDIT: I should have also said that G29 is not related to bed.g, that file is used with G32 not G29.
Morning Buddy.
Ah ha, thanks for the clarification on that. It had to be and I seem to recall reading a post in which David mentioned similar.
Ok, so G29 is working and am I right in saying this is the recommended mesh levelling option to use for CoreXY setups now?
As test I have remvoed my bed.g file and the Auto Bed Compensation G32 does now not work, but if I am to solely use G29 that's no problem.Would you mind sharing your sys folder files at all? As it seems you are using a very similar setup to me and out of curiosity I would like to compare what I have setup to your own. If ytou'd prefer not to don't worry, but it's worth asking.
Thanks for your time.
Ian
-
Hey Ian, you can find my config files here: https://github.com/Fulg/VORON/tree/master/Firmware/DuetWifi/fulg
I did not update my repo for 1.19 yet however so you will find extra M401/M402 in my bed.g. For 1.19 they can be removed.
G29 is mesh bed leveling and is recommended for CoreXY setups. In my start Gcode I just have a G29 S1 which loads the previously probed heightmap of the bed. I do not use G32.
Cheers,
Ben.EDIT: again I am poorly choosing my words to avoid confusion. bed.g is not required for G29, I only have it for the rare times that I use G32 for testing stuff, when doing a full 192-point G29 is simply taking too long to iterate quickly.
-
hiya
this was by far the best articlewhat happened it appears to be deleted?
-
Hm, its gone and also with the sticky posts… seems several of Calvinx posts are deleted which is a shame - so good
-
I'm currently getting the BLTouch error immediately after the probe makes contact with the bed of my i3. The BLTouch then remains in error until I send an [c]M280 P3 S160 I1;[/c] to clear the error. I'm running 1.19.2 on a Duet Ethernet. What is the solution for stopping the BLTouch from going into alarm? Thanks!
-
@davidbitton, you are probably not raising the carriage high enough or fast enough after the first probe. The probe height is the H parameter of M558, and the travel speed (non-probing speed) is the T parameter.
On my printer I use [c]M558 P5 X0 Y0 Z1 H5 F100 T7000[/c].
BLTouch will go into alarm if it does not have enough space to deploy the pin completely, and when RRF is probing, the pin is immediately redeployed while Z is raising, it does not wait until the carriage is at the next probing point (in contrast to Marlin which will retract during travel moves).
Cheers,
Ben.PS: I don't know what happened to Calvinx, he manually deleted all of his posts. For the BLTouch at least his info is still on the Wiki.
