Printer prints backwards and can not get auto bed leveling to probe before print

Basic Information:

Printer Model:
MCU / Printerboard:
Host / SBC
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

…tronxy x5sa

Btt octopus v1.1

raspberry pi 3+ running klipper and mainsail

klippy.log (318.2 KB)

I have been using this printer for several months and now the printer will home right but everything it prints it prints in mirror . Also i had it setup to probe the bed before each print but that has gone away . Its still probes for the z endstop but no matter what I put in the gcode in prusaslicer it wont probe the bed before the print .

Weba @Casper75 !

From within the frontend, does the printer move correctly?

Yes when I home y it goes to the front and when I home x it moves to the left side . the hot end , ends up in the front left corner where it always has .

Can you run a BED_MESH_CALIBRATE from the console?

The “mirror” issue could be a slicer setting. Use the sliders in the preview window. Do the moves align with what the printer does?

Maybe picked a wrong printer profile by accident?

even if that why wont it except the auto bed leveling before print in gcode

Slice a calibration cube (or other small opject) and upload the g-code.

ok here is the gcode for the cube . I did try a different profile the orca profile does the auto bed leveling but skips steps bad . i am also uploading a prusa gcode for the same cube but wont do auto leveling and prints mirrow > i also attached a picture of how bad it skipped .

Calibration Cube PRUSA.gcode (314.9 KB)

calibration-cube_PLA_12m10s.gcode_3.79407 g weight.gcode (518.9 KB)

No smoking gun in the g-code. Prusa calls the mesh after heat soak, Orca meshes cold. Both use the same syntax.

Print both files with speed set to 30% in the web UI (cancel at layer 20 if time/filament is an issue). Note the direction the front faces print. Both should do the front outside parameter from left to right.

After printing both files upload a new klippy.log.

I will do it tomorrow when I get home from work

Ok on the prusasilcer of if I am standing looking at the front of the printer . It prints from right to left .

On the orca slicer facing the same way prints left to right . Here is a picture of the 2 cubes prism slicer on left and orca on right .

here is the klippy log

klippy.log (1.3 MB)

I slowed the printer way down but check this out . Now it printing off instead of the y being in the front it’s on the right of your facing the printer

I find no reason for any difference between the 2 slicers:

Orca, Outer wall (lines 169–174):

start: (174.75, 174.75)  ← top-right corner
→ (155.25, 174.75)   top edge,   right → left   (−X)
→ (155.25, 155.25)   left edge,  top → bottom   (−Y)
→ (174.75, 155.25)   bottom edge, left → right   (+X)
→ (174.75, 174.71)   right edge, bottom → top   (+Y, closing)

Prusa, External perimeter (lines 269–274):

start: (174.79, 174.79)  ← top-right corner
→ (155.21, 174.79)   top edge,   right → left   (−X)
→ (155.21, 155.21)   left edge,  top → bottom   (−Y)
→ (174.79, 155.21)   bottom edge, left → right   (+X)
→ (174.79, 174.73)   right edge, bottom → top   (+Y, closing)

Both start at the top-right corner, both trace top→left→bottom→right in the same counterclockwise order, both close in the same place. There’s no mirroring, no reversal, no axis transposition between these two passes

If you use the arrow buttons in Fluidd/Mainsail/KlipperScreen do the head movements match directions. You .cfg file has X and Y steppers reversed in reference to a generic Btt octopus v1.1 cfg. But if the plugs are swapped at the mainboard then your .cfg is valid.

The y axis homes to the front

The x homes to the front left . When the gcode start to print in goes to the back left corner then moves to the middle and starts printing .

So if both gcods are the same and same movement why do I get suck differ results . The prusaslocer prints mirror with the Y in front and the orca print with the cube turned with the Y on the cube to the right of the printer

Also the x and y are not swapped at the mother board

You have the Y endstop set to 333:

[stepper_x]
step_pin = PG0
dir_pin = !PG1
enable_pin = !PF15
microsteps = 16
rotation_distance = 80
endstop_pin = !PG6
position_endstop = 0
position_min = 0
position_max = 330
homing_retract_dist = 5
homing_speed = 60
second_homing_speed = 15
[stepper_y]
step_pin = PF13
dir_pin = PF12
enable_pin = !PF14
microsteps = 16
rotation_distance = 80
endstop_pin = !PG9
position_endstop = 333
position_min = 0
position_max = 333
homing_retract_dist = 5
homing_speed = 60
second_homing_speed = 15
[stepper_z]
step_pin = PF11
dir_pin = !PG3
enable_pin = !PG5
microsteps = 16
rotation_distance = 16
endstop_pin = probe:z_virtual_endstop
position_min = -5
position_max = 400
homing_speed = 20
second_homing_speed = 10
homing_retract_dist = 5
[stepper_z1]
step_pin = PG4
dir_pin = !PC1
enable_pin = !PA0
microsteps = 16
rotation_distance = 16

By convention Y should home to the BACK. Where is the Y endstop switch mounted?

This is true if 0,0 is at the front left corner.
However you can home whereever you want to. As long as the motors and everything is properly set up.

@Casper75 check this here:
Understanding X and Y Axes Limits and Homing - Knowledge Base - Klipper

Could that be causing my prints to be messing up

Yes.

Klipper doesn’t do a very good job of explaining how CoreXY works. The motors and stepper drivers operate in a coordinate system rotated 45°. Typically the rotated axies are referred to as A and B. See:

For the transformation to happen correctly the X (A) and Y (B) motors have to be configured correctly.

Your OP says you had several months of successful prints. Unless you recently (accidentally) swapped motor plugs all of your prints have been rotated and/or mirrored. Most objects are symmetrical enough that you just never noticed.

This is the first time I was printing anything with lettering in it and realized there was a problem . I am going to read the links you provided and see if I can correct the problem .