Power failure and resurrection on a CNC machine

Nightowl

I'm still hoping someone will answer my question about using a small powerbank permanently plugged in to the USB port on the Duet3, but nothing yet. If that isn't an option, there may be an alternative!

I can REM out the unnecessary lines in SaveSpindleSpeed.g and resurrect-prologue.g quite easily, and see if that makes a difference. I'll do that this evening, but won't be able to test them until tomorrow, though.

Thanks for your perseverence!

infiniteloop

@nightowl999 said in Power failure and resurrection on a CNC machine:

I can REM out the unnecessary lines in SaveSpindleSpeed.g and resurrect-prologue.g quite easily, and see if that makes a difference

It does. I am pretty sure that SaveSpindleSpeed.g has enough time to write a one-liner to the SD card. By now, it gets 4-6 lines done.

Nightowl

@infiniteloop

OK, so I've done that, leaving the SaveSpindleSpeed.g at this:

var fName = "RestoreSpindleSpeed.g"
echo >>{var.fName} "if {!exists(global.abort_process)}"
echo >>{var.fName} "    global abort_process = true"
echo >>{var.fName} "else"
echo >>{var.fName} "    set global.abort_process = true"
echo >>{var.fName} "M291 S3 R""Resurrect:"" P""Continue with <"^{job.file.fileName}^">?"""
echo >>{var.fName} "set global.abort_process = false"
echo >>{var.fName} "M3 S"^{spindles[0].active}

Which produces this RestoreSpindleSpeed.g file:

if {!exists(global.abort_process)}
    global abort_process = true
else
    set global.abort_process = true
M291 S3 R"Resurrect:" P"Continue with <null>?"
set global.abort_process = false
M3 S0

What I was surprised to see is that if I don't delete the RestoreSpindleSpeed.g and run the SaveSpindleSpeed.g again, it appends to the existing file - perpetually.

Nightowl

@infiniteloop
Actually, why do I need to edit the resurrect-prologue.g file, as this is only run when power is restored?

infiniteloop

@nightowl999

What I was surprised to see is that if I don't delete the RestoreSpindleSpeed.g and run the SaveSpindleSpeed.g again, it appends to the existing file - perpetually.

The first echo must be written with a single angular bracket, i.e. „echo >{var.fName} …

OK, so I've done that, leaving the SaveSpindleSpeed.g at this:

Hm, that’s the file I posted today at 19:14, and I know which RestoreSpindleSpeed.g it generates. That’s not the one-liner I had in mind. Don't mix things up, please.

Actually, why do I need to edit the resurrect-prologue.g file, as this is only run when power is restored?

Because if RestoreSpindleSpeed.g becomes a one-liner, the current resurrect-prologue.g throws an error on the missing variable abort_process.

Nightowl

@infiniteloop said in Power failure and resurrection on a CNC machine:

Hm, that’s the file I posted today at 19:14, and I know which RestoreSpindleSpeed.g it generates. That’s not the one-liner I had in mind. Don't mix things up, please.

I wasn't saying it isn't, just that is what I was left with once I'd deleted the REM lines, but which one-liner were you referring to, to replace those 8 lines, please?

The first echo must be written with a single angular bracket, i.e. „echo >{var.fName} …

Ah, I deleted the lines above it, leaving this one with two >>. Should it be like this, then?

var fName = "RestoreSpindleSpeed.g"
echo >{var.fName} "if {!exists(global.abort_process)}"
echo >>{var.fName} "    global abort_process = true"
echo >>{var.fName} "else"
echo >>{var.fName} "    set global.abort_process = true"
echo >>{var.fName} "M291 S3 R""Resurrect:"" P""Continue with <"^{job.file.fileName}^">?"""
echo >>{var.fName} "set global.abort_process = false"
echo >>{var.fName} "M3 S"^{spindles[0].active}

Because if RestoreSpindleSpeed.g becomes a one-liner

OK, but I'm still unsure how that file could possibly become a one-liner, to be honest!

