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

[Nightowl]

...but I'm at a loss as to how else this could have happened!

I've just completed my first real project on my RatRig CNC, having tested and tweaked a couple of the toolpaths on some waste boards to make sure everything would go according to plan, with only very minor changes. These toolpaths worked faultlessly.

Whilst the first (of five) toolpaths was running on the real project, cutting a 1mm deep pocket on each pass up to a 5mm depth, at the end of the second pass the Duet3 (MB6HC) went into pause mode, moved to the pause location and immediately resumed the job. It then did exactly the same at the end of the fourth pass.

I know I didn't deliberately click the pause or resume buttons as I was nowhere near the screen on either occasion, so is there anything that could cause this to happen?

I've searched the gcode file and there's no M24 or M25 commands in there, so what else could it be?

Thanks

[jay_s_uk]

@nightowl999 any M226 (I think)
Can you post the gcode?

[Nightowl]

Thank you, @jay_s_uk File uploaded, as requested...

v11_1-1st Clearance.gcode

[jay_s_uk]

@nightowl999 had a quick browse through the gcode and I can't spot anything

[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