My take on Installing a BL Touch Probe
-
this is my bed.g now odd i know but it does work as far as running probe and getting result.
; bed.g
; called to perform automatic bed compensation via G32G28 ; Home All
;–--------- Mesh Level ------------------
M561 ; Clear any bed transform
M557 X10:260 Y10:240 S25 ; Define grid
M401 ; Deploy probe
G29 ; Start mesh level (this is where it deploys probe, moves to 1st point and then alarms)
M280 P3 S60 I1 ; Clear Alarm
G29 ; Start mesh level
M402 ; Retract probeDeployprobe.g
M280 P3 S10 I1 ;deploy probe
G4 P200 ;will delay 200ms.
Config.g
; BLTouch
M307 H3 A-1 C-1 D-1
M558 P5 X-22 Y-9 Z2.65 H3 F200 T5000
G31 X-22 Y-9 Z1 -
The Z parameter in your G31 command is the nozzle height above the bed when the probe triggers. You need to set that correctly to get the nozzle at the correct height when you start printing. See https://duet3d.com/wiki/Using_mesh_bed_compensation#Checking_the_trigger_height.
-
i did a manual bed level last night and re ran mesh level. It still runs fine and the result appeared to be way better now but the nozzle is still way to high when it starts to print. I have z offset in slic3r set to 0 so not sure where this is coming from but z is off by close to 5mm after running routine. very odd.
Sorry, didn't see your g31 reply till just now, definitely going to play with that setting. Thanks much!
-
it appears the z probe error is caused when it deploys then moves. it starts moving to soon and drags a little at start of move to 1st home position. is there a way i can delay a command by a second or 2? that should fix the error and having to clear alarm. still playing with g31 to see if that fixes it.
-
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.
