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

[OwenD]

@nightowl999
The variables include

• all the information that was in the console.
• whether or not you have driver warning and error macros in place (makes a difference if there's any indication of driver problems)
• firmware version
• what debouncing measures are in place
• the M122 information immediately after

If it happens in the same spot then it could be wiring related (As in a short when cables are stretched or flexed) or load related.
Could be electrical interference as already suggested.

I'm afraid you're going to have to repeat the process until you get the necessary info.

I'm not 100% sure it's possible but it might be worth trying to set up a second trigger on the same pin but looking for a falling condition. This need not contain anything more than an echo and would serve only to help identify state changes.

[Nightowl]

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

@nightowl999
What type of button are you using for pause?
How long are the wires?
Are the twisted? Shielded?

One of these, just a standard push button, momentary switch.

Less than 1m, but they're not twisted or shielded, so I could change them for 4-core shielded limit stitch cables (I have several feet of it!) I should have thought about that more; limit switch cable being shielded!

[Nightowl]

@owend

All the information in the console? Failed
I don't have driver warning or error macros, nor would I know where to start!
Duet3 MD6HC with 4.3.1
Debouncing measures are incorporated, but the physical button wasn't pressed. Here's the trigger file...

; trigger2.g
echo "called at " ^ state.time
G4 S1							; delay 10ms to debounce
if sensors.gpIn[9].value=1
	echo "debounce"
	M99 						; break out if sensor value is zero again (bouncing)
if job.file.fileName !=null		; if there's a job filename then it's reasonably safe to say we are printing
if global.PausePress == false	; the button hasn't been pressed so we'll pause
	echo "Pause"
	M25							; pause the current toolpath
else
	echo "resume"				; resume the current toolpath
	M24

M122 information? Failed on that count, too

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

I'm afraid you're going to have to repeat the process until you get the necessary info.

You're correct, of course, but let's see if changing the cable helps. This project was a one-off, in that I won't be running it again in this design iteration, but I'll report back if the event occurs again - and I'll have the concole and M122 reports to hand.

[OwenD]

@nightowl999
The reason it pauses and then resumes immediately is because you are using a "single button" method and the trigger is being activated multiple times.
The "commands" are queued.
So a bad wire that makes & breaks or anything that causes the trigger will pause/resume/pause "ad infinitim"
I looked back through your other posts.
I don't believe you have activated the internal pull-up resistor on the pin, so that would be a good start to reduce the possibility of a "floating" pin.
You should also review this blog as it may offer helpful ideas for a CNC setup.

[Nightowl]

Thanks @owend,

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