BLTouch Only Descends Halfway on G29/G32

Phaedrux

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.1

Hopefully that would load up the DWC.

dc42

It's better to put those commands in a macro and run that, because the network module remains disabled until config.g has completed.

Zerbob

Is there a way to trigger that macro to run on boot?

dc42

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.

Zerbob

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.

dc42

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.

Zerbob

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.

dc42

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.

Zerbob

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.

Zerbob

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.

dc42

Please try adding some recovery time to your M558 command, for example R0.5. If that works, you can try reducing it.

dc42

PS - P25 in your G31 command is very low. What happens if you use P500?

Zerbob

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.

dc42

Just to be clear, please try both a M558 R parameter and a higher G31 P parameter.

Zerbob

Tried both and got the same result. It seems that the printer is resetting its height before a dive, causing it to dive too short. If you obstruct the probe early with your finger, it works as intended. However left to itself, it will not lower enough for the probe to even reach the bed.

dc42

Could it be that the bed is tilted, and the dive height is set too low to reach some points? You can change dive height, it's the M558 H parameter. The default is 5mm.