Correct finding of the starting position on the X and Y axes

ZenXY Your Builds
1

Hello ev

95
951200×1600 231 KB

eryone! I’m using CoreXY kinematics with two optical limit switches for eac

During homing along the X-axis, the Y limit switch is also active. (Likewise, during homing along the Y-axis, the X limit switch is active.) This interferes with correctly finding the home position. How can I fix this? In CoreXY kinematics, only the X limit switch should be active when homing the X-axis, and only the Y limit switch should be active when homing the Y-axis. Thanks in advance for any hel

I am using DLC-32 v 2.1

Here’s my configuration

board: MKS-DLC32 V2.1
name: CoreXY
meta: (01.01.2022) by Skorpi

kinematics:
midtbot:

stepping:
engine: I2S_STATIC
idle_ms: 0
pulse_us: 4
dir_delay_us: 1
disable_delay_us: 0

axes:
shared_stepper_disable_pin: I2SO.0

x:
steps_per_mm: 80
max_rate_mm_per_min: 18000.000
acceleration_mm_per_sec2: 1500.000
max_travel_mm: 600
soft_limits: true
homing:
cycle: 1
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 300.000
seek_mm_per_min: 5000.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100

motor0:
  limit_neg_pin: gpio.36
  hard_limits: false
  pulloff_mm: 2.000
  stepstick:
    step_pin: I2SO.1
    direction_pin: I2SO.2

y:
steps_per_mm: 80
max_rate_mm_per_min: 12000.000
acceleration_mm_per_sec2: 300.000
max_travel_mm: 600
soft_limits: true
homing:
cycle: 2
positive_direction: false
mpos_mm: -5.000
feed_mm_per_min: 300.000
seek_mm_per_min: 5000.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100

motor0:
  limit_neg_pin: gpio.35
  hard_limits: false
  pulloff_mm: 5.000
  stepstick:
    step_pin: I2SO.5
    direction_pin: I2SO.6:low

i2so:
bck_pin: gpio.16
data_pin: gpio.21
ws_pin: gpio.17

spi:
miso_pin: gpio.12
mosi_pin: gpio.13
sck_pin: gpio.14

sdcard:
cs_pin: gpio.15
card_detect_pin: NO_PIN

control:
safety_door_pin: NO_PIN
reset_pin: NO_PIN
feed_hold_pin: NO_PIN
cycle_start_pin: NO_PIN
macro0_pin: gpio.33:low:pu
macro1_pin: NO_PIN
macro2_pin: NO_PIN
macro3_pin: NO_PIN

macros:
startup_line0:
startup_line1:
macro0: $SD/Run=lasertest.gcode
macro1: $SD/Run=home.gcode
macro2:
macro3:

coolant:
flood_pin: NO_PIN
mist_pin: NO_PIN
delay_ms: 0

probe:
pin: gpio.22
check_mode_start: true

Laser:
pwm_hz: 5000
#L on Beeper / IN on TTL
output_pin: gpio.32
enable_pin: I2SO.7
disable_with_s0: false
s0_with_disable: false
tool_num: 0
speed_map: 0=0.000% 0=12.500% 1700=100.000%

user_outputs:
analog0_pin: NO_PIN
analog1_pin: NO_PIN
analog2_pin: NO_PIN
analog3_pin: NO_PIN
analog0_hz: 5000
analog1_hz: 5000
analog2_hz: 5000
analog3_hz: 5000
digital0_pin: NO_PIN
digital1_pin: NO_PIN
digital2_pin: NO_PIN
digital3_pin: NO_PIN

start:
must_home: false

Copied from the other topic:

name: CoreXY
meta: (01.01.2022) by Skorpi

kinematics:
  midtbot:

