My take on Installing a BL Touch Probe
-
Does anyone know what puts a BLTouch into alarm mode? Could it be incomplete deployment?
That is exactly it. Part of the problem is that G29 and G30 do not handle deployprobe.g and retractprobe.g, so you have to deploy the probe yourself before using them. This means 1) the probe is deployed during the moves and 2) the BLTouch can enter the error state if you do not rise Z fast enough to clear the pin re-extending after the trigger, because the servo signal still says the probe should be deployed.
Maybe this is the wrong place to suggest this (I don't mean to hijack the thread!) but it would help a lot if G29 and G30 could call the deploy and retract macros of the probe implicitly, so RRF would only deploy the pin before moving Z down for the actual Z test, and avoid the early redeploy of the pin during the Z up. It should also be possible for RRF to detect the error state of the BLTouch (I don't remember the details, I could look them up or just write the code), and fail the probe to avoid the inevitable head crashing that will occur. Much like it already does when you attempt to probe with the probe already triggered.
It would also mean you could then do G29 and G30 from the Gcode console without fear of crashing the head. Right now you cannot even do a manual G30 because even if you remember to deploy the BLTouch first, once G30 is done Z is unchanged from the trigger height, which will cause the BLTouch to go in its error state (as it cannot extend the pin further, it has already been triggered!). You can also see this on a G29 for the final point, the pin will extend one last time for no reason while Z is rising to its probe clearance height, before the M402 takes effect.
Cheers,
Ben. -
Thanks dc42, i think you are right on the money for my issue, probe is still deploying when it starts to move to 1st position. even a 1 or 2 second pause would do the trick. is the a g code for that by chance? Just did bed leveling again and adjusted my g31 z height. post mesh, i moved z to 0 and it appears spot on but when i print i am still 1 to 2 mm above bed. odd considering z is perfect after mesh level runs (paper just snug under ph when nozzle is z=0) verified slic3r has no z ofset so still have to figure out where gap is coming from.
-
The G4 command can be used to implement a delay.
-
thank you sir!
I found the switch for whole seconds so that should do it. 1 thing that still bothers me is i have a 300 x 300 mm bed, after running mesh bed leveling i was expecting to be able to print a good test grid but the result is way worse than i get doing it manually. a couple of the corners are more that .3 mm off and print in mid air so not good with .2 layer height lol My bed has a 120 vac 750 watt heater mat and 6 screws with springs supporting bed from solid aluminum plate so i am concerned about warping but the glass should take care of that right? . 1 piece of 1/4 inch cork tile with heater glued to underside of pcb bed and glass with 3mm pei sheet on top. i have dual z motors but z axis is not tied together (upgrade coming soon to reduce to 1 z motor and tie both z lead screws to 1 belt) I suspect my bed can get crooked from time to time and thought mesh bed compensation would take care of that. I did do a solid mechanical alignment 1st so bed is level with nozzle in all corners and above each screw mount. I also don't see the results in web or touch screen console no apparent button or menu. i thought i should have both.G4: Dwell
Support FiveD Teacup Sprinter Marlin Repetier Smoothie RepRapFirmware Machinekit MakerBot grbl Redeem MK4duo
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Pause the machine for a period of time.
Parameters
Pnnn Time to wait, in milliseconds
Snnn Time to wait, in seconds (Only on Repetier, Marlin, Smoothieware, and RepRapFirmware 1.16 and la -
If you click on the arrow next to the button "Auto bed compensation" in Duet WebControl, it will display the last height map saved. It should display it automatically after running G32 or G29 from DuetWebControl too.
-
yup that is what i understand but there is no arrow. i tried the g4 and added 5 second pause before deploy, after deploy and it still errors out but clearing alarm lets it run fine 2nd time. even tried to clear alarm twice to see if i could clear it on the 1st error and no luck there either
-
Perhaps you are using an old version of DWC?
-
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.
