Power requirements for controller

This is very helpful Tom and I appreciate your response.

1 Like

I plan to use a UPS but only for the Onefinity controller and a Wi-fi camera to keep an eye on things from in the house. The router I’m not worried about. My main reason for the UPS is to guard against a breaker trip and losing everything in the middle of a job. And if you pause a job then it’s a little safer with the UPS backing up the controller. If the router loses power no biggie, but the controller is another story.

And the UPS gives you power conditioning which is a big plus.

1 Like

I’m in the process of designing the setup for a 1F Woodworker that I’ll order shortly. Recently, I’ve been thinking about details of the electrical setup.
You say that you want to use a UPS “to guard against a breaker trip and losing everything in the middle of a job”. I plan to use a UPS for the controller too but I don’t understand what “losing everything” means if didn’t use a UPS.
Also, you say “if the router loses power, no biggie, but the controller is another story”. If a breaker trips, I presume the router will stop running but the controller will continue. Isn’t this a recipe at least for breaking the router bit? I guess I don’t understand all the consequences of the controller losing power.

Hey Bob @crz383, hey Bob @Bob_D,

in fact retaining the position where you were in the running g-code program and the positions of the axes after emergency stopping the program due to detected power loss does not work with the stock controller even if it is hooked to a UPS, at least not without using internal controller software functionality directly.

In general, you could wire a safety circuit which is able to tell the controller (assumed to be on a UPS) that something is wrong (e.g. the power to the milling motor is gone), and generally, UPSes have the ability to signal the power loss and to trigger actions then, but the Onefinity controller, which is derived from buildbotics.com controller, only has an input pin for “estop” (pin 23), which sets the controller in “estopped” mode, but this mode lets you loose the point where you were in your program and you also loose the positions of all axes. Unfortunately, a hardware input pin for “pause” is not present on Onefinity or Buildbotics controller, so in case you want to be able to pause the program and to resume and continue program execution later (e.g. when power outage is over), the only way would be to write a webpage-operating program that “presses” pause on the (webbrowser-based) controller interface software (instead of triggering “estop”). This is possible but I would say the effort could be bigger than implementing an additional hardware I/O pin for “pause” in the original controller software.

Also one should be aware that even if you were able to trigger “pause” by an external I/O pin, controller will terminate the gcode line before pausing, so if the milling motor ceased to run because of power outage, the bit will be broken anyway, and also even if paused and resumed, the controller is not able to re-run the last command.

Anyway, a “pause” input pin or hardware button is a yet unfulfilled feature request for Buildbotics Controller and for Onefinity Controller.

Thanks, Aiph5u. That’s more or less what I gathered from reading other posts. So, it seems the only (but not necessarily small) benefit of having the controller on a UPS is to provide power conditioning and isolation.
Has anyone used a UPS to provide backup power to the router and presumably the dust collector. If so, which UPS did they use. It seems it would have to be a fairly sizeable one.

I just had a 20 amp circuit installed yesterday. Your Makita/dust collector will probably trip a 15 amp.

Hey Bob,

The advantage of hooking the controller to an UPS is that on power loss, you are very well able to let stop the running g-code program automatically and the milling motor too. What I refered to is the ability to resume g-code program execution after power is restored, which is questionable at the moment.

In detail, when hooking the Onefinity CNC Controller to an UPS, you would use nut software which enables you to trigger events inside the Controller in case the UPS reports mains electricity failing. You have to use the communication cable provided with the UPS and connect it to the Onefinity Controller. The “Nut” package is easy to install on (Raspberry Pi 3-based) Onefinity Controller since it’s in raspberrypi.org repository.

In case of an event detected like power failure, the nut software in its default configuration is used to shut down the computer shortly before the UPS’s batteries become empty. Nut is also able to send shutdown messages to other computers via remote operation, but it can be used to do whatever you write into the scripts that are run on power failure detection event or on battery low event.

The question is, what can else can you trigger from there. What is possible without problem, is, in case power outage is detected, to stop the spindle by triggering one of the programmed Input Terminals available on any VFD, and there also exists a way to wire the milling motor’s (=Makita router’s) power line to a relay that can be switched on and off by the controller (see here for details), so it could also stop the router immediately. And at same time it would trigger “estop” on the AVR mainboard of Onefinity, so program is stopped.

But you asked, what is if power outage lets the milling motor stop and controller is on UPS and therefore continues to run gcode program and breaks the bit of (now stillstanding) router, right? The answer is, since you install “nut” package, the (Raspberry Pi-based) Onefinity controller can be set up to stop g-code program immediately using “estop” functionality and to stop the milling motor (spindle or router). Whether this is fast enough to stop the g-code program and therefore X,Y axis motion before the router itself is ceasing to run by power outage itself, is what I have not yet tested. But you can halt the g-code program as soon as the UPS signals a power outage to the “nut” daemon running on Onefinity Controller.

