Just throwing this out there, but if an alternative firmware came out (Ie, not Marlin) what would be the features you would expect to have and be able to use on those 8 bit avr boards? E.g. Delta kinematics is a pain on those, so don’t support delta for example. Keep in mind that Marlin is an unorganized mess because of several reasons one of which is a ton if added features on a board you can’t do much on in the first place.
Or, alternatively, do you feel it’s better as a whole to move to larger boards with 32 bit arm chips?
8bit AVRs date back to the late 1990s. They were fine when everybody was running Cartesian bots at 40mm/s with no features, but they’re WAY past prime at this point.
Even 32bit ARM Cortex-M3s used in the Due and Smoothieboard date to the early/mid 2000s. And they’re already running out of resources before even fully replacing AVRs. People want more features than M3s can realistically handle.
They’re not quite there yet, but real time operating system controllers like Redeem and MachineKit on >1GHz single-board-computers are the future.
Personally I agree that an RTOS is the future as well, but the cost in building one is a bit high right now. Plus if we go that route I want drivers that can actually handle encoders
How cheap do you want? A BBB+CRAMPS is $135, that’s competitive with 32bit M3 boards and vastly more powerful. Cheap Chinese capes would bring that down more since the BBB is only $55.
32bit MCUs don’t even cost more than 8bit - we’re only using them because Arduino, so if you can live without Arduino compatibility, 32bit is the only real option.
I think that it also needs to be as pain free as the arduino. Granted, it does require a bit of know how, but it is not rocket science, nor does it require a PHD to set one up… Look at the new Raspberry Pi3… $35. How much would an add on board be to control the steppers, etc? For what I do with mine (hobbyist), I cannot justify and extra $140 for another board when the ‘old’ standby - atmega2560 and ramps work just as well for under $50 (edit: for my needs)…
I really think the new smoothie2 should be released, and then people should be taking that board, and the chosen IC, and building specific boards for specific tasks. I’m certainly interested in doing a drop-in K40 laser controller based on the new board.
@Justin_Nesselrotte why don’t you just use Repetier? It out-performs Marlin on both AVRs and ARMs, has nearly the same features, and doesn’t have even half the bloat issues. It’s also optimized well enough to handle things like delta kinematics with an 8bit processor.
For people discussing cost here, you gotta remember, low prices come from VOLUME. Mega/RAMPS is cheap because it’s mature (old) and there is enough demand to get scale production going in China. The actual BOM cost isn’t driving prices.
“New hotness” boards by definition won’t be at scale yet. And they have to bear the cost of original R&D. So to a good approximation, your basic choice is between “old and cheap” or “new and expensive”. It’s completely unreasonable to ask for higher performance, at the same price, without waiting for scale adoption.
The way we develop and grow alternatives is by sucking it up and paying a little more in the short term in order to reap rewards down the road. If you just want to pay $40, fine, you can do that, just don’t complain about performance.
@Keith_Applegarth some of the 32bit boards are WAY easier than Arduino. Smoothie and RepRapFirmware have text config files on an SD card and no need to ever build your own firmware. Super user-friendly.
@Ryan_Carlyle I disagree with Repetier on an ethical level even though I still use it. Plus, they’re not consistent with GCodes either. Not as bad as Marlin but still.
Also, having bought a ramps when they were first a thing for like $200, I know that volume helps, but also the ramps does a lot of cheap things that were made cheaper.
Not a fan of RTOS on embedded systems - Smoothie is going in a very good direction, I wish more people were using it, developing with it and supporting more tool-chain development based on now and future power.
It’s really time to move on from Arduino for Machines…
@Justin_Nesselrotte can you expand on the ethical issue? First I’ve heard someone raise that. As for gcodes, 3dp is vastly screwed up in every way if you actually look at the underlying CNC standards, Marlin’s dozens of ad-hoc mcodes are a big offender, and MachineKit is the only option I know of that actually complies with standards.
@Mike_Miller NURBS and spline paths would be awesome, but that will require abandoning GRBL-based motion planners and probably even gcode entirely. That’s a whole new toolchain ecosystem all the way from the modeling software to the printer controller. EG it’ll exclude surface mesh based modeling programs entirely. Not gonna happen in the open source world, there’s too much “chicken or the egg” for it to be developed without significant corporate funding.
The only way that a firmware could succeed (= gain a following that justifies creating one in the first place) given the heterogeneous printer market is by being extensible without losing maintainability. And the only way I see to prevent platform fragmentation like we have it now with Marlin (thousands of forks in various states that are rarely or never updated with fixes) is to build it with printer model specific configuration decoupled from the actual firmware implementation, ideally backed by a printer config repository with an attached build platform (one click download of the most current stable version already configured for printer model x, just flash and enjoy).
Marlin tries to achieve configurability through ifdef hell based on a bunch of configuration header files - and fails because the source sadly is pretty much unmaintainable at this point. And any bug fixes done to Marlin take literally forever to propagate through the thousands of forked versions flashed to printers. That is something that would definitely need to be prevented from happening again.
So basically, how I would tackle that (if I had the time, which I don’t) is:
make the whole code base modular - C++ has classes for a reason, they should be used for proper abstraction, it’s not like abstracting the functionality within a 3d printer’s firmware is rocket science and there are enough established patterns how to tackle even the most tricky of modeling situation
only implement the absolute bare bone functionality in the base code - motion control & planning, maybe (!) temperature control, communication layer, that’s it
allow compile time extension with community contributed feature modules (thus preventing feature creep, this is where all that fancy leveling, lcd, sound, whatnot stuff goes) - for that the base would need to establish extension points that allow for that, stuff like adding commands, adding functionality into the idle loop etc, and the tricky part here would be to prevent extension from slowing down everything
create a build system that allows mix and match of base + wanted modules + printer specific hardware configuration
make everything testable through automated (!) tests - if possible not only unit tests but integration tests through hardware emulation, encourage proper test coverage in modules as well
I have next to no experience with embedded programming but personally I would hope that with some proper modularization that gets merged at compile time that should still be possible even on 8bit. But it’s really not my area of expertise, so… in any case, I don’t believe there’s much future in that architecture anyhow, so I’d probably rather suggest going for 32bit.
In any case, to reiterate (because this is really my key point) I think more important than what features or not to include is really to rather design a firmware in such a way that no matter what the answer is to that question it will still not become a code base that causes eyes to start bleeding, and make it easy enough to configure and share certain builds that it is not necessary for everyone and their mother to maintain their own fork just because the pin table looks slightly different.
And of course, before even thinking about yet another firmware: protocol specification, protocol specification, protocol specification.
@foosel Most of the more “modern” firmwares (eg Smoothie, dc42-RRF) are “one build for all” with a single distributed binary and plaintext config to handle all necessary printer-specific stuff. That DOES require having a central “owner” for the code that decides which features to include/exclude in the main branch. Or there’s MachineKit, where the hardware-specific stuff is all implemented via a distinct HAL without needing to compile it in. Either model is fine. (The former is more user-friendly, the latter is more powerful.)
The #ifdefs in Marlin were a response to tiny program memory space, more than anything. Completely unnecessary with modern hardware.
@Mike_Miller MachineKit’s blending mode already sort of does that, it will round off corners and such to keep speed up without violating acceleration limits. But in general, if you’re going to interpolate between gcode waypoints, the firmware is basically reconstructing the model intent from scratch. That’s 1) lots of computation that even ARM M3s won’t be able to keep up with* and 2) going to involve a lot of guesswork to try to reconstruct the model intent. For example, do you draw the inscribed or circumscribed circle when smoothing out a faceted arc? There’s lots of ways for that to go wrong.
RepRapFirmware already maxes out the Due/Duet’s 32bit ARM M3 just using exact path interpolation for deltas rather than segmentation… And that’s only part of what you’d have to do for generalized facet smoothing.
That DOES require having a central “owner” for the code that decides which features to include/exclude in the main branch
And that is something that means endless forks, at least one per hardware vendor. Which means fixes not getting merged in a timely manner, which means a very bad situation for projects that need to interface with printers (think host software like OctoPrint). That simply doesn’t scale.
I’m not only talking (just) about hardware abstraction here. I’m talking about feature abstraction too. One person wants to have some fancy menu system with filament swap and bed offset wizards and whatnot. Another wants auto leveling. Yet another wants the menu too, but without the wizards. Yet another wants an mp3 module to play yakety sax while the printer is running, or a regular ping towards his DSLR to take a picture when the print head is at a specific position.
If you try to find a “one size fits all” solution here without external extensibility in mind, you either end up with a horrible mess of a code base which you are responsible of maintaining even if you don’t even have the hardware to test, or you alienate contributors which then go and fork and contribute to the platform fragmentation. Both is pretty undesirable.