There are actually quite a few controllers / systems that can achieve this as well. I’m actually opting to test one ( CNC xPRO V5 / more info, along with CNCJS on the software side).
But lets not kid ourselves either - 1F DOES require an “external” computer - in the way of the Raspberry Pi (we can debate semantics all day long on whether this is “external or not” - fact of the matter, you can have any other form of tiny PC / SBC built into the same enclosure as the controller board, and it’s the same thing). I think the touch-screen tablet (interface) is really what most are considering “built-in”.
In the above case, I’ll actually try running CNCJS on a Pi as well (NodeJS). It has support for small screens/tablets as well. I’ll probably run from keyboard/mouse/monitor during testing (ease of use) - but I’ll try it on the tablet as well for those interested.
I plan on documenting this trial as well to let everyone know how it goes.
As-is a few of the benefits:
GRBL based (so lots of apps/code that supports it).
Ability to adjust Feed rate on-the-fly (Buildbotics, the way the controller processes the code, this basically will NOT be possible without some major hacks - one of my #1 reasons for dropping BB). I know for those who have proven recipes, or run production, this might not be an issue - set it and forget it - but I experiment a lot, so the ability to adjust the feed in real-time is a requirement.
Better maintained - the BB source doesn’t seem to be contributed to much, I know 1F is pulling their weight and making adjustments now that BB has a large audience, but with only open-source live releases (no visibility into dev/beta), nor willingness to expand this, I’d rather not rely on it.
TBD - Still determining whether it (or any GRBL based system) can perform a “resume from here” function.
This is all an experiment, mostly because I can. If it all fails, I’ll revert to my initial test of the Centroid Acorn controller (as I know it’s a proven solution for me).
It is great that you are doing this, @wolfkabal and even better that you are willing to share/document your experience! I am quite underwhelmed with the BB platform esp. your observations about the state of the code base. Good luck and keep us posted!
Thanks Tim - completely agree about BB. Seems to be the major drawback of an otherwise excellent machine. Also agree the OF does have a ‘computer’ - just not separate from the CNC like most tethered solutions. Pros and cons of both.
Just thought I’d add that I’ve found out why the BB control program does not recognize new uploaded files right away. It appears that upon boot it looks at the directory and post-processes all the uploaded files (all .nc in my case) to additional control files. These can be found in /var/lib/bbctrl/plans. So, it’s not as simple as the Gcode being directly transferred to the AVR controller after all, and simply uploading the file via samba does not do the same thing as on other systems.
I’ll definitely follow this also. I have found the 1F to be very useful and accurate but streamlining it and allowing some customization is also very important. But I’m with you on the ability to experiment. I definitely want a web based control option also since that has proven to be worth a lot in managing multiple devices centrally as well as locally. At least that’s how BB is oriented. The interface to the AVR controller in the BB system appears to be almost completely custom and likely has some performance advantages.
I know several people who are using CNCJS and love it, but I’ve not tried it.
Would a 3d printer control board like the duet wifi run this? Basically the controller just needs to convert G code into movements via the stepper motor drivers correct? The interface for set up, on the duet, is easy to use. You can make speed changes on the fly etc. You can pause for tool change and resume. I don’t have a, start from here, option though. Can set up macros for multiple starting points etc. Also has multiple extra drivers for 4th axis. Can send files directly to the board via wifi.
Randy - there has to be a way to trigger the post-processing, or the upload from the browser wouldn’t work properly. Wondering if you can write a script to monitor the directory and trigger post processing when I new file shows up? Maybe the post-processing is just for the CAMotics? Most controllers (e.g., grbl) take straight gcode and process it on the fly.
I’m sure there’s a routine that does this on upload, but the firmware is pretty opaque at this point. We have the sources, but modifying it without a full recompile does not seem likely.
I’ve looked at this option also. The fairly recent advent of well-made smaller CNC platforms like the 1F have sometimes been able to use 3D printer controllers. I use a Rambo board on a MPCNC setup with the host running Octoprint. This works surprisingly sell for a CNC setup of this size. However, the current specs for the NEMA24 motors on the 1F are 2.8A, where the spec for NEMA17 (the normal 3D printer stepper) is usually around 1.8A. I’m sure there are some others that would work.
But, I’d rather use the existing setup without additional cost. The problems with customization, accessibility, and update I hope will get better, but if not some of us are looking at other options just for productive workflow.
sftp seems to work. Used FileZilla to upload the new firmware to the machine, and loaded it through the web interface. Sill missing part of my machine, so can’t try g-code yet, but that should be coming in the next day.
Uploaded the file to the bbmc user home directory, then ran the interface. Seems to work, and no USB device!
Ahh, I should have read more carefully, you’re trying to go one step further than I did. I used sftp to get the file to the pi - you’re trying to get the file uploaded to the pi and “into the system” (ie., in the drop-down of available gcode) all in one step. I still need to do a 2nd step of loading the file.
You can also upload a local file by running the interface (http://onefinity.local/), instead of copying the file and then loading it at the machine. It’s not perfect, but it’s not horrible. Surprised wi-fi works so well - haven’t had to use an external wifi antenna yet, didn’t think wifi was that strong in the shop.
Sometime later, I want to add a 4th axis - that will mean getting a 2nd controller. But, this is all new to me, so I have a lot to play around with before I get that far!
I had a little free time today and decided to try setting up the SMB share. As you guys have noted, you can put files in the shared directory as well as delete files, but the BB web interface does not recognize the changes unless you restart. Having looked at the BB code for other purposes, I can say fixing this won’t be a trivial change. The software is keeping its own list of files, not actually looking in this directory in real time. The best way to deal with this would be to add a “Refresh” icon alongside the upload and download icons, which would force the BB software to re-read the directory. I am thinking it won’t be high on @OnefinityCNC list to address this. I might try poking around at the code but I have no experience with Python so this is probably above my pay grade.
The code is actually there already (in python /src/py/bbctrl/State.py load_files() ) but as you indicated, this function only runs at initialization [init()] - I’ll see if I can do a quick change on the JS side to call that, and get a PR in for v1.0.7
Great! Glad you were able to track that down so quickly. I was thinking if I could figure out the code (which you’ve now done) maybe hijack the Download button, which I never use, and just have it call State.py load_files() on the back end. This would just be a temporary hack until OF addresses it, hopefully in 1.0.7. Or even just open up a terminal window and run the script interactively. Anything beats a reboot!
When you upload a new file, the UI has to trigger that function to register the new file, so adding another button should be relatively trivial – unless the upload simply reloads the whole page - then you need to hack the init script or something. Anyway, standing by - let me know if you need help Tim.
You’re way ahead of me here, and clearly more familiar with the programming environment. Mine is from designing assembly code and microprocessors, so a bit lower level…
Do you know how the firmware is structured and combined from the various languages? JS, Python, some C, etc. I see the firmware is run from under Python, but where do the JS scripts reside and why can’t we simply modify our own instances of the JS and/or python code. Yes, I know it’d be a special branch but I’m confused at the structure.
I frankly would not be unhappy keeping some changes updated on just my machine, and redoing them on updates.
Hey Randy - I came from the embedded programming world, but did web programming for a few years. I’ll freely admit, I don’t get what BB has done with the software. They are using all sorts of frameworks that I’m sure simplify things, but it also obfuscates the obvious things. If you want to dig into it, poke around the git repository - there are JS files there along with Python (which is 100% server side code), HTML, and other things. Since the whole thing is far more complex than I think it should be, I’m not too interested in investing the time to figure it all out, hack it, and get the results I want. Just my 0.02 or so.
It is very confusing and I’m sure makes sense somewhere. But, all I want to do is modify one of the JS files and I can’t even find where they reside. Since you’ve done web programming perhaps you have a clue? Where does the control page reside on the rpi?
This! - I had the same thoughts - it’s just some Python and JS, admittedly my coding is more old-school (Java, .Net, Assembly, and later Python - JS is my weakness). Documentation on the actual code is non-existent, though credit is due and hardware (PCB) is documented quite well.
A quick synopsis though - the front in UI is Javascript (rendered server-side, with Pug for layout template and Vue as the front-end framework (MVC)) - all versions are a bit behind though on their core versions). This is what your browser runs.
There’s a web-server written in Python, which is what is running on the RPi, this has a REST API which is what the JS (Vue) makes calls to, for the actual heavy lifting. In addition, some C++ compiled down for the serial interface with the BB board.
For the most part, these are the two parts one would need to touch, unless you want to get down into actual firmware for the BB chipset.
This is based on my reverse engineering, and minimum documentation available.
This is more of a CS question than anything, but since the webpage is served by the rpi, even though the JS is run in the browser there must still be a JS source file for that page on the RPI somewhere. I’d be happy to hack this if I could find it. I can’t. I tried searching the entire disk with find but nothing.