The only thing that does not work out of the box, is a way to pause the program and to be able to resume operation later (except than touching/clicking on the “pause” field on controller’s display/remote display).

Note: Besides possibility to trigger “estop” functionality of Onefinity/Buildbotics Controller, or, as mentioned above in the other post, the possibility to write a webpage-operating tool that is able to press “pause” on Onefinity/Buildbotics Controller Web Interface, there also exists the possibility to use the internal functionality of Onefinity/Buildbotics Software directly. Since “nut” package runs on same machine as the Onefinity/Buildbotics Software, you can access all functions directly. I already dived into Buildbotics/Onefinity software earlier, however I have not the time at the moment! I have totally different things to do in my life at the moment. But if I find the time I will report but I cannot tell when this will be.

Thanks for your extensive reply. I have done some work with Raspberry Pi 3 but I didn’t know about nut. I was surprised to learn that the 1F controller allows other software to be installed on it.
I downloaded the nut metapackage but got the warning “nut_2.7.4-13_all.deb can’t be dowloaded securely”, which I presumed could be safely ignored. I presume that the nut server gets installed on the 1F controller; but where does the nut client get installed. Does the nut metapackage take care of choosing the proper versions of the server and client? (I can’t run it since I don’t have a 1F yet.)

Hey Bob

on a Debian GNU/Linux-based system, you usually don’t download and install external packages, but instead you use the apt repository of the operating system.

This happens when you try to install a package outside of package system, but it is not the way to do this. This is the advantage of using the operating system’s package installation functionality: It automatically checks the digital signature of every package against the keys in repository keyring, so downloading is automatically safe then. This prevents man-in-the-middle attacks or installation of packages not signed.

Safe downloading is done automatically when you use the operating system’s package installation functionality: After opening a terminal window or after logging in into Onefinity Controller via a ssh, you can simply do:

sudo apt-get install nut-server nut-client nut-doc

After this, the documentation will be installed under /usr/share/doc/nut-doc .

But be aware that there can be a problem when installing packages on Onefinity Controller. It may be that a package can not be found on repository anymore because the state of the software installed on Onefinity Controller is very old and it could be you are required to execute

sudo apt-get update

which will tell you that hundreds of packages of the entire operating system need to be upgraded and since it’s a very old system (that works in this state for Onefinity CNC software), Onefinity will surely deny any warranty if you do this. However you would still have the possibility to flash the original state of the system back at any time. Have you ever administered a Debian GNU/Linux-derived system before?

Note that Onefinity firmware updates are only updating Onefinity CNC Software, not the underlying “Raspberry Pi OS” operating system, it always remains old.

Thanks for that additional information. That makes things a lot clearer. I have built a couple of Debian GNU/Linux systems on Raspberry Pi 3s; so the process you’ve outlined above is certainly familiar. (I’m a retired software engineer and I’ve worked on other Linux systems.)

Your comments about the age of the 1F system prompts me to ask: if I did do a “sudo update” of all those old packages, does the controller still run properly afterwards? Has anyone done this? (I understand why 1F wants to stick with a tried and true, if old, system and not invest the effort to test and and debug more recent changes to it.)

I noticed on the Buildbotics web page for the breakout board that there’s an “old” controller (with I/O connections limited to 3.3V) and a new one (with 5V connections). Do you know which one the 1F controller uses?

You said in an earlier post that “I already dived into the 1F software earlier”. Does that mean the code is open source? (Not that I necessarily want to get it or have the time to do anything with it.)

Your post also led me to investigate how to control the router and vacuum from G-code.

Hey Bob,

Then you belong to those who should have no reason to fear it :slight_smile:

The development of Buildbotics both hardware and software goes on and this seems not easily to make its way into Onefinity Controller. Users still wait for e.g. the macros that Buildbotics implemented. I already thought that it would be worth to try recent Buildbotics Controller on Onefinity machine for some people. There is development going on. See their forum. (Compare Buildbotics Manual v1.0.2 to Buildbotics Manual v1.0).

Yes, and Buildbotics Controller is a very interesting piece of software of an admirably smart person. As you know Onefinity CNC Controller is both a hardware and a software fork of Buildbotics.com Controller. Both are Open Source:

For a post about using and install git software locally (available for macOS, Windows and Linux/Unix) see here.

3.3 V.

I am not using the Onefinity Controller at the moment, but I have the OS image mounted as loop-mount to explore it as well as Buildbotics image.

