After much research I’m about to place an order for a Woodworker. I have one question for the group. I live in a rural area and during the summer months we have a lot of lightning. This results in momentary power outages. Does the Onefinity controller have a feature that will allow you to resume a cut after a power outage or must the cut be restarted from the beginning?
Hey Peter,
No , if your controller loses power it will essentially reset itself back to first boot. However if you use the XYZ Zero you could restart your carve and while it will carve a bit of air as it repasses over the already carved areas it will pick back up once it gets to where the power cut out and will continue as expected.
The machine is incredibly accurate and repeat operations are one of its strong points even if that’s after a restart. Again make sure you zero your work (I would recommend not even un-clapmping it as you might inadvertently twist it on the re-clamp. But if it does not move it will be perfect.
-Alex
5 Likes
OP, hope you dont mind if I add to the question… What if the controller is on a UPS but the main power is not. How will the machine behave in a power outage?
1 Like
Peter Brad
A quality UPS (Uninterruptable Power Supply) will keep everything running for a short time. I have the same issue of the power flickering when the weather is bad. When it happens, I have enough time to plug into a generator to keep everything running…
You have to do what you have to do!
1 Like
The machine will continue to move in X.Y an Z axis without the cutter turning which will likely lead to a ruined part and possibly a broken bit. If you can’t put both on UPS I wouldn’t put just the controller on a UPS, it’s better to let it stop when the power goes out and zero it and start over when the power is back IMO.
So the controller doesnt sense (lack of) current through the router and stop? Seems like a design issue.
Rural power. We get power flickers pretty regularly. Putting UPS aside for a moment…
When the power comes back, as I understand, the router will have power restored, and will begin running again.
Question:
When the controller’s power comes back online, will it leave the router in place (running), or lift it out of the project by default (zero/home)?
Thanks
When the power comes back and the controller boots up it will have a prompt asking you if you want to home the machine. It will not move until you tell it to.
You could use a NVR (no voltage release) switch. Something like this
POWERTEC 71354 Magnetic Switch 120V | EZ Surface Mount Box, Other https://www.amazon.com/dp/B07HWRVPRR/ref=cm_sw_r_cp_api_glt_fabc_61J5WEA2WMGWSY7V8HWV?_encoding=UTF8&psc=1
2 Likes
Blockquote
You could use a NVR (no voltage release) switch. Something like this
POWERTEC 71354 Magnetic Switch 120V | EZ Surface Mount Box, Other
This looks good. Let me poke around a bit to see if I can find a 220 version
Thank you
For 220 this one might work. Bit more money but looks right.
1 Like
I would like to revisit this for a slightly different scenario.
I was carving a 3D bias relief, on the roughing pass.
I needed to stop for a bit and paused the tool path.
During the pause we had a power outage of a minute or so.
As the roughing pass was removing . 125 on each pass I couldn’t re zero my z to the original setting.
I did reset xyz with the probe and restarted the carve, thinking it would cut air until it caught up with the tool path.
To my horror the tool path started at the new z setting ruining the carve.
I have since started over with new material.
How can I avoid this in the future.
Thank you
Mike
1 Like
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’.
My goodness what a response. I had to read it through several times to get a possible solution to my power outage event during a “pause” when running a program.
No disrespect intended but most of this went right over my head.
I am somewhat computer literate so that did help (10 years in School district tech support)
However my Onefinity experience is about 8 months.
My system is not connected to a network, and I have not explored much further that creating files in Vectric and running them on my machine.
I do know that this system is capable of so much more than I currently use.
I am a pure hobbyist and not production.
using my retirement for woodworking fun
If I can put this in terms that I can understand:
If I take a screenshot (phone camera) of the main screen before running the program.
(as an example)
Then enter these values using the MDI tab? (I’ll have to learn about that)
I can then restart the program and it will run the program cutting air until until it catches up?
Or even better if I can take a picture of the “paused” screen I can enter those values?
How will the controller know the start at a certain line in my G-code?
I did have one other instance where I had a system pause failure, I was able to probe xyz and had another member remove many lines of G-code and pickup where I left off.
On that instance my z zero had not changed.
I can see that I still have a lot to learn 
Thank you so much for taking the time for the explaination.
Mike
1 Like
Hey Mike,
yes, if after a power outage you know the offsets that were in the offsets column before it happened. What I mean, you won’t have to re-probe again, because you tell the machine where its workpiece zero was, and in the first case described below, additionally where it is since the power failed (this case works only if the power outage happened when the machine was paused).
-
First I wrote, you could take a photo of the positions and offsets on the control page (more than one people reported to do that before every run after initial workpiece probing, especially if their circuit breaker tends to trip).
-
But then I found out that when you probe, the log file records the offsets and you can find these values later again in the log file, even after a power outage or a reboot. This means you don’t really need to make a photo, at least not for restoring the offsets.
As an example, let’s say, you probed your workpiece and started to run the program, and then you press pause. Let’s say the values are this way then, and you made a screenshot of it:
In this example we assume that the machine was not moving the axes in the moment of the power outage, but paused as you said. Now you get the power outage, and after reboot the user interface looks this way:
Then you would click “Cancel” and then switch to the MDI Tab.
Here you would first enter the offsets (they came from probing). They were X=15, Y=25 and Z=-50. To enter them, you use the G92 command and you enter it into the command entry field of the MDI Tab, but with their sign changed (i.e. the Additive Inverse):
G92 X-15 Y-25 Z50
Then you click on the “Set Axis button” of each axis one after the other, and set each axis position to the value you saved with your photo or screenshot:
This way, without the axes having moved, you restored the settings from before the power outage:
If you are sure the axes did not move, you could run your program again. It would first return to its program starting point and mill air for the parts that had already been milled away, and mill the rest normally.
Unfortunately I can’t test it because I have only the Onefinity Controller here but with no machine attached to it. You can report back if it worked, e.g. by simulating a power outage by simply pausing and shutting down (shutdown, not reboot), then powering on again and proceeding as described above.
The other case would be where the power outage occurred while the machine was moving, and in this case you will have to first home the machine, then we would restore the offsets only, before re-running the program. It’s late so I can’t describe this case today.
And what we could do another day, is make no photo but extract the offset values from the log file 
Got to go, it’s 21:34 in Central Europe, good night!
PS:
The Onefinity Controller does not support starting on a specified line. This only would work by stripping parts of the file. But this is not necessary if initial milling air does not disturb you. Removing the first portion of a G-code file is not trivial (you got to make sure the modal commands at the beginning of the file are preserved, and later modal commands too) and you also had to know the line where to resume.
1 Like