@bot said in 6th-order jerk-controlled motion planning:
@dragonn axis compensation was added to accommodate improperly built printers.
Why should we not be aiming for theoretically perfect? It's a much cleaner approach than simply applying bandaids over dirty bandaids.
The problem of achieving perfect prints from FDM has already been solved, and Duet electronics with RepRapFirmware already allow it. Speed improvements and "vibration reduction" has thus far only been proposed for mechanical systems which are less than adequate. I don't buy into this, at all. If this type of direction is pursued with the main branch of RRF, I will be considering the maintenance of a new branch designed for long-term support (ie, more locked down features) and geared towards high-end professional hardware.
TL;DR Great idea! I think that would be a huge benefit to the community. I would be happy to help with this endeavor; assuming that it can be done in conjunction/co-operation with @dc42 and @T3P3Tony to avoid fragmenting the RRF user base as that has a tendency to undermine the value of both projects.
I think an argument could be made that something similar to this approach might be valuable regardless. Many software packages and platforms follow an approach similar to this. For instance the "Long Term Support" version of node.js is currently 8.x while the "Latest and greatest" is 9.x this allows users of the system to choose a path that they are most comfortable with.
I think that in some ways @dc42 is following this now albeit without a ton of formalization around it. For instance he mentioned in either the 2.0 thread or the 1.2.1 thread that he would back port critical fixes from 2.0 to 1.2.1 in some cases. Once 2.0 is stabilized and considered the gold standard I think it could be very cool to have two options to choose from "stable" and "latest".
One of the greatest things about the RepRap community is that many of it's members are always challenging "state of the art" and "good enough". This has resulted in some amazing things (The Duet, 32bit motion controllers, new kinematics, the flex3drive / zesty, PEI print beds, dual extrusion, linear advance, piezo sensors, olsson ruby, laser filament monitors, etc...). It also has resulted in a lot of dead ends, failed concepts, bugs, fires, and forum debates. The constant desire to improve if only by a few microns is one of the reasons that FDM printers today are so amazing and useful.
There will always be people trying to compensate for poorly constructed machines by changing slicer settings, trying new firmware features, and/or putting an olsson ruby on a machine that only prints PLA. One of the first things I tell anyone getting in to 3D printing is "don't even try auto bed leveling until you can level a bed by hand". Obviously some software and hardware features have made it easier to have a "less than perfect" printer and achieve decent results. This has lowered the barrier to entry for 3D printing. This is a good thing! A lower barrier to entry means more people using / buying products which results in new products (like the Duet), and lower costs (manufacturing efficiency due to volume). There is nothing wrong with these people, in fact, they are CRITICAL.
There are also people like me who will redesign parts, spend hours printing them, and rebuild an entire machine because I want to PLAY with a new sensor, motion, or cooling concept. These people will obsess over the math behind .9 degree stepper motors, 6th-order jerk controlled motion planning, the amount of deflection in a delrin wheel, how thermoplastics bond at various temperatures, the G-code generated by a slicer, the thermo and fluid dynamics of melted plastic, layer adhesion, etc. We are annoying as hell, opinionated, passionate, and constantly looking for something new to play with in the hopes that we can somehow eventually print a Cessna or something. In reality we will probably pretty much just print new parts for our printers...forever.
There are also people that use their printers in a mission critical environment and while I contend that the fact that they can do this is very directly related to so many people pushing the state of the art for so long; it doesn't change the fact that they need things to "just work".
There is ample room for all sets of ideals, goals, and passions in this space; and quite frankly none of them are going anywhere and all are necessary for the continued success and growth of the industry. Curtailing the experience of one group for the benefit of another can spell the end of innovation, the end of progress, and ultimately that hurts everyone.
@dc42 and @T3P3Tony are obviously quite busy, have business to run, and donate a TON of their personal time to the support and maintenance of their products and the community as a whole. I would never dream of asking them to do more than they already are so perhaps someone stepping up to help maintain a "stable" branch of the firmware and only bringing in new features when they are proven to either be at a minimum benign, or at best useful could be huge. Most of my real-world C/C++ experience is in developing against OpenGL on iOS but I am already planning on jumping into some firmware development for the Duet and would be more than happy to assist with the maintenance of something like this; but only with the blessing of @dc42 as the last thing I would want to do is accidentally fragment the RRF user base as I don't think that this would provide value in the long run.
-M