Also, can I just check I've got the config.g M911 line correct, please:

M911 S23 R23.5 P"M98 P""SaveSpindleSpeed.g""M913 X0 Y0"

Thank you

OwenD

FYI, the spurious {1} lines are a bug in the forum markup software.
You can alleviate them by specifying a language after the code ticks




```php

```json

```perl

Just try different ones till it clears the extra lines

Edit: some references
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks

infiniteloop

@nightowl999 said in Power failure and resurrection on a CNC machine:

Also, can I just check I've got the config.g M911 line correct, please:

You should insert a blank in front of M913.

For the "one-liner", SaveSpindleSpeed.g will look like this:

; SaveSpindleSpeed.g
; Macro to store the actual spindle speed (RPM) at the time this is called
; To restore the saved datum, call the macro "RestoreSpindleSpeed.g".
;
var fName = "RestoreSpindleSpeed.g"
;
echo >{var.fName} "M3 S"^{spindles[0].active}

… and resurrect-prologue.g must be modified like that:

; resurrect-prologue.g
M98 P"RestoreSpindleSpeed.g"
M98 P"homeall.g"	; homes all axes before restarting the job

infiniteloop

@owend Thank you for the tip! Works

dc42

@infiniteloop said in Power failure and resurrection on a CNC machine:

From a first glance, I get the impression that this resurrect.g is missing all the things which are specific to CNC routers.

@infiniteloop and @Nightowl999 if you can list the items that are missing from resurrect.g for CNC machines then I can add that fixing those items the work list for release 3.5.

infiniteloop

@dc42

if you can list the items that are missing from resurrect.g for CNC machines…

From a coder’s point of view, this thread is more a lesson in practical chaos theory than about mills. So the list from this here is quite short:

spindles[n].active

According to @Nightowl999, the corresponding M3 should follow the prologue call in resurrect.g. But I have reasonable doubts if this is sufficient for more complex CNC devices. For a better picture, I need advice from someone with profound CNC knowledge who in turn is willing to try some macros who emulate the required steps in resurrect.g - just without the power outage.

Nightowl

@dc42
Thank you! It's been a really steep learning curve for me with this, but it has certainly provided me with a bit of an insight with programming, thanks to @infiniteloop!

I'll include everything, so will probably mention things that are already preserved, but won't include 'stuff' from the config.g, as I guess this will run when the system restarts. I'm not sure where this information is stored in the Object Browser (Spindles or Tools?) so I'll give a little description.

Active Spindle (tools[n].spindle) - which spindle/tool was active
Spindle Speed (tools[n].spindleRpm) - the last programmed speed of the spindle/tool
XYZ coordinates at power loss

I offer the following for considerations on power loss when the machine is in CNC Mode:

Raise the Z height to Z(max-3) - in preparation for homing when the machine is restarted
Turn the spindle off - after the Z axis is raised.

I don't know if a printer will automatically resume the job when the power is restored, but this is definitely not a good idea for a CNC machin, but I'd like you to consider on power being restored is:

Home the machine - unless this isn't necessary. CNC machines can be quite a bit bigger than a 3D printer, so homing and resuming movements could take a while.
Return to saved XY coordinates - could be a rapid move
Turn the spindle on - at the saved spindle speed
Return to saved Z coordinates - slowly

The option to Resume or Cancel the project should be included too?

Thank you

Nightowl

@dc42
Further to my comments above, which I hope other CNC users will look at and add their thoughts, is it worth considering a CNC-specific resurrect.g file, as there are a few references spurious to these machines.

Here's my latest resurrect.g file with a "?" indicating the lines that may be irrelevant for CNCs...

; File "0:/gcodes/Calibration Toolpath.gcode" resume print after power failure at 2022-05-31 18:23
G21
G92 X368.755 Y584.170 Z47.739
G60 S1
? T-1 P0 ; I'm not sure what this is for
M98 P"resurrect-prologue.g"
? M116 ; not relevant for CNCs
? M290 X0.000 Y0.000 Z0.000 R0 ; is this relevant to CNCs
; Workplace coordinates
G10 L2 P1 X247.00 Y534.00 Z48.05
? G10 L2 P2 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P3 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P4 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P5 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P6 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P7 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P8 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
? G10 L2 P9 X0.00 Y0.00 Z0.00 ; is this relevant to CNCs
G54
M106 S0.00
M106 P0 S0.50
? M116 ; not relevant to CNCs
? G92 E0.00000 ; not relevant to CNCs
? M83 ; not relevant to CNCs
? M486 S-1 ; is thisrelevant to CNCs
? G17 ; is this relevant to CNCs
M23 "0:/gcodes/Calibration Toolpath.gcode"
M26 S2729
? G0 F6000 Z49.739 ; this should happen after XY 
G0 F6000 X368.755 Y584.170
? G0 F6000 Z47.739 ; this speed is much too fast!!
? G1 F762.0 P0 ; is this relevant to CNCs
G21
M24

I hope this helps.

Thank you

Nightowl

@dc42

Would it be conceivable to add support for the M6 and M2 gcode commands, too?

M6 would be useful as I'm using Vectric software with my machine set up as an Ooznest Workbee Z1+ 1075 with the Duet - RRF3_3(mm) post processor, which isn't allowing me to save multi-tool toolpaths. This function may be helpful for other CNC users although I appreciate not everyone runs multi-tool files. This is a function available on my previous machine, and enabled if the machine had a tool length probe installed, to ensure the tool length is measured and the Z Work Zero height adjusted accordingly. Maybe I'm just being lazy...

M2 would also be helpful for follow-on macros. I'm not sure why the spindle returns to +5mm above the Work Z Zero once the job is completed, but I would prefer it moved to a pre-defined location. I could do this with a stop.g macro, but I understand that would need the M2 gcode command in toolpath file.

Thank you.

OwenD

@nightowl999
You have misunderstood my comments about M2
It is not required for stop.g. You need M0 for that.
I was pointing out that some post processors for cnc cutting machines use M2 to denote end of program, which would NOT call stop.g
These systems use M0 and M1 differently as well.
https://tormach.com/program-stop-and-program-end-m00-m01-m02-and-m30
However as you're using a duet board you need to conform to how it uses M0 and M1
That's not to say there's no case for M2, but you need to review the arguments.

Nightowl

@owend
I can see where you referred to M2, but I picked it up from the "GCodes not implemented which are not planned for implementation" section from here, when reviewing the documentation in response to @dc42's request above. I hadn't misunderstood what you'd written, I was just suggesting what could be supported.

However, as far as I can see M0 and M1 have a specific function dependent on what the machine is doing at the time and could be entered manually in the MDI to carry out that function, and seems particularly appropriate for 3D printers. The M2 command, on the other hand, when appended at the end of a programmed toolpath file, has the specific purpose of identifying the end of that program - as it does for plasma cutting (your reference). If M2 is implemented - as it's described in the document referenced above - then I think it would be for the benefit for CNC users.

Whatever the way forward, the Vectric post-processor I use for my machine doesn't include any M codes, other than to turn the spindle off:

; VECTRIC POST REVISION
; a long string of random text
T1
G17
G21
G90
G0Z5.090
G0X0.000Y0.000
M3P0S18000
G0X31.755Y28.580Z5.080
G1Z-1.000F762.0
G1X71.755F3683.0
====
Deleted code...
====
G3X107.470Y51.755I0.000J-14.285
G3X121.755Y37.470I14.285J0.000
G3X136.040Y51.755I0.000J14.285
G3X121.755Y66.040I-14.285J0.000
G1Y68.580
G3X104.930Y51.755I0.000J-16.825
G3X121.755Y34.930I16.825J0.000
G3X138.580Y51.755I0.000J16.825
G3X121.755Y68.580I-16.825J0.000
G0Z5.080
M5
G0Z5.090
G0X0.000Y0.000

...but maybe that's a failing of the PP?