BLTouch Only Descends Halfway on G29/G32
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?
Is 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
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.
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
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.1
Hopefully 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.
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?
I've run it at 250 and 500 before, but I will try a little higher and see if that helps. Won't be able to test till tomorrow. Thank you for still checking in.