BLTouch Only Descends Halfway on G29/G32
-
What command are you sending in the deployprobe.g and retractprobe.g files?
Does the probe respond when you send it the commands to deploy, retract, self-test, and release alarm?
If you set it to run self-test does it continue dropping and raising the pin non-stop until you manually trigger it or does it self-trigger? If it self-triggers you might have a sticky pin. In which case the pin can be removed by removing the set screw on the top of the unit.
Your dive height is a little high and fast. Maybe try M558 H5 F100. And in the G31 command try P25 instead of P250.
Here's how I have my BLTouch configured on my CoreXY
[c]M574 X1 Y2 S0 ; Set active-low switches, low end endstop for X, high end endstop for Y, add Z2 for Zmax
M574 Z1 S2 ; Use zprobe and home to min
M307 H3 A-1 C-1 D-1 ; Unbind heater 3 pins for probe use.
M558 P9 X0 Y0 Z1 H5 F100 T4000 A10 R0.5 S0.008 ; P9 for BLTouch, dive height 5mm, probe at 100mm/s, travel 4000mm/s, up to 10 probes, pause 0.5s
G31 X-42.5 Y-2.2 Z1.8 P25 ; probe offset from nozzle, p is trigger value, set low for bltouch, set Z=0 for testing
; (z height is 1.8006 after calibration March 29th)
M557 X20:310 Y2:282 S14 ; Define mesh grid
M376 H20 ; Taper off compensation over 20mm of height
M375 ; Load heightmap.csv[/c]For access point mode use M552 S2 and check your wifi networks for the Duet.
-
I've tried your settings but still get this weird behaviour. Video: https://drive.google.com/file/d/1pSdNuHWDPTvjjOFv8BxW1zxDio94YLGC/view?usp=sharing
-
Your Z speeds are pretty slow. What type of mechanics are you using?
I also just noticed that your trigger height is negative. How did you calibrate that?
-
Tried changing the Z trigger height to positive. Might have been a mistake. It did not solve the issue.
For the Z axis we are using M12 threaded rods. Our gantry is about 1.5mx1.5m and is carrying about 10kg of weight. We can't go much faster or else we get vibration build up. The Z axis is about 2m tall. Future work is to upgrade them to lead screws but we were limited by cost and lead time.
-
Sounds like a very cool project. Hopefully you'll share the completed build in the example forum.
As for your homing issue, can you follow the steps here?
https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probeIs the BLTouch wiring running alongside any untwisted stepper wiring? Do you have a heater running during the probe? Can you test the probe with the wiring separated from the rest of the bundle? I'm starting to suspect possible interference.
-
I'll give that a try tomorrow. It is running as part of a bundle of wires which contains multiple steppers, a heating element, and a fan. The steppers and heater are in shielded wire, but the lengths are long enough we could even get interference from fluorescent lights (which I've experienced with telephone wires).
Maybe I'll try a small capacitor and playing with the trigger value. We have been testing with the heaters off for now.
What confuses me is that M401 and M402 both work. G28 Z works. But when we go to G29 it doesn't behave correctly. We even noticed this when we swapped the BLTouch for an inductive sensor I had on hand.
I'll also be sure to put the build up on the forum. We're focused on finishing the project right now, but afterwards will be hitting up some of the various 3D printer sites and communities.
-
Further settings for the access point mode by the way.
M589: Configure access point parameters
Parameters:S"ccc" The SSID that the WiFi interface should use when it is commanded to run as an access point
P"ccc" The WiFi password
Inn.nn.nn.nn The IP address to use
Cnn The WiFi channel to use (optional)
Note: WPA2 security will be used by default. -
Could you actually provide a more detailed example of M589? I tried doing that but kept getting an error stating incorrect parameters.
-
Try adding this to your config.g. Remove your existing M552 entry or put it after it.
[c]
M550 PBigPrinter ; give the printer a name to show up in URL http://BigPrinter.local
M552 S0 ; disable wifi so we can add a network
M587 S"BigPrinterWifi" P"PRINT" I192.168.0.1 ; create entry in remembered networks for access point SSID
M552 P"BigPrinterWifi" S2 . ; Specify SSID and set access point mode
M589 S"BigPrinterWiFi" P"PRINT" I192.168.0.1 . ; configure access point parameters
[/c]Now on your device find wifi network called BigPrinterWifi and connect using password PRINT.
Then in your browser go to http://BigPrinter.local or 192.168.0.1Hopefully that would load up the DWC.
-
It's better to put those commands in a macro and run that, because the network module remains disabled until config.g has completed.
-
Is there a way to trigger that macro to run on boot?
-
It should work if you set up a trigger on an unused endstop (e.g. E7) using M581, then use M582 to sample it. Running the macro will be deferred until after config.g has completed. Use a G4 S5 command at the start of the macro, to give the network module time to start up.
-
Thank you.
Do you have any thoughts to the issue above relating to probing? It's a very odd situation and I have been unable to find others with the same issue even.
-
It's an odd problem. Are you certain that your Z axis can do 300mm/sec speed and 250mm/sec^2 acceleration without skipping steps, both up and down? My Cartesian printer has 4000 steps/mm, almost the same as yours does, and I have to limit the speed to 250 and the acceleration to 20.
Try reducing both the M203 Z parameter and M558 F parameter to 100, and the M201 Z parameter to 20, and see if that makes a difference.
-
I'd be very surprised if it was skipping steps. The Z axis is driven by two Nema 23's on an external high power driver (DM860AC). We have run the Z axis on big moves vertically and it does them correctly at 300 mm/min. We have run the motors to the point where they start to skip and do not see/hear skipping steps. We have run the Z axis up to 500 mm/min but slowed them down due to vibrations.
It will also probe correctly on the first attempt. Even if we set M558 A >1 it will probe it once correctly, then fail to probe close to the same distance on the second attempt. This can be seen in the linked video above.
-
Nevertheless, your Z acceleration looks very large to me, given the high steps/mm. Does the bed move in your printer, or the gantry? Have you tried moving Z up and down repeatedly by 10mm @ 300mm/min, and checking that the Z height doesn't drift?
Another thing to try is placing the probe about 10mm above the bed, then repeatedly execute G30 S-1 and G1 Z10 F300, to see whether you get the same problem.
Also make sure you don't have any M586 axis skew compensation configured in config.g.
-
It is a moving gantry. Our bed weighs about 110kg and consists of a metal sheet on a galvanized steel pallet. Moving the bed was not feasible.
The Z axis consists of 2 threaded rods but the motion itself is on precision linear rails.
I'll try turning the Z acceleration down and report back with the results tomorrow.
-
I have turned the Z acceleration down quite a bit, from 250mm/s^2 to 100mm/s^2. I also changed homez.gcode to utilize the endstop. With the new homez.gcode I get very consistent zeroing.
To test the probing I do the following set of commands.
M558 P9 F200 T9000 H5 A3 ; set probe type to BLTouch, feed rate to 200mm/min, travel between points to 9000 mm/min, dive height 3mm, probe three times G1 X0 Y0 F9000 ; go to x0 y0 G28 Z ; home the Z axis G1 Z4.5 F200 ; move G30 ; perform single point probe
This code should cause the Z axis to be correctly home, then probe the same spot three more times. The result is similar to before. The homing probe will be performed correctly (it is using a G1 S1 Z-1300 F200, followed by a G92). I then make sure that the probe is within the dive height to the bed based off the measurement just performed. The probing move is then started but the probe will stop a mm or two short of the bed then state "Error: Z probe was not triggered during probing move".
On the probing move it is visibly not descending far enough before stopping and reporting the error. No heaters or fans are running during any of these tests.
-
Please try adding some recovery time to your M558 command, for example R0.5. If that works, you can try reducing it.
-
PS - P25 in your G31 command is very low. What happens if you use P500?