BL-Touch Calibration Issues on Printer: Seeking Help
-
Good morning,
I'm using BL-touch on my printer, but it's repeatedly unable to complete the calibration process, while in other instances it can. I'm not sure what could be causing this issue. I'm on version 3.5.0-beta3.
Here's the configuration of my BL-touch v3.1 in config.g:
; Z Probe M950 S0 C"io7.out" M558 P9 C"io7.in" H8 F120 T6000 R0.5 A5 M557 P15:15 X{0,move.axes[0].max} Y{0,move.axes[1].max} G31 X40 Y0 Z2.7 P25
deployprobe.g file:
M280 P0 S11
retractprobe.g file:
M280 P0 S90
bed.g file:
; bed.g ; Call to realise automatic bed compensation via G32 if state.status != "processing" if state.status != "paused" G29 S2 ; Disable mesh bed compensation G28 ; Home all M561 ; Set Identity Transform G0 X0 Y0 Z20 G30 P0 X0 Y0 Z-99999 G29 ; Mesh bed probe M400 ; Wait for current moves to finish
This is the message that shows up every time, and BL-touch is unable to exit the alarm state with M280 P0 S160 or S60. What am I doing wrong? "M280: Probe already triggered at start of probing move"
In case it's relevant, my print area is 1500x1500x1500 millimeters, so the cable is quite long. Although it has been able to perform a 15x15 mapping in some instances, there are times when it's impossible to do even a 5x5 without the error occurring.
If there's anything that is not clear or if you need more information, please do not hesitate to ask for it.
Best regards, Aitor
-
-
@Aitor said in BL-Touch Calibration Issues on Printer: Seeking Help:
P0 X0 Y0 Z-99999
Remove that if all you're trying to do is home Z.
@Aitor said in BL-Touch Calibration Issues on Printer: Seeking Help:
unable to complete the calibration process
I assume you mean when you've sent G32 to run your bed.g?
Does it run better if you simply send G29?
Your dive height in M558 is set quite high at 8mm, do you really need that much clearance?
@Aitor said in BL-Touch Calibration Issues on Printer: Seeking Help:
so the cable is quite long
How long are we talking? What does it run along side?
-
@Aitor said in BL-Touch Calibration Issues on Printer: Seeking Help:
deployprobe.g file:
M280 P0 S11
This should be S10 not S11, and I think may be triggering the alarm on the BLTouch. It should be
M280 P0 S10
Ian
-
Good morning @Phaedrux and @droftarts,
@Phaedrux, if I don't use the P0 parameter, the BL-touch doesn't compensate for the distance between the nozzle and the BL-touch and takes the value of the point where it is located. Although I understand that it serves me the same if I use G30 without additional parameters, I will perform the test even though I think I have also tried it before.
The error appears during the G29 process, usually because for some reason, the "M280 P0 S10" trigger is not activated, and the BL-touch goes into an alarm state, showing the mentioned error. My height is 8mm since at some point, I have a 4mm difference, so keeping it at 5mm, the BL-touch was triggered as the piston came out.
G32 Error: in file macro: M280: Probe already triggered before probing move started
I'm not sure I understand your question:
How long are we talking? What does it run alongside?
But my cable will be around 5-6 meters long.
@droftarts, I have tried with M280 P0 S10, S11, S12, and at first, it seemed that even with S12, it worked well since I managed to perform a 15x15 mapping with S12. But it is about performing desperate tests since I don't know what the reason for the failure is, and with such a long cable, I performed these tests to see if it improved, and it seemed to have improved at first, but it failed again. Today, I will try to downgrade to version 3.4.5 to make sure it's not a version issue.
Thank you for your responses. If there is anything that is not clear or if you require additional information, please do not hesitate to ask.
Best regards, Aitor
-
@Aitor at 5 to 6m long, I expect it’s the length of the cable that is the problem, especially if it travels next to motor wires. Is there a CAN connected expansion board or toolboard closer to the probe you can connect it to?
Ian
-
Good morning, @droftarts.
I'm going to try using a shielded cable to solve the problem I'm having. However, it will take me a while to do it. I'm also considering adding a small delay before executing the "deploymentprobe.g" command to make sure that the X and Y motors are completely stopped before starting the operation, since I believe they are the only ones that can generate this noise.
I will keep you informed about the results of the tests.
Best regards,