Endstops ignored?

Software / Firmware
1

Hi,
I’m fairly new to CNC Machines, the one I own is bought from a friend and seems to work pretty well as i understand it, with one small exception…
This is read from the display: V1CNC 508 D, Marlin ver. 2.0.7.2 (firmware).

The machine is equipped with dual end stops, when homing the machine it seems to work perfect, but when jogging the machine either in x or y, the end stops seems to be ignored.
This means, if I am careless, the machine will crash in either direction, I have to “kill” it.
Is this the way i supposed to be, should the end stops work both during homing and also during manual jogging?

I have tried to read on the forum, but most of what i have found, is far to “complex” for me to understand at this point.
Somewhere I found this topic:
// If you want endstops to stay on (by default) even when not homing
// enable this option. Override at any time with M120, M121.
//#define ENDSTOPS_ALWAYS_ON_DEFAULT

Is the above applicable in my case, which means that I have to change in the config files and reflash the firmware?
Or should it be resolved in completely different way, by software endstops or else?

Getting support to sort out this question would be very much appropriated!
Thanks in advance!
//Peter

2

Yep, thats correct behaviour and while you can change I suggest you don’t - there is no real benefit.

If your machine tries to move beyond the limit of your workspace you’ll hear an awful grinding noise that you might assume is stripping gears somewhere - its isn’t its the stepper coils (which are spinning magnets) skipping causing no damage at all.

2 Likes
3

Thanks for your quick reply!
What you describes is precisely the awful noise I have heard and have been concerned about.
OK, then I know that this the correct behavior and really not to be worried about. Do you happen no the logic behind this behavior, I assume that there might be some disadvantage or unwanted side effect, if the endstops are “respected” with all kind of jogging, beside the homing?
Any guideline, tutorial or similar, which can bring some more light to this issue?

Please don’t spend time on this, it just to satisfy my own curiosity!
Thanks again!
//Peter

4

If they are accidentally triggered during a cut, then the job would be ruined.

1 Like
5

Alright, it makes sense.
Thanks,
//Peter

1 Like
6

Hello everyone! 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

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
7

Hey Sergey, first of all we don’t know anything about your machine. Is it an MPCNC? A LowRider?

Secondly, it would be helpful to start your own topic.

2 Likes
8

Agreed, threads are free to start and that makes it much easier for us to help.

2 Likes