Hey Mike,
in no case re-home or re-zero. You can get it to run the program again correctly the same way if you are sure it didn’t move which is the case when you paused the program before power outage happened (a new homing process should be avoided because unless you retrofit limit sensors but use the stock stall homing, you may have some homing repeatability inaccuracy).
What you need after a power outage is the former workpiece zero coordinates, which are stored as offsets relative to the absolute machine coordinates. They are always shown on CONTROL page. If you had these values after a power outage or a reboot, you could restore the state and re-run the program without probing again, and since you didn’t touch the workpiece, it would mill first air and then the rest perfectly.
Unfortunately the Onefinity Controller does not store the workpiece zero position in a file, so it’s volatile and gone on power outage (EDIT: This is wrong, see below). The solution is to make a screenshot or a photo of the control page where you see the positions, absolute positions and offsets. When power comes back, don’t home and don’t zero but manually insert the values you made a screenshot of. The offsets are entered with the G92 command in the command entry field of MDI tab. G92 (Coordinate System Offset) is the command that sets the workpiece zero at a specified value, on one or more axes.
After that, you would send the carriages to the workpiece zero position with a G0 X0 Y0 Z0 command where you can run the program from the beginning again (which will be milling air for the parts that were already milled away).
That the power outage happens during a program pause is of course ideal, because if you saved all the positions at the moment you are pausing, you can later tell the machine where the carriages are by entering the saved values as explained above.
If the power outage happens while the machine is moving, or if you don’t have a screenshot or photo of the paused state, but only from the state after probing and before program start (which means you have the position of the workpiece zero), then you don’t have this information and you cannot tell the machine where the carriages are, and you will have to home the machine after power came back. But the saved offset values will still allow you to directly set the workpiece zero again to its previous values without any probing. The only difference will be a possible minimal position change caused by the homing repeatability accuracy.
If you control your Onefinity Controller via a remote browser access, you can easily make a screenshot as this is usually available on desktops, usually by pressing the “Print Screen” key on PCs. With the touch display directly connected to the Onefinity Controller, such a function is lacking, but if your Onefinity Controller has internet access (usually this is the case when connected via DHCP on your local network in case it has a WAN gateway, not when using with http://onefinity.local/), you could install a screenshot tool in order to make a screenshot through a keypress. I haven’t tried it since you have no window manager running on the Onefinity Controller, but just an instance of chromium-browser. Maybe there’s a way to use other desktop tools when chromium-browser runs (haven’t tried) as single graphical application without window manager (as is the case), but one way that would work would be to install a window manager (a small one like Xfce which is the standard on Raspberry Pies and has Xfce4-screenshooter integrated). Autostart of chromium-browser with the Onefinity User Interface as start page from the window manager then is no problem. Usually a window manager with a desktop is not wanted on a CNC controller, but you can at any time switch chromium-browser to full-screen (F11) and the Onefinity UI will fill the screen the way users are familiar with. By the way, another tool that would be useful is xosview, to see live cpu activity and be warned should the memory become exhausted.
EDIT: Sorry, I am wrong. The Onefinity Controller DOES save some things in a file during program run or on manual MDI execution. Parameter changes made by your g-code program are logged in the bbctrl log file (at /var/log/bbctrl.log). You can find the workpiece zero coordinates by searching for “offset” which is the witness of the last instance of G92, or you could write a script to find and extract the values. Sorry, since I don’t run this controller (just have one here without motors connected to check some things) I have never had a closer look to the log file format, but it seems you can find some information in it.
So Update on what I wrote above:
Instead of having to make a screenshot of the positions and offsets after probing and prior to g-code run, after a power outage you can open the bbctrl log file in a viewer and search for the offsets in the log entries corresponding to your g-code file.
As an example, I just ran Berns_Offset_metric.ngc (172 Bytes), and the log file spits out:
I:Planner:GCode:./upload/Berns_Offset_metric.ngc
I:Planner:Config:{"max-arc-error": 0.01, "min-soft-limit": {"x": 0, "y": 0, "z": -133, "a": -Infinity, "b": -Infinity, "c": -Infinity}, "max-accel": {"x": 750000000, "y": 750000000, "z": 750000000}, "max-jerk": {"x": 1000000000, "y": 1000000000, "z": 1000000000}, "max-soft-limit": {"x": 816, "y": 816, "z": 0, "a": Infinity, "b": Infinity, "c": Infinity}, "rapid-auto-off": false, "program-start": "(Runs at program start)\nG90 (Absolute distance mode)\nG17 (Select XY plane)\n", "default-units": "METRIC", "junction-accel": 200000, "overrides": {"M2": "(Runs on M2, program end)\nM2", "M6": "(Runs on M6, tool change)\nM70\nG21\nS0\nG53 G0 X0 Y0 Z0\nM0 M6 (MSG, Please change the tool and tighten the collet with both wrenches)\nG0 X0 Y0\nM0 (MSG, Please connect the touch probe to the controller, place the touch probe underneath the bit and attach the magnet end to the collet of your router.)\nF100\nG91\nG38.2 Z-100 ; Here we probe\nG92 Z15.4 ; And here we set the new workpiece zero (including substraction of the probe's height)\nG0 Z30\nM0 (MSG, Please remove the touch probe and start the router)\nM72\n\n"}, "max-blend-error": 0.05, "max-vel": {"x": 10000, "y": 10000, "z": 3000}, "max-merge-error": 0.05}
I:Web:200 PUT /api/start (169.254.121.37)
I:Comm:< c
I:Planner:set(#47, line, 5)
I:Planner:set(#48, offset_x, 4.033)
I:Planner:set(#49, offset_y, 4.04)
I:Planner:Cmd:{"type": "end", "id": 50}
I:Comm:< #id=50\n
I:Comm:> {"id":50,"xc":132}
(Note line 2, which contains all machine settings, including my custom ‘tool-change’ routine (although not used here))
The program “Berns_Offset_metric.ngc” contained:
G90 ; Set Absolute distance mode
G21 ; Set Metric units mode
G92.1 ; Delete any previous offset
G0 X4.033 Y4.04 ; Rapid move X and Y
G92 X0 Y0 ; Set X and Y zero here
You see, there is a G92 command that sets a new workpiece zero, and you find the values in the log where it says “offset_x” and “offset_y”. So as long as the Raspberry Pi sync’ed the log file to the SD card before the power failure, you are saved and have the exact workpiece zero coordinates with which you can restore the state of the machine by entering them and then restart the program without reprobing.
Of course instead of extracting them from the log it would be nicer if the positions and especially the offsets, or let’s say all parameters or at least all numbered parameters are saved neatly in a user-friendly file directly when they are changed and constantly kept up-to-date – a file that the user can always find after any power outage or even simply as a last state after every bootup.
By the way, keeping the workpiece zero and current carriage positions is a feature requested in #1045, #1907 and #14115 (and possibly more)
HINT: Note that /var/log/bbctrl.log is subject to logfile rotation. So if you cannot find the information corresponding to your g-code program in the current log file, look at bbctrl.log.1.gz. View with ‘zcat bbctrl.log.1.gz’.