I want to change the firmware on the onefinity to the open source buildbotics software. There are many things on the open source project that I want that aren’t in the official version. I’m also a software developer and would like to add my own features for my own custom things.
I’m wondering if the firmwares in this forum can be installed on the onefinity controller that I purchased from onefinity? I wasn’t clear if the firmwares here are for people who bought a controller from outside or would also work for the official controller purchased from onefinity.
I’ve seen this asked a few times and the answer is no you can not due to hardware differences between the two controllers and it may/will brick the controller if you try it. The code repo for the Onefinity controller isn’t a fork from BB and seems to be somewhat inaccurate/incomplete (I was never able to get it to build and install). It is kind of a bummer as there are code fixes and improvements on the BB code that would add significant functionality to the Onefinity controller. I had at one point considered buying a BB controller as a drop in replacement directly from them but ultimately went the route of LinuxCNC then Masso G3 which required more effort to convert - limit switches, stepper motor drivers.
but what would be the reason that it did not work? If you look at the schematics, you can find the only very few differences (buildbotics/bbctrl-pcb vs. onefinitycnc-pcb). Of course the Onefinity Controller is a software and a hardware fork of the Buildbotics.com Controller. Both firmware and schematics, and the pcb too, you can clearly see where it comes from and find the differences. Obviously firmware it is based on Buildbotics 0.4.14.
Did you remember what the setup log said, specifically when it comes to uploading the AVR and ATTiny firmware?
I checked it, this recent ‘arm64’ image of course boots on the Onefinity Controller with its Raspberry Pi 3B. I did that when one buildbotics forum user reported that he was able to successfully build the Buildbotics-firmware sources on the Raspberry Pi 400 (Pi 4 based). I did not yet try to build ‘bbctrl-firmware’ on the Onefinity’s Raspberry Pi 3B though, but thought of trying it, since like Neel @justneel, I would prefer to contribute to the upstream project and would avoid to buy a separate controller.
I doubt you could brick it permanently as long as you are able upload the AVR firmware to the AVR and to the ATTiny.
What is missing on the Onefinity fork, is the small LCD on the box. It is on the same sda/sdc bus with two wires. So I would remove the code that drives it.
EDIT: onefinity-firmware/src/avr/src/lcd.c and lcd.h exist and seem not to do any harm, although Onefinity lacks the LCD on the box.
Meanwell 36 V power supply is internal on the Onefinity, external on the Buildbotics. One difference on the pcb is that Load1, Load2, Probe and Laser are additionally made available as Molex sockets on the Onefinity Controller, while on Buildbotics you only get them via the 25-pin I/O port. A good thing on the recent Buildbotics version is the 15-pin Auxiliary Port that allows connection of external stepper drivers so you can use other things like closed-loop steppers or servos. However that is just a port, not a circuit change.
But seriously, uploading firmware to an AVR / ATTiny is something that I do since years, often many times a day (I did that already when there was no such thing as the Arduino platform and its nice C dialect and all the libraries, but you programmed in assembler before gcc-avr came up, and Atmel was a competitor of Microchip, and not yet aquired by Microchip, and the question was AVR or PIC, like C64 or ZX Spectrum, Amiga or Atari ST, Stones or Beatles, and there was no flash memory and no boot-loading code that automatically requests the firmware), so I really don’t think you will brick it if you know what you’re doing. The AVRs on the serial bus are accessible from the Raspberry Pi OS (the AVR C code is under /src/avr).
I don’t think that one should fear to test it just because Onefinity tells you it won’t work and you will brick it (just my opinion). But it is clear that although I may test it one day, because of health issues I can’t do it at the moment because I cannot work in my lab where the controller is, also I plan to use another CNC controller for my machine so I doubt that I will give it enough priority to find the time.
Yes I did and encountered numerous build errors using a clone of the 1.0.9 repo. I did not have time to debug and troubleshoot further so I stopped pursuing it.
I did ask at the time if anyone else had successfully built it and it seems no one had.
I have relegated the Onefinity BB controller to running a secondary smaller non Onefinity 3 axis CNC so it is still of interest to me to improve it, just not at the cost of many hours of time chasing down a dead end.
The original poster wants to try to build the buildbotics/bbctrl-firmware (and assuming using the current Buildbotics Raspberry Pi SD card image) on the Onefinity hardware. That is a quite different thing. That’s what I would try too if I had the time.
This is something that I also is interested in. As software developer and former developer of embedded linux system this was one thing that made me really happy when ordering my Onefinity but when I got it and start to look more closely to it I found out that it would probably not follow the forked buildbotics making it hard to create a open source community around it.
I have tried to add some issue to the github page for small web UI updates to make the xyz-probe to consider tool width but it doesn’t looks like anyone tracks that one.
If we are more people with this in mind it might be possible to put together a build pipeline and maybe a discord server to make it happen.
2 Likes
Aiph5u
(Aiph5u (not affiliated with Onefinity))
11
Hey Lars,
I believe the Buildbotics.com project is worth it to be further developed. And it is worth to be used because of what it offers today. This includes also the fact that it is available at a reasonable price (with respect to performance/price ratio). And being able to use the Onefinity Controller hardware would be even cheaper – but as said above, I didn’t try it yet. But there is the original upstream Buildbotics.com hardware – and the open hardware pcb so you could even make your own hardware of it (just as Onefinity did).
What I would see as the first thing to do is to integrate the bbserial.ko kernel module into the DKMS and the Debian/Raspbian package system and to free it of its hardwiring to an ancient kernel source, as I described here:
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
12
Note that if you want to contribute code, it is best to provide it in unified diff format:
--- lars1.txt<->2023-11-15 12:51:03.782044763 +0100
+++ lars2.txt<->2023-11-15 12:51:25.438099881 +0100
@@ -1,15 +1,18 @@
+const xSafeProbeOffset = 20 + cutterDiameterMetric / 2.0;
+const ySafeProbeOffset = 20 + cutterDiameterMetric / 2.0;
+
G91 G0 Z ${zLift}
-G91 G0 X 20
+G91 G0 X ${xSafeProbeOffset}
G91 G0 Z ${-plunge}
-G38.2 X -20 F${fastSeek}
+G38.2 X -${xSafeProbeOffset} F${fastSeek}
G91 G1 X 1
G38.2 X -2 F${slowSeek}
G92 X ${xOffset}
.
G91 G0 X 1
-G91 G0 Y 20
-G91 G0 X -20
-G38.2 Y -20 F${fastSeek}
+G91 G0 Y ${ySafeProbeOffset}
+G91 G0 X -${xSafeProbeOffset}
+G38.2 Y -${ySafeProbeOffset} F${fastSeek}
G91 G1 Y 1
G38.2 Y -2 F${slowSeek}
G92 Y ${yOffset}
The reason is that such a diff file can be applied to the source code with patch directly.
Also you’ll have to mention the file name in the source to which your proposed change should apply. In unified diff format, it is added automatically, I used “lars1.txt” and “lars2.txt” because you did not give any filename.
Also I believe OnefinityCNC expects bug reports or enhancement propositions rather under Firmware (Buildbotics) in the forum, than on onefinity-firmware/issues on their github.com repository. At least the few number of filed issues there leads to that impression.
By the way, are you referring to probing with a surfacing bit? Using the Three-axis Touch Plate and the ‘Probe XYZ’ algorithm on Jog Pane with a large surfacing bit or a V-bit is not possible. See here.
Besides of that, taking into account the bit diameter to adjust probe offset makes the procedure smarter
I could add a patch but that makes more since if I would add a pull request with my fix. In this example I just added the issue and a suggestion on how it could probably be solved, the patch would not work since it mixing javascript const in a text string. But I added a link to the section with the file in the issue highlighting that parts that need bit compensation.
The problem saying that you can’t use probing for surfacing bits it that you expect it to be common 1" bit with 3 cutter where there can be problems with which part that touch the probe. But I have a 20mm bit that would work great if it wouldn’t crash into the probe when moving in X direction due to insufficient bit clearance.
Btw I manage to get the onefinity-firmware project to build on a newer build system last night (Ubuntu 22.04) but there it some changes that need to be done to work.
gplan:
Need to switch to a newer raspberry image since stretch it no longer available in the repositories so I used buster to build that one.
There was also some issue with compiler mismatch with the old kernel release for bbserial but that only affected the kernel setup and not the model build.
I haven’t tried it out yet, need to get a spare raspberry pi3 to use for development.
But it is clear that this need to be migrated to newer version soon. It starts to get really hard to get all components that is needed to build it.
Will make my fork available soon on github so it is possible to talk around it.
Haven’t had time to look into the source for the bbserial and I don’t really know why this is needed if there is a custom handling for the uart protocol or why it can’t use the build in serial drivers in linux to communicate.
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
14
That’s what I meant with the bbserial kernel module being “hardwired to an ancient kernel release”. It’s a dirty hack that was never replaced by a serious solution by the buildbotics main developer. Further integration of the kernel module into the OS was dropped as soon the serial interface to the AVR Mainboard that it provides did work. You know that: Once you get something to work, you stop working on it. Problem is, with the present situation of being “hardwired” to an ancient kernel source, you can’t compile this module if you updated the system’s kernel to a recent version, and if you don’t have this kernel module working and running, you have no CNC controller, but just a Raspberry Pi, with a CNC User interface that does not find the AVR mainboard with the CNC driver hardware.
On Debian/Raspbian (and its derivatives like Ubuntu), the only serious solution for a separate kernel module like the bbserial module is to integrate it into Dynamic Kernel Module Support (DKMS) so that the module is recreated automatically after every kernel package update on the system. And it would be necessary to make ‘bbserial’ and ‘onefinity-firmware’ or ‘bbctrl-firmware’ each a proper Deb package (which is still not the case ) that have their package dependencies defined, and be installed, deinstalled, upgraded or even downgraded with apt. How one can learn to do this is explained in debian.org/doc/ → Introduction into Debian Packaging and of course debian.org/doc/ → Debian Policy#Binary packages has to be observed.
I got one a few monthes ago but it was the last one available at that time. But why not use Raspberry Pi 4. Since it has much more graphics capability, it could show the camotics 3D toolpath simulation which the Pi 3 can’t do (provided the mesa 3d acceleration graphics drivers get installed)
Image: In order to see the 3D toolpath simulation, it is necessary to use the User Interface from a remote computer that has more graphics capabilities (and some 3D graphics drivers installed). This simulation is not shown on a HDMI monitor directly connected to the Buildbotics/Onefinity CNC Controller.
Usually you need real-time operating systems when you build a CNC controller. As you may have noticed above, the Buildbotics does not use the asynchronuous serial communication (UART) functionality (two-wire) of the Raspberry Pi but a synchronous serial interface (three-wire, see circuit diagrams that I included above). That is what is programmed in the bbserial kernel module.
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
16
Hey Lars,
I strongly recommend to avoid using the GitHub platform, for these reasons. If you are for Free and Open Source, you got to be aware that Microsoft’s GitHub platform violates the ideals of free and open source software consistently and in more than one way. If you really think you need a combination of public code repository and social network, I always recommend to better use one of these:
GitLab Community Edition (note, the GitLab Enterprise Edition, which is provided to the public on gitlab.com, is (like GitHub) trade-secret, proprietary, vendor-lock-in software)
But you can also work very well together with other people on codebases completely without any of such platforms. Look at the Linux Kernel Project, which is a very important project, with many, many people contributing code to it. It does not use any of such platforms. In order to work on it, you just need a local installation of the Free and Open SourceDistributed Version Control software git (which I strongly recommend to install anyway, in order to be able to work on multiple versions and branches of the code), and a mailing list (here: the Linux kernel mailing list (LKML)).
You don’t need anything else than these two things to work on open source code with the community. That is why I think it is important to know how to use git anyway.
Using things like the GitHub platform (and specifically, thinking that it is necessary to work on code with other people) is just a current fad because everyone wants to have everything in a social medium and sees nothing wrong with the fact that the means to realize collaborative work on codebases and the necessary communication are not their own (as with git and majordomo), but must necessarily belong to some crazy billionaires who exploit them with catalog-long terms and conditions with advertising and data collection. But that’s the way people are at the moment. But I think that will pass.
Abstract—There is burgeoning interest in designing AI-based systems to assist humans in designing computing systems, including tools that automatically generate computer code. The most notable of these comes in the form of the first self-described ‘AI pair programmer’, GitHub Copilot, which is a language model trained over open-source GitHub code. However, code often contains bugs—and so, given the vast quantity of unvetted code that Copilot has processed, it is certain that the language model will have learned from exploitable, buggy code. This raises concerns on the security of Copilot’s code contributions. In this work, we systematically investigate the prevalence and conditions that can cause GitHub Copilot to recommend insecure code. To perform this analysis we prompt Copilot to generate code in scenarios relevant to high-risk cybersecurity weaknesses, e.g. those from MITRE’s “Top 25” Common Weakness Enumeration (CWE) list. We explore Copilot’s performance on three distinct code generation axes—examining how it performs given diversity of weaknesses, diversity of prompts, and diversity of domains. In total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40 % to be vulnerable.
Why Give Up GitHub?
There are so many reasons to give up on GitHub, but we list here a few of the most important ones:
Copilot is a for-profit product — developed and marketed by Microsoft and their GitHub subsidiary — that uses Artificial Intelligence (AI) techniques to automatically generate code interactively for developers. The AI model was trained (according to GitHub’s own statements) exclusively with projects that were hosted on GitHub, including many licensed under copyleft licenses. Most of those projects are not in the “public domain”, they are licensed under FOSS licenses. These licenses have requirements including proper author attribution and, in the case of copyleft licenses, they sometimes require that works based on and/or that incorporate the software be licensed under the same copyleft license as the prior work. Microsoft and GitHub have been ignoring these license requirements for more than a year. Their only defense of these actions was a tweet by their former CEO, in which he falsely claims that unsettled law on this topic is actually settled. In addition to the legal issues, the ethical implications of GitHub’s choice to use copylefted code in the service of creating proprietary software are grave.
For what it’s worth, I was able to spin up a Debian 9 VM and fully compile the latest Onefinity firmware (1.3.0) with only a few minor changes. All other instructions from the docs are the same.
Add valid source for Debian 9 to /etc/apt/sources.list.
deb http://archive.debian.org/debian stretch main contrib non-free
After installing the required packages, install NVM and Node 16.
From the project directory and before running make, execute the following command.
This will add a new line to the start of src/pug/templates/console.pug to allow build/templates.pug to generate correctly. This is only meant to be a temporary solution.
sed -i '1s/^/\n/' ./src/pug/templates/console.pug
After running make from the project directory, and before running make gplan, you must prepare for the outdated Raspbian repository.
nano ./scripts/gplan-init-dev-img.sh
Add these (2) lines to the file before the apt update command.
(This is for the rpi VM source list. It is not replacing the Debian source list.)
Everything (make, make gplan, make pkg) should be able to compile successfully.
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
18
Hey Matticustard,
And when you put this on a Raspberry Pi OS bootable SD card and boot it on a Onefinity controller, does it load the ‘bbserial’ kernel module (lsmod | grep bbserial)? Because only when the ‘bbserial’ module is compiled and loaded successfully, the controller will find the AVR mainboard and its stepper motor drivers. Otherwise you just have a *bian system with the Onefinity UI installed, that reports only errors.
Anyway, even if you succeed with building the recent verison of ‘onefinity-firmware’ source and run it on the ancient Raspberry Pi OS 9 ‘Strech’ system from 2018 that Onefinity provides, this does not address the original poster’s question who wants to both
I realize this was not the original poster’s question and I am well aware of your opinion on the Onefinity firmware. Despite your objections, I believe there are still people who are interested in the opportunity to play around with it. Additionally, I was responding directly to another user (lars, not OP) who indicated their attempts to compile the Onefinity firmware on Ubuntu 22.04.
As it is, I have uploaded the resulting build to my controller and it is not perfect. However, the problem does not seem to be with bbserial, but it is instead with the Vue web interface. I will see if I might be able to run down the problem later this weekend.
More testing will be required to determine any and all other issues.
EDIT: I have diagnosed the issue on my end to a malformed structure in ./build/templates.pug. It fails to add a new line before the console template, the last template in the file. I do not know why this is occurring. This can be temporarily addressed by adding a new line to the start of ./src/pug/templates/console.pug until a proper solution is available. From the project directory, run
sed -i '1s/^/\n/' ./src/pug/templates/console.pug
before executing the make commands. The firmware now appears to be fully functional on my controller. I will add a note of this to the list above as well.
1 Like
Aiph5u
(Aiph5u (not affiliated with Onefinity))
20
Hey Matticustard,
Yes, of course, and I’m sure they’re grateful that you’re showing them what’s possible without (greater) effort, perhaps also to lower their inhibitions. I like to encourage people to try everything out, especially with open source software.
Okay, but that means you have still the “hardwiring” to the ancient kernel source:
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.
…it is “hardwired” to the official GitHub repository of the Raspberry Pi Foundation instead, which means, the organization from which a standard Raspberry Pi OS installation gets its proprietary kernel and bootloader images from as per /etc/sources.list.d/raspi.list.
So I would ask, why in Onefinity’s fork is ‘bbserial’ linked to a private kernel source copy instead of the official raspbian kernel source?
PS2: When I surfed around on the buildbotics site, the other day I saw that they do have more recent SD card images of Raspberry Pi OS on hold (for whatever reason ):
) that have their package dependencies defined, and be installed, deinstalled, upgraded or even downgraded with 