Whether the Controller still would work if you upgrade its system to a recent Raspberry Pi OS version cannot be guaranteed in advance but if you are very experienced with Debian GNU/Linux you may solve upcoming problems. I have seen on the buildbotics site there is a directory with a Raspberry Pi OS image of much more recent date in it, but I don’t know at the moment if they use it. So surely it should run – in principle. Since I have been using Debian GNU/Linux from 1995 to 2017 and am still using Debian-derivates on my production machines and am also running a lot of Raspis as thin clients here, I am not the person who would fear updating the Onefinity Controller but be aware that if you want to update it to the most recent version of Raspberry Pi OS (i.e. to benefit of security updates) you would have to make all dist-upgrades one after the other. Did you already upgrade to a new Debian release on a production machine? Or at all? It means reading carefully all the release notes and upgrade manuals - for each release that was there since they cloned the Raspberry Pi image for using it in the Onefinity Controller (this was Raspbian GNU/Linux 9.3 (“stretch”)). Next release would be “buster” (Release Notes, Upgrade Manual, Installation Manual) and be sure to be familiar with Raspberry Pi OS Upgrade Instructions, Raspberry Pi OS ‘config.txt’ file and ‘raspi-config’ documentation. During a Debian(-derived) release upgrade, you will be asked a lot of questions by the system during upgrade process, questions about packages you’ve never heard of. Sometimes it is good to have Debian Reference, Debian GNU/Linux FAQ and Debian Administrator’s Handbook at hand. You could first try it on a machine that is not a production machine. Clone the image, boot (to let the Onefinity firmware installation complete) and then you could try it. Note that the address of the repository has to be changed in /etc/apt/sources.list and /etc/apt/sources.list.d at a certain point when you reach a version that is not already archived.

You may also omit upgrading to the next releases (apt-get upgrade && apt-get dist-upgrade) and just do an update of the package list (apt-get update) to be at least able to install additional packages of the (archived) currently running (9.3 “stretch”) system.

Further Reading

Debian GNU/Linux Documentation
Raspberry Pi OS Documentation
Buildbotics Documentation

Thanks for the information about doing upgrades. It seems pretty daunting; but, if there was some substantial benefit in doing so, if I was certain of being able to back out of the upgrades if the resulting system failed and if I didn’t care about OneFinity voiding my warranty, I might give it a go some day.

I’d suggest picking up a 32gb micro SD card and flashing it with the Onefinity image then use that if you want to experiment.


Hey Bob,

since as you said, you know Raspberry Pi, you know you can simply slip another SD card into the slot on the underside of the pcb. You can have the one with virgin Onefinity original image on it on the shelf and you know your warranty is there.

1 Like

I read and understood the post on how to reflash the OS. However, I can presumably take the SD card from the controller to another Raspi system and use the “dd” command to make an exact copy of it onto a second SD card. But, and this may be due to my lack of understanding of the low-level details of how Raspberry Pi uses the SD card, should I expect this second SD card then to work in the controller.

Hey Bob,

the SD card is simply seen by the Raspberry Pi as a bootable hard disk.

If it contains exactly the same as the original, it will boot. On computers with PC-style boot mechanism, it is the first sector of hard disk (and SD card is seen as a hard disk here) that contains the boot loader.

The only thing you got to know is that the Raspberry Pi image that Onefinity offers for download is maximally reduced in size (4075814912 bytes the last time I downloaded it), and on first boot, a program is called (that is available in ‘raspi-config’ tool by the way) that expands the partition entry and the filesytem of the 2nd partition to the maximum size available on the SD card. The resulting size depends on how large the SD card is. This leads to the problem that if you want to backup a system with ‘dd(1)’ that was already expanded this way because it was already booted, it is much bigger now, and can take place only on a media of sufficient size. SD cards don’t always have the size written on their case. If you happen to buy a SD card that is a little smaller than the already expanded Onefinity system, your ‘dd’ command will fail (of course you can shrink the system again before backing it up, if you know how to use resize2fs(8) and parted(8)/gparted(8)). Therefore, as a backup, I would use an image cloned before first boot, or better simply a downloaded copy of image that Onefinity offers.

1 Like

Interesting to learn about expanding the partition on the SD card. I also wanted to learn whether I could clone an SD card from an operating system, so that the clone included the current state of the file system, ie, new and updated files, settings, etc. (I hadn’t needed to do that on the Raspi systems I’ve built and I was just wondering whether it would work in general.)

Are you implying that the only adverse effect of cloning the SD card from an operating system is that it may take a lot longer than a virgin system? What size SD card is shipped with current 1F systems?

Hey Bob,

a clone is a clone, which means, it is identical.

If you clone a SD card with ‘dd’, you also clone a lot of bytes that are considered as empty space on a filesystem.

If you want to freeze the state of an entire system, you mean snapshots.

If you just want to save the modifications you made to a system, then you want incremental backups. Usually backup systems do this, e.g. in a daily interval.

Both allow you to restore data to a previous state.

SD cards smaller than 16 GB are hard to find nowadays, even if this space will never be used in an Onefinity controller.

I understand: don’t put the CNC controller and a vacuum on the same outlet. Do they require separate circuits from the circuit-breaker box, or can I just split one circuit to power separate outlets?

It’s best practice to be separate circuits.

1 Like