Calibration factors do not equal number of leadscrews

BDPrinters

@gloomyandy I will take that into account next time I run into this issue (hopefully never but you never know).

Somehow it worked fine enough to be able to change my calibration settings back to where they were before, so I am happy for now about that

BDPrinters

@fcwilt Couple questions with this.

What makes you think the order could be wrong? Not trying to challenge what you are saying, I just don't see what you are seeing to come to that conclusion, some clarity on that would be welcomed.

In my config file, I have that specific z screw being listed third, but in the bed.g file, it is set to be the second probe of the three to be probed. Do the screws need to be probed in the same order in bed.g as they are listed in the config.g?

Essentially, how it is set up now, I probe 1,2 then 3,(see below) but the order in the config file would say to probe 1,3, then 2. Is this an issue?

Also, I have since changed the bed.g probing locations to a more exact number, the original ones were rough estimates taken with a tape measure. Do the Z screw locations and the probing locations need to be the same? My initial thought is that they do not need to be, as it is the actual location, but specific coordinates to probe for those stated screws, but I could be wrong.

My setup for Z screws is laid out as such

(0,0) Home                                     2 screw


1 screw


                                                 3 screw```

Phaedrux

@BDPrinters said in Calibration factors do not equal number of leadscrews:

Do the Z screw locations and the probing locations need to be the same?

No.

The order and position of the points probed in bed.g isn't critical, but the order of the points in M671 need to match the order of the motors in M584.

gloomyandy

@BDPrinters Just to be clear the M671 locations need to be the points at which the bed actually pivots (this may or may not be the same location as the Z-screw locations, that depends on how the bed is mounted).

BDPrinters

One other thing I just noticed is that I get this error just by homing all. Maybe the issue lies there.

Here is my homeall.g file.

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Wed Nov 01 2023 09:48:25 GMT-0400 (Eastern Daylight Time)
G91                     ; relative positioning
G1 H2 Z20 F6000          ; lift Z relative to current position
G1 H1 X-555 Y-555 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 H2 X5 Y5 F6000       ; go back a few mm
G1 H1 X-555 Y-555 F360  ; move slowly to X and Y axis endstops once more (second pass)
G90                     ; absolute positioning
G1 X15 Y15 F600        ; go to first bed probe point and home Z
G30 S0                  ; home Z by probing the bed

; Uncomment the following lines to lift Z after probing
G91                    ; relative positioning
G1 Z5 F100             ; lift Z relative to current position
G90                    ; absolute positioning

gloomyandy

@BDPrinters I don't think your G30 should have the S0 option to it. Just a simple G30 should be fine.

Phaedrux

@BDPrinters said in Calibration factors do not equal number of leadscrews:

I get this error just by homing all

which error exactly?

BDPrinters

@Phaedrux I get the error that calibration factors are not equal to the number of leadscrews

gloomyandy

@BDPrinters Did you remove the S0 from the G30 command in your homez.g file?

BDPrinters

@gloomyandy Yes, that actually seemed to be the problem for the calibration factors not equaling the number of leadscrews. Things seem to be working fine now.

Thanks to all who have given advice on this, it is much appreciated.

Tom

fcwilt

@BDPrinters said in Calibration factors do not equal number of leadscrews:

Yes, that actually seemed to be the problem for the calibration factors not equaling the number of leadscrews. Things seem to be working fine now.

That seems odd since the docs for G30 without a P parameter state the having an S0 parameter is the same as not having the S0 parameter

A few things come to mind:

the code for G30 S0 has a bug and it doesn't work like the documentation says it should
the documentation for G30 S30 is wrong
you changed something else at the same time which actually fixed the problem

I haven't a clue what is going on.

Frederick