Hmph…sounds like IOT writ small…(now every lightbulb needs glib.c patched)
@foosel you ever use Sailfish? It has centralized dev control, and runs about a quarter of the world’s consumer/hobbyist printers, including over a dozen commercial printer manufacturers (like FlashForge), and it’s almost never forked. It’s mature and has a good featureset as-is and as a result people simply don’t screw with it much. (An OctoPi rounds it out nicely when people want more features.) The problem you’re describing comes from people who want special one-off features and pet projects incorporated into a large-scale community project, and I would argue that Marlin’s slow cancerous decay is proof we simply shouldn’t do that! I would STRONGLY discourage people from piling features into a performance-sensitive embedded hardware control system. It’s bad practice to allow uncontrolled feature adds in this sort of application, period.
This is a strong argument for two-board systems or big/little boards, where there’s a high-performance embedded system that only gets touched by a core dev team and a separate non-RT platform (like Octoprint or PanelDue) to do the heavy lifting on manufacturer-specific features and whiz-bang stuff.
I would argue that sailfish is also rarely tampered with because most printers running it (at least that I’m aware of) are commercial printers targeting consumers rather than hobbyists, including more or less closed workflows, so people who wouldn’t even know that it could potentially be tampered with. Which is ok of course, but doesn’t solve the issue that once you do attract that crowd you have to be prepared for the issues that come with that. “xyz shouldn’t be done” or “it’s bad practice” simply will not stop people from doing it, period, no matter how right it is. It will not stop companies from doing it because “product vision” or “usability”, and it will not stop hobbyists from doing it because “shiny new toy” or “innovation”. So since one can’t prevent it from happening (and let’s face it, in most cases actually shouldn’t because it’s ok that people have diverse requirements), I’m arguing for limiting the consequences (unmaintainability/fragmentation) through design, and for an as-lean-as-possible base layer.
How that is implemented in hardware I honestly don’t care about at this point (it’s all academic anyhow at the moment), but you will not prevent fragmentation by forbidding enhancements, and you desperately need to to mitigate another version chaos. And - naturally - you don’t want to have an “anything goes” situation like now with Marlin either, I think we all agree that this is the best way to kill any project, regardless whether it runs on an 8bit avr or a full blade cluster.
Along the lines of @foosel 's point – I think simply that everything should be developed in such a way that it’s completely modular. The old unix philosophy - do one job, and do it well. The firmware’s job should be to handle machine geometry, handle gcode input, and anything past that should be what basically amounts to a ‘plugin’. Something that the rest of the code does not depend on, stands largely alone, and when disabled does not bloat the control-space.
@foosel no real disagreement there. I personally think separating firmware from software is how you get to that point, but there are multiple valid approaches.
The reason we’re all still using old-ass GRBL algorithms is because the meat-and-potatoes of 4-axis motion control is simply too hard/complex for the vast majority of people to do. I only know a few people in the world who have the necessary skills, desire, and time to work on the actual low-level motion control stuff. For example, to work on improving acceleration/dynamics, you have to delve deep into the performance-critical interpolation/DDA code that almost no one understands.
Separating that complex core from the stuff hobbyists want to bang on (features) would really improve the codebase. Multiple ways to do that though.
@ThantiK what you’re proposing ends up being pretty resource-intensive, which is why Smoothie v1 is out of RAM. You can port to faster hardware (like Smoothie v2) but that’s basically a delay tactic for another X years until that new hardware is tapped out too. (Say, when somebody implements native NURBS slicing and spline paths. Or whatever.) Whereas RTOS solutions divorce the difficult-to-modify core codebase from the hardware platform. It’s a much more long-term viable approach. (Not saying any of today’s RTOS options are there, just that it’s a better model.)
@Ryan_Carlyle , Then we should just simply jump straight ahead to something with a lot more power and an RTOS option - Or something with PRUs like the BBB. Or even maybe divorce the motor control over to a PRU-like-processor.
@ThantiK And that’s why I’m very curious to see how Replicape/Redeem develops over time.
@ThantiK we agree. We rewrote Marlin (not sure what to call it now) to just handle gcode and the motion. Everything else is optional… Like a plugin. I’m sure I’m over-simplifying but that’s the big idea. People will, I’m sure, add in all sorts of things but using json for that and more keeps it sain. We are looking to the work that Tinyg did to make sense of the mcodes. All non essential codes are separated from the essential motion commands. While we don’t assume people will run to our solution, it could at least help the conversation. We will at least have a new approach that works well, removing the Marlin-pain, and that should excite developers that are used to clean, well organized, code who want to do their own thing without having to dig into the black hole of the Marlin learning curve.
I realize it’s not that helpful until we release the code and show details, but I don’t see anything else that has developed from (almost) the ground up to not only fix things that were broke, but add wifi and touch LCD. The wifi and touch are a separate electronics totally separate so the UI is now a separate beast- no integrated LCD menus, etc. we are calling it “printrhost” internally.
We are currently working to see if we can figure out over the air firmware updates for printrhost and the printrboard… Not trivial.
The printrhost can currently load gcode over your local network, but it’s too slow, so we need to add ram to make it fast.
Once we finalize the hardware, and make a run of 100, we will offer beta/developer boards to get some widespread testing before selling it.
We are putting Printrbot’s needs first, but since it’s open source, the community may want to bend it to their own desires and needs.
Keep the firmware as firmware IOW minimal amount of RAM to run lean and efficient software
The add-ons should be RAM intensive for the machines that need to run those specific applications
The printrboard will be pretty much the same. The Printrhost electronics will be all new- that’s where we put the UI, wifi, touch screen, ram, hidden Sd card for storage.