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

OwenD

Did any of your trigger macros execute?
Bad wiring or a floating input pin can cause random triggering on a pin.
A stall or error on a driver could trigger a pause.
There's lots of variables dependant on how you've configured everything.
If you put echo commands in any macros that could be related to a pause event it will help you trace it.

Nightowl

@owend
I think the pause macro must have definitely triggered somehow, because the spindle moved to the programmed 'safe spot' when I deliberately activate the pause macro, but resume macro followed immediately afterwards.

I could understand it more if it just paused and I had to physically activate resume to continue the job, but it didn't. It even showed the Pause/Resume buttons in the DWC, and then the Cancel button when the resume process moved the spindle back to the last saved point but before it started cutting.

And why would it do it at the same point, on the changeover between the 2nd and 3rd cut, then again between the 4th and 5th cut? It didn't do it on any other toolpath on this project, before with the practice runs or with the toolpaths after this one.

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

There's lots of variables dependant on how you've configured everything.

The macro code is fairly basic and the configuration is pretty standard, but I have connected an external pause/resume button near the enclosure, but I was well away from it when it happened. Are there any other variables I should look at?

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

If you put echo commands in any macros that could be related to a pause event it will help you trace it.

There are echo commands in the macros (I meant to d/l the console text, but turned the machine off before I remembered!) and the one thing I noticed is that the pause and resume macros were activated at the same time, and I got a red M24 warning telling me there was no job to pause (paraphrasing, as I can't remember the exact error).

Curious, indeed!

fcwilt

@nightowl999

What type of button are you using for pause?

How long are the wires?

Are the twisted? Shielded?

It's possible the button/wiring is picking up noise and triggering the pause. That would be my first guess.

Frederick

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