Hey quesohusker,
this is true. Buildbotics.com considered it as capable enough for a CNC controller, but it is not capable enough to show the camotics.org 3D toolpath simulation, currently you see it only when you use the Onefinity User Interface from a (more graphics-capable) remote computer.
So I would think, yes, there is a way to install a Raspberry Pi 4 in your Onefinity Controller if you observe a few things:
one user reports that he was able to successfully build the Buildbotics-firmware sources on the Raspberry Pi 400 (Pi 4 based). So I would see no reason why it wouldn’t work with Onefinity-firmware sources too.
no need to exchange the Raspberry Pi, as explained above. But in case someone would want to, the old back panel of Onefinity Controller won’t fit Pi 4 since connectors positions changed (see here) (technical drawing). Also you would need a Mini-HDMI to HDMI adapter.
As for the Onefinity Controller’s current operating system, a frozen and totally outdated Raspbian OS from 2017, updating this OS on the Onefinity SD card image brings many problems and will not work, as explained in the following below. So what would work instead, is take a recent Raspberry Pi OS (64-bit), flash it on a SD card, boot it, and build (=compile and install) the Onefinity System from its sources.
The next firmware version of the software, 2.0 is a major software revision. What do we mean by ‘major’? Visually, and functionally, it will look and work very much the same as our current firmware (1.2). However, it’s underlying programing is moving to 64bit architecture, which means major, under the hood, work. What does moving to 64 bit mean? In simplified terms, it allows us to change from the current older raspberry pi 3b computer module that’s inside our controller today to the raspberry pi 4 computer module.
What does that mean for all of the current Buildbotics users? Are we stuck with 1.2.1 forever? Or will there be an upgrade path for us, either a new module to put in the controller, or a complete new box?
the Raspberry Pi 3B that is inside the stock Onefinity Controller already has a 64-bit-capable CPU. The outdated Raspberry Pi OS from 2017 that runs on the Onefinity <=1.2.xx SD card images is an image of the 32-bit architecture “armhf” (ARM hard float), but switching to the 64-bit architecture “arm64” will work out of the box since the Raspberry Pi 3B is in fact made for it.
You can check this by taking an empty SD card and writing the most recent Raspberry Pi OS (64-bit) to it and boot it on the Raspberry Pi 3B in your Onefinity Controller.
As Onefinity states:
This has a major rebuild that is 64 bit which will work with either RPI3 or RPI4.
So no need for an upgrade path, you will be able to simply install 2.x firmware with a 64-bit OS image when it left beta status on your old Onefinity Controller.
You cannot update any of the packages of the ancient Raspbian Stretch installation from 2017 on the Onefinity SD card without making the CNC controller functions ceasing to work. This is because more or less every package of which you want to install a recent version relies on countless dependencies to other recent packages that you can only fulfill by a complete OS upgrade. But a OS upgrade is not possible. This is because the crucial bbserial.ko kernel module, that makes communication with the AVR mainboard with the stepper drivers possible, is not packed as a .deb package and not integrated in Dynamic Kernel Module Support (DKMS) so will not be re-compiled automatically on a kernel package upgrade, so on kernel module loading, this module will fail, turning your Onefinity Controller into a brick with an updated Raspberry PI OS running, but being no more a CNC controller. So updating chrome or any of the packages that could have old security issues, is not possible.
It should however possible to take an SD card and flash a new, up-to-date Raspberry Pi OS (64-bit) on it and to build (=compile and install) the Onefinity System from the sources, as mentioned above, where I mentioned that a user built the buildbotics sources on a recent Raspberry Pi 400 with a recent 64-bit Raspberry Pi OS system.
For the project of creating and offering a new CNC machine, forking buildbotics.com was a good way to go, as it is free and open software and hardware (see onefinity-pcb vs. bbctrl-pcb for the open hardware). But Onefinity simply inherited some problems from upstream when they forked it. For example, just as the ‘buildbotics-firmware’, the ‘onefinity-firmware’ package is the only package on the Raspberry Pi OS system inside the Onefinity Controller that is not packed as ‘.deb’ package and therefore cannot simply be downgraded with ‘apt-get install onefinity-firmware=1.0.9’, which would have been very helpful when Onefinity abandoned and withdraw the 1.1x branch and told people they need to reflash the entire OS on the SD card.
Usually it is never necessary to overwrite (re-flash) a Raspberry Pi OS installation (except if the SD card fails). Today, all Unixoid Operating Systems have smart package management systems . Usually unixoid operating systems have an uptime of monthes, even years, and are updated while they run – including occasionally necessary downgrade of a package. On Debian-derived systems like the Raspberry Pi OS, this is the Advanced Package Tool (APT) system which deals with deb packages.
But it’s not trivial to pack a package as deb file, not only you have to learn debian policy, but you first also would need to integrate the bbserial kernel module into the Dynamic Kernel Module Support (DKMS) system so that it is automatically re-built on any kernel upgrade. Currently it is hardwired to an ancient kernel source and as soon you upgrade the kernel, the bbserial module ceases to work and the Onefinity System cannot access the AVR mainboard with the stepper drivers anymore. This is why you are stuck with a Raspbian operating system of 2017 with all the security issues that came up since then.
The good news is, onefinity-firmware is published under a free license, so if someone is willing to free bbserial from the hardcoding to an ancient kernel source, integrate it into the Debian’s DKMS, and finally pack ‘onefinity-firmware’ as a .deb package, that would be worth it to achieve that it becomes an interesting community project that attracts developers.
The same applies to buildbotics-firmware too by the way, and the question is, wouldn’t the community better contribute to buildbotics upstream, as this original version of the controller firmware (and hardware) would easily fit the Onefinity machine, but evolved a bit further [What’s new in Buildbotics 1.0.2], [What’s new in Buildbotics 1.0.0]. Unfortunately, Onefinity never backports any upstream improvements to its fork.
As you can see, it is linked to a kernel source under dbrgn (Danilo Bargen) · GitHub which is dbrgn (Danilo Bargen) · GitHub – is this necessary? I would not deliver a software that is “hardwired” this way.
What would be a progress would be an updated, recent Raspberry Pi OS operating system on the Onefinity, which would also mean the crucially important ‘bbserial’ module freed from the “hardwiring” to some dbrgn’s ancient kernel source from 2018 shown above, and the bbserial kernel module made from the updated, recent kernel source, and being compiled automatically everytime the kernel of the system is updated. DKMS does that (see my post above). E.g. like the ‘vboxdrv’ kernel module when you have virtualbox installed on your machine. You don’t have to care of it, because it is always recent and working and loaded, thanks to DKMS.
Having a recent operating system version on the Onefinity controller instead of a frozen 2018 version would also allow the CNC operator to install other useful software, and first of all avoid using old software with security issues.