stepping:
  engine: I2S_STATIC
  idle_ms: 0
  pulse_us: 4
  dir_delay_us: 1
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: I2SO.0

  x:
    steps_per_mm: 80
    max_rate_mm_per_min: 18000.000
    acceleration_mm_per_sec2: 1500.000
    max_travel_mm: 600
    soft_limits: true
    homing:
      cycle: 1
      positive_direction: false
      mpos_mm: 0.000
      feed_mm_per_min: 300.000
      seek_mm_per_min: 5000.000
      settle_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: gpio.36
      hard_limits: false
      pulloff_mm: 2.000
      stepstick:
        step_pin: I2SO.1
        direction_pin: I2SO.2

  y:
    steps_per_mm: 80
    max_rate_mm_per_min: 12000.000
    acceleration_mm_per_sec2: 300.000
    max_travel_mm: 600
    soft_limits: true
    homing:
      cycle: 2
      positive_direction: false
      mpos_mm: -5.000
      feed_mm_per_min: 300.000
      seek_mm_per_min: 5000.000
      settle_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: gpio.35
      hard_limits: false
      pulloff_mm: 5.000
      stepstick:
        step_pin: I2SO.5
        direction_pin: I2SO.6:low

i2so:
  bck_pin: gpio.16
  data_pin: gpio.21
  ws_pin: gpio.17

spi:
  miso_pin: gpio.12
  mosi_pin: gpio.13
  sck_pin: gpio.14

sdcard:
  cs_pin: gpio.15
  card_detect_pin: NO_PIN

control:
  safety_door_pin: NO_PIN
  reset_pin: NO_PIN
  feed_hold_pin: NO_PIN
  cycle_start_pin: NO_PIN
  macro0_pin: gpio.33:low:pu
  macro1_pin: NO_PIN
  macro2_pin: NO_PIN
  macro3_pin: NO_PIN

macros:
  startup_line0:
  startup_line1:
  macro0: $SD/Run=lasertest.gcode
  macro1: $SD/Run=home.gcode
  macro2:
  macro3:

coolant:
  flood_pin: NO_PIN
  mist_pin: NO_PIN
  delay_ms: 0

probe:
  pin: gpio.22
  check_mode_start: true

Laser:
  pwm_hz: 5000
  #L on Beeper / IN on TTL
  output_pin: gpio.32
  enable_pin: I2SO.7
  disable_with_s0: false
  s0_with_disable: false
  tool_num: 0
  speed_map: 0=0.000% 0=12.500% 1700=100.000%

user_outputs:
  analog0_pin: NO_PIN
  analog1_pin: NO_PIN
  analog2_pin: NO_PIN
  analog3_pin: NO_PIN
  analog0_hz: 5000
  analog1_hz: 5000
  analog2_hz: 5000
  analog3_hz: 5000
  digital0_pin: NO_PIN
  digital1_pin: NO_PIN
  digital2_pin: NO_PIN
  digital3_pin: NO_PIN

start:
  must_home: false
2

Is this true? What errors are you seeing?

Which flag is X and which is Y? I’m going to assume the left one in your picture is X, correct me if I’m wrong.

You need to home X first, but you can’t have Y trigger at the same time. So the middle bit of the gantry needs to be somewhere other than Y=0. You can make a custom homing sequence to do that. But it is probably easier to have a homing macro that just pushes Y to +10 or so before homing X.

Once you do that, you need X to move away from the endstop to clear the trigger. FluidNC should do this for you. I think the settings like mpos_mm adjust that.

But then the Y endstop needs to reach the optical endstop. So you need to adjust you little flags so Y can reach farher than X.

Once the machine homes, you can ignore the endstops. You can set the trigger position for X and Y so the machine can reach that corner for 0,0 despite the flags being at different lengths. That’s the nice thing about optical endstops. You can drive over the trigger point with them.

If this all feels a bit too hacked, you can edit the homing sequence/logic in the code. If you were making many dozens of these machines, that would be the right oath forward. For just 1-2, I would adjust the settings to get what you want.

As a side note, I edited your post to have the code blocks. But the yaml from this post lost the indentation. So I copied the yaml from your other reply.

3

Late to the party here… That’s a very neat looking build.

I also use corexy in Arrakis 2.0. I am using a Duet3D WiFi 3D printer controller board with optical endstops. I simply home the Y axis first (my table’s long axis), then the X axis. Never had a problem with it.

If you really want to make that table go, try servomotors!