Home not working on K40 laser machine

Avataar120 commented 2 years ago

Controller Board

Personal board

See schematic below (picture not accepted here)

Help From Board Vendor

[ ] Yes
[ ] No
[ ] Not Applicable

Machine Description

K40 stock machine Optical end switches for X & Y Delivering 5V when triggered (HOME position) Delivering 0V when not triggered (NC behavior)

Mechanical switch for Z (NO behavior)

Input Circuits

No response

Configuration file

$cd
board: 4_Ava_Shield_7.x_XYZ
name: K40_AvaShield
meta:
stepping:
  engine: I2S_static
  idle_ms: 255
  pulse_us: 4
  dir_delay_us: 1
  disable_delay_us: 0
  segments: 12
axes:
  shared_stepper_disable_pin: NO_PIN
  shared_stepper_reset_pin: NO_PIN
  x:
    steps_per_mm: 78.740
    max_rate_mm_per_min: 20000.000
    acceleration_mm_per_sec2: 2000.000
    max_travel_mm: 310.000
    soft_limits: true
    homing:
      cycle: 1
      allow_single_axis: true
      positive_direction: false
      mpos_mm: 5.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 2500.000
      settle_ms: 250
      seek_scaler: 1.500
      feed_scaler: 5.000
    motor0:
      limit_neg_pin: gpio.39
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 5.000
      stepstick:
        step_pin: I2SO.2
        direction_pin: I2SO.1
        disable_pin: I2SO.0
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: I2SO.3
        reset_pin: NO_PIN
  y:
    steps_per_mm: 78.740
    max_rate_mm_per_min: 20000.000
    acceleration_mm_per_sec2: 2000.000
    max_travel_mm: 210.000
    soft_limits: true
    homing:
      cycle: 1
      allow_single_axis: true
      positive_direction: false
      mpos_mm: 5.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 2500.000
      settle_ms: 250
      seek_scaler: 1.500
      feed_scaler: 5.000
    motor0:
      limit_neg_pin: gpio.34
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 5.000
      stepstick:
        step_pin: I2SO.6
        direction_pin: I2SO.5:low
        disable_pin: I2SO.4
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: I2SO.7
        reset_pin: NO_PIN
  z:
    steps_per_mm: 1000.000
    max_rate_mm_per_min: 200.000
    acceleration_mm_per_sec2: 1000.000
    max_travel_mm: 20.000
    soft_limits: false
    homing:
      cycle: 2
      allow_single_axis: true
      positive_direction: true
      mpos_mm: 9.500
      feed_mm_per_min: 100.000
      seek_mm_per_min: 100.000
      settle_ms: 250
      seek_scaler: 1.500
      feed_scaler: 5.000
    motor0:
      limit_neg_pin: gpio.35:low
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 9.500
      stepstick:
        step_pin: I2SO.10
        direction_pin: I2SO.9:low
        disable_pin: I2SO.8
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: I2SO.11
        reset_pin: NO_PIN
    motor1:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1.000
      null_motor:
kinematics:
  Cartesian:
i2so:
  bck_pin: gpio.22
  data_pin: gpio.21
  ws_pin: gpio.17
spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18
sdcard:
  cs_pin: gpio.5
  card_detect_pin: NO_PIN
control:
  safety_door_pin: gpio.27:low:pu
  reset_pin: gpio.12:low:pu
  feed_hold_pin: gpio.14:low:pu
  cycle_start_pin: gpio.13:low:pu
  macro0_pin: NO_PIN
  macro1_pin: NO_PIN
  macro2_pin: NO_PIN
  macro3_pin: NO_PIN
coolant:
  flood_pin: NO_PIN
  mist_pin: gpio.4
  delay_ms: 50
probe:
  pin: gpio.36:low
  check_mode_start: false
macros:
  startup_line0:
  startup_line1:
  macro0:
  macro1:
  macro2:
  macro3:
start:
  must_home: true
  deactivate_parking: false
  check_limits: true
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
arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: false
use_line_numbers: false
planner_blocks: 16
Laser:
  pwm_hz: 15000
  output_pin: gpio.15
  enable_pin: gpio.16:low
  disable_with_s0: true
  s0_with_disable: false
  tool_num: 0
  speed_map: 0=0.000% 1000=100.000%
ok

Startup Messages

