I'm not saying it's not my fault...

Nightowl

I appreciate the comment "...a bad wire that makes & breaks or anything that causes the trigger will pause/resume/pause "ad infinitim"..." but the button wasn't pressed during the run.

Also, the switch is normally open so a short could only occur along the cable, as the plug is correctly connected on the board and the other end has two spade connectors onto the switch (the LED connections aren't 'made'.

The pullup resistor is on the .out pin, as far as I understand it, which isn't on the switch side. It's on the LED side, which isn't connected up yet (it's not bright enough - see this thread).

I'll check out the blog tomorrow, but thanks for pointing me there!

mikeabuilder

No answers here, but a debug suggestion. If you rerun the job (maybe without a bit in the chuck), do you get the same failure at the same place? If so, random electrical noise seems less likely, but maybe electrical noise from a specific sequence of commands.

If you do have repeatability, you could start chopping out big chunks of the gcode before and after the failure event, to eventually narrow down to a specific, short section of gcode. Maybe the pattern of electrical signals for the pattern causing a failure will point in a direction to investigate, or at least give you a short sequence that can be looped on while you wiggle wires to see if a particular wiggle makes it happen.

fcwilt

@nightowl999 said in I'm not saying it's not my fault...:

Also, the switch is normally open...

In that case the wire from the board to the switch and act as an "antenna" and pick up noise more easily than if the switch is normally closed and thus connecting the board input to the board ground.

Frederick

Nightowl

@mikeabuilder I might have to run it again after all, so I'll keep an eye our for that, thanks.

I'm not sure about wire-wiggling, but I'm going to change the existing cable to four-core shielded cable over the next couple of days

Nightowl

@fcwilt
OK, I get that. Hopefully the shielded cable (the shield would be earthed) will resolve that, but would a NC button be better? These switches have both options, so I could change it, if NC is the better choice?

fcwilt

@nightowl999 said in I'm not saying it's not my fault...:

@fcwilt
OK, I get that. Hopefully the shielded cable (the shield would be earthed) will resolve that, but would a NC button be better? These switches have both options, so I could change it, if NC is the better choice?

NC first choice always.

Shielded cable never hurts.

As I recall you have the one button and had a bit of trouble getting the code to work.

Two buttons is always better. No issues with hitting the button more than once. Pause is pause. Resume is resume.

Frederick

JoergS5

@nightowl999 with an NC, a disturbance or interference does nothing (it's already closed). With NO, it triggers. So NC is preferrable.

deckingman

@nightowl999 To elaborate on what others have already said, if you have a normally open switch and a wire falls off, it will never trigger. So when you try to home, the carriage will not stop bit will crash into the frame. If you have a normally closed switch, and a wire falls off, then it'll trigger at the start of a homing move so won't crash into the frame. However, if you don't happen to notice, the machine will have a false homing and will "think" it's at one edge of the gantry travel, when in fact it could be in the centre. So if you start a job like that, the head will likely crash into the frame at the end furthest from the homing position. To mitigate that, I always check the status of the homing switch as the very first command in my homing files, and if the switch is already triggered then homing is aborted and a message displayed as to the reason.

fcwilt

@deckingman said in I'm not saying it's not my fault...:

To mitigate that, I always check the status of the homing switch as the very first command in my homing files, and if the switch is already triggered then homing is aborted and a message displayed as to the reason.

That is something I never thought of, that it could indicate a hardware failure.

I've always treated that as an indication that the gantry just happens to sitting at the end of the axis and is triggering the endstop sensor.

Your approach is certainly safe but what do you do then? Jog the gantry away from the endstop sensor?

I need to change my code to deal with the possibility that it could be a hardware failure.

Thanks.

Frederick

Nightowl

Thanks, @deckingman

I too will need to look at my homing macros to incorporate a status check, so I’d be interested to see how you’ve done it.

Other comments regarding the NC switch make sense, because that’s why I changed to nc proximity sensors on the X, Y and Z axes, rather than mechanical no switches!

Thanks, everyone!

deckingman

@fcwilt said in [I'm not saying it's not my fault...](/post/285096

Your approach is certainly safe but what do you do then? Jog the gantry away from the endstop sensor?

Yes that's the first thing to do although it's very unlikely that my machine would be left in a position where one or more axes was hard up against an end stop. The only times it has saved me have been a genuine fault, usually related to my use of a nozzle as a probe and the associated kinematic mount which used to be a bit temperamental.

deckingman

@nightowl999 said in I'm not saying it's not my fault...:

Thanks, @deckingman

I too will need to look at my homing macros to incorporate a status check, so I’d be interested to see how you’ve done it.

I'm away from home right now and only have my phone to hand so I can't give you the exact code. But it's in the form of "if axis(n) is homed - show message and abort". You'll have to look up conditional gcode. If you remind me in about a week, I'll post the exact code.

fcwilt

@nightowl999 said in I'm not saying it's not my fault...:

so I’d be interested to see how you’ve done it.

Here is a stripped down version of one of my homing routines.

If the endstop is triggered at the start of the move I first backoff a bit to see if it clears.

Most of the time this won't cause any problems unless the endstop was stuck on and there was no room to backoff because of the current axis position.

If that is of concern to you, simply remove the code the does the check and the backoff.

You will notice the code at the end that talks about moving to the centerline. That is because my endstops rarely are at the exact min or max position of the axis. A G1 H1 move sets the logical axis position to the axis min or max setting (depending on where the endstop is located) but that doesn't mean the axis is actually at the position. Since I always configure my printers to have X=0 Y=0 at the center of the bed, by testing I determine how far I have to move the axis, after the G1 H1 moves complete, to reach the centerline. Once I know that number it goes into the homing code followed by the G92 which then sets the logical position to 0.

; === homeY.g BOF ===

; --- setup to home Y ---

var msg = ""

M291 R"Homing Y" P"Please wait..." T0

; --- check Y endstop state ---

if sensors.endstops[1].triggered
  G91                       ; relative movements
  G1 H2 Y-35 F3000          ; if triggered backoff so both G1 H1 moves below will be performed

; --- check endstop state again to be sure it cleared ---

if sensors.endstops[1].triggered
  set var.msg = "homeY: Cannot home - the endstop seems to be stuck on"
  
  M291 R{var.msg} P"Aborting" S2
  abort var.msg
  
; --- home Y ---

G91                         ; relative movements
G1 H1 Y299 F3000            ; fast move to endstop
G1 Y-10                     ; backoff a bit as needed to clear endstop
G1 H1 Y15  F300             ; slow move to endstop

; --- finish up ---

G91                         ; relative movements
G1 Y-117 F3000              ; move as needed to get to Y centerline of bed
G92 Y0                      ; sync logical and physical

M291 R"Y Homed" P"Done" T1