$ss
[MSG:INFO: FluidNC v3.6.1]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is SPIFFS]
[MSG:INFO: Configuration file:config.yaml]
[MSG:DBG: Running after-parse tasks]
[MSG:DBG: Checking configuration]
[MSG:INFO: Machine K40_AvaShield]
[MSG:INFO: Board 4_Ava_Shield_7.x_XYZ]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.17 DATA:gpio.21]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN]
[MSG:INFO: Stepping:I2S_static Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (5.000,315.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.2 Dir:I2SO.1 Disable:I2SO.0]
[MSG:INFO:  X Neg Limit gpio.39]
[MSG:DBG: Updating  X Neg Limit]
[MSG:DBG:  X Neg Limit 1]
[MSG:INFO: Axis Y (5.000,215.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.6 Dir:I2SO.5:low Disable:I2SO.4]
[MSG:INFO:  Y Neg Limit gpio.34]
[MSG:DBG: Updating  Y Neg Limit]
[MSG:DBG:  Y Neg Limit 1]
[MSG:INFO: Axis Z (-10.500,9.500)]
[MSG:INFO:   Motor0]
[MSG:INFO:     stepstick Step:I2SO.10 Dir:I2SO.9:low Disable:I2SO.8]
[MSG:INFO:  Z Neg Limit gpio.35:low]
[MSG:DBG: Updating  Z Neg Limit]
[MSG:DBG:  Z Neg Limit 0]
[MSG:INFO:   Motor1]
[MSG:INFO: safety_door_pin gpio.27:low:pu]
[MSG:INFO: reset_pin gpio.12:low:pu]
[MSG:INFO: feed_hold_pin gpio.14:low:pu]
[MSG:INFO: cycle_start_pin gpio.13:low:pu]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Laser Ena:gpio.16:low Out:gpio.15 Freq:15000Hz Period:4095]
[MSG:INFO: Using spindle Laser]
[MSG:INFO: Mist coolant gpio.4]
[MSG:INFO: Probe Pin: gpio.36:low]
[MSG:INFO: STA SSID is not set]
[MSG:INFO: AP SSID FluidNC IP 192.168.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
ok

User Interface Software

Lightburn or Fluidterm

What happened?

When I issue a $H command on v3.6.1 : Axis are moving to top left corner -> OK When they hit the limit switches -> movement stops -> OK Pull off on both X & Y axis at the time -> OK Slow approach starts -> OK X limit switch is hit first. X stops -> OK Y limit switch is hit -> OK Movement on Y does NOT stop -> NOK 100% repeatable. I didn't tried with NC mechanical switches as I don't have the good setup for that It was working on 3.4.4 and earlier with same config file. Works as a charm with ESP32 GRBL as well.

Thanks for your help.

Log on v3.6.1 : $h [MSG:DBG: Homing Cycle XY] [MSG:DBG: Homing nextPhase FastApproach] [MSG:DBG: Starting from 0.000,0.000,0.000] [MSG:DBG: Planned move to -465.000,-315.000,0.000 @ 3535.534] [MSG:DBG: X Neg Limit 1] [MSG:DBG: Homing limited X] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 1] [MSG:DBG: Homing limited X Y] [MSG:DBG: Homing nextPhase Pulloff0] [MSG:DBG: Starting from -50.572,-45.326,0.000] [MSG:DBG: Planned move to -45.572,-40.326,0.000 @ 282.843] [MSG:DBG: CycleStop Pulloff0] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Homing nextPhase SlowApproach] [MSG:DBG: Starting from -45.568,-40.323,0.000] [MSG:DBG: Planned move to -70.568,-65.323,0.000 @ 282.843] [MSG:DBG: X Neg Limit 1] [MSG:DBG: Homing limited X] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: CycleStop SlowApproach] [MSG:DBG: X Neg Limit 1] <Home|MPos:-50.470,-65.329,0.000|FS:0,0|Pn:X|WCO:5.004,5.004,5.200> ALARM:9 Homing fail. Could not find limit switch within search distance. Defined as 1.5 max_travel on search and 5 pulloff on locate phases. ok

Log on v3.4.4 : $h [MSG:DBG: Homing XY] [MSG:DBG: PrePulloff] [MSG:DBG: Fast approach] [MSG:DBG: X target -465.000 rate 2500.000] [MSG:DBG: Y target -315.000 rate 2500.000] [MSG:DBG: Pulloff0] [MSG:DBG: X target 5.000 rate 200.000] [MSG:DBG: Y target 5.000 rate 200.000] [MSG:DBG: Slow approach] [MSG:DBG: X target -25.000 rate 200.000] [MSG:DBG: Y target -25.000 rate 200.000] [MSG:DBG: Pulloff1] [MSG:DBG: X target 5.000 rate 200.000] [MSG:DBG: Y target 5.000 rate 200.000] [MSG:DBG: Homing Z] [MSG:DBG: PrePulloff] [MSG:DBG: Fast approach] [MSG:DBG: Z target 30.000 rate 100.000] [MSG:DBG: Pulloff0] [MSG:DBG: Z target -9.500 rate 100.000] [MSG:DBG: Slow approach] [MSG:DBG: Z target 47.500 rate 100.000] [MSG:DBG: Pulloff1] [MSG:DBG: Z target -9.500 rate 100.000] ok

Other Information

MitchBradley commented 2 years ago

The optical endstop switches on K40s are widely known to be very noisy and sensitive to stray light. Have you tried shielding them from ambient light?

Avataar120 commented 2 years ago

Yes for sure. I know quite well this machine and common issues associated. Even in full dark it's not working & always exactely the same sequence (fast approach works well, slow approach detects only the X switch which is hit first and not the Y one which is hit after...)

From what I observe, seems not linked to any noise issue.

Avataar120 commented 2 years ago

Wonder if it could come from NC swicthes. I'll try to wire a setup with NC switches to test ... But I don't have switches currently

MitchBradley commented 2 years ago

Since I cannot duplicate it, I am at a loss for how to proceed.

Avataar120 commented 2 years ago

Understood. I'll try to make some more investigations / add probes in the code to try to understand better

Avataar120 commented 2 years ago

Hi @MitchBradley, after some experiments, here my findings ... I have modified LimitPin code like that (just for debug purpose)

void LimitPin::run(void* arg) {
        bool value = get();
        log_debug ( "Before : " << value);
        delay_us (100);
        value = get();
        log_debug ( "After : " << value);
        ....

You can see below that value is different before & after 100us delay causing the issue. With 100us delay, homing & endstop detection are working well Seems to be still linked to the different threshold in the input circuitry between edge detection INT & pin reading

[MSG:DBG: Homing Cycle XY] [MSG:DBG: Homing nextPhase FastApproach] [MSG:DBG: Starting from 0.000,0.000,0.000] [MSG:DBG: Planned move to -465.000,-315.000,0.000 @ 3535.534] [MSG:DBG: Before : 1] [MSG:DBG: After : 1] [MSG:DBG: X Neg Limit 1] [MSG:DBG: Homing limited X] [MSG:DBG: Before : 0] [MSG:DBG: After : 1] [MSG:DBG: Y Neg Limit 1] [MSG:DBG: Homing limited X Y] [MSG:DBG: Homing nextPhase Pulloff0] [MSG:DBG: Starting from -72.924,-94.094,0.000] [MSG:DBG: Planned move to -67.924,-89.094,0.000 @ 282.843] [MSG:DBG: CycleStop Pulloff0] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Homing nextPhase SlowApproach] [MSG:DBG: Starting from -67.920,-89.091,0.000] [MSG:DBG: Planned move to -92.920,-114.091,0.000 @ 282.843] [MSG:DBG: Before : 0] [MSG:DBG: After : 0] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Before : 0] [MSG:DBG: After : 0] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Before : 0] [MSG:DBG: After : 1] [MSG:DBG: X Neg Limit 1] [MSG:DBG: Homing limited X] [MSG:DBG: Before : 1] [MSG:DBG: After : 1] [MSG:DBG: Y Neg Limit 1] [MSG:DBG: Homing limited X Y] [MSG:DBG: Homing nextPhase Pulloff1] [MSG:DBG: Starting from -72.847,-94.056,0.000] [MSG:DBG: Planned move to -67.847,-89.056,0.000 @ 282.843] [MSG:DBG: CycleStop Pulloff1] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: Homing nextPhase Pulloff2] [MSG:DBG: mpos was -67.844,-89.053,0.000] [MSG:DBG: mpos becomes 5.000,5.000,0.000] [MSG:DBG: mpos transformed 5.004,5.004,0.000] [MSG:DBG: Homing done]

MitchBradley commented 2 years ago

I am starting to get very irritated at Espressif

Avataar120 commented 2 years ago

Hi @MitchBradley ,

I made some tests with NC and NO mechanical switches without reproducing the same problem than before your work on limit switchs (#547).

You probably know it already, but K40 endstops are delivering an analog signal between 0 and 5V. When axis is moving toward its end position, voltage is going progressively from low value to high value with a link with axis movement speed (voltage is dependent of the light perceived by the sensor) During homing slow approach, movement is quite slow and switch from low to high voltage takes time (more than the filtering of a sharp edge by board RC filter) leading to the defect of input reading in my opinion ...

MitchBradley commented 2 years ago

Very interesting. An extremely slow edge

MitchBradley commented 2 years ago

This is related to the metastable synchronization problem , for which there is no complete solution. There are techniques to reduce the probability of failure to an arbitrary amount (but not to 0), at the expense of latency. Andreas Bechtolsheim was working on the problem for his PhD, which he never finished due to founding Sun Microsystems. Andy later started several other companies and sold them for large amounts of money, then became a multi-billionaire due to being the first investor in Google. When I was working at Sun, I had to diagnose a lot of problems that turned out to be synchronization failures. Often they would fail once in many millions of events.

A super-slow edge makes synchronization much more difficult because the input signal stays in the transition region for a very long time, greatly increasing the probability of an ambiguous sample where two different circuit elements disagree on the state.

In this case, I could try some more techniques for disambiguation, but it would cause additional latency, which is what I was hoping to reduce with the interrupt-driven limit switch code. Maybe a hardware solution would be better. The ESP32 GPIOs are particularly susceptible to slow edges because they have no hysteresis (8-bit AVR chips have much better GPIO input circuits with hysteresis). Putting a Schmitt trigger buffer between the optical limit and the ESP32 GPIO would probably work much better. Both of the 4x input modules for the 6 pack have Schmitt triggers.

Avataar120 commented 2 years ago

Hi @MitchBradley,

Thanks for this very detailed answer. Honestly, if I'm the only one to have this issue, don't spend to much time on it. I have a workaround that is working on my setup (should not be implemented in other contexts). You can close the issue if relevant

Thanks,

bdring / FluidNC