6th-order jerk-controlled motion planning
-
Yeah - this should be an option, at start this could be even a build option. We could compile it and post a version with this motion planer in this thread for testing.
-
@carlosspr said in 6th-order jerk-controlled motion planning:
@deckingman said in 6th-order jerk-controlled motion planning:
What concerns me now is that a new motion system may not be something that I could choose to use or not.
Agreed. A new motion planner should not be a replacement, but rather an option. But there is no reason to deny the feature that according the marlin posts is showing a big impact on printer vibrations.
There are many algorithms for motion planning in the technical literature and a proper software architecture would allow to select which planner to use. Marlin team has solved this issue with a compilation directive that you can define or not in Configuration.h when you prepare your firmware letting you the option to use it or not.All very true - and I'm not denying anything. It's just that the balance of evidence as I see it leans me personally towards the opinion that the introduction of non-linear acceleration in FDM printers is unlikely to achieve any measurable improvement, and may even be detrimental. However, if evidence is forthcoming which is based one more than just assumption or anecdotes, (i.e clear evidence of improved print quality) then that will of course change the balance and I'll happily change my opinion. I'm just trying to introduce a measure of caution. Just because technical papers have been written does not automatically prove anything until the theory and assumptions therein have been tested.
-
@carlosspr said in 6th-order jerk-controlled motion planning:
... according the marlin posts is showing a big impact on printer vibrations...
I'd love to know how they were measuring and quantifying these vibration differences.
I'm on the side of "don't fix it if it's not broken." And also the side of "if your printer is not mechanically perfect, please don't suggest 'improvements' to the firmware that are meant to correct for janky hardware."
IMO there is no need whatsoever to revamp the motion planning system. I am worried, as someone who is still using an ancient firmware (because it works and I don't change what works) to hear that Ian is reporting problems with newer firmware versions adjusting their behaviour. Firmware should change gradually, in a planned and precise matter. One of the benefits of the Duet ecosystem is the developer support -- one of its drawbacks is the developer support without proper testing and validation.
We should not be tailoring the software to lower common denominators -- we should be tailoring software to theoretically perfect hardware, with some consideration only for hardware errors that are almost universal.
-
@bot said in 6th-order jerk-controlled motion planning:
"if your printer is not mechanically perfect, please don't suggest 'improvements' to the firmware that are meant to correct for janky hardware."
Really? Then why Duet have for example https://duet3d.dozuki.com/Wiki/Gcode#Section_M556_Axis_compensation
"theoretically perfect hardware" - bullshit, we should supply software with works with a practical printer good not a 'theoretically' printer. The world isn't theoretical
-
@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.
-
@bot If we would aim for a theoretically perfect printer we wouldn't have:
- axis compensation
- auto bed leveling
- pressure advance!
- thermal runaway protection!
Software designed without taking the practical aspect how something works is just useless. It is always need to find the point where theory and praxis overlap. And the truth is - ever printer have vibration and just slowing it down is a solution, just a dirty fix. If 6th-order jerk-control will allow as printing with higher speeds and prevent vibrations why should we implemented it? Only because in the perfect theory it is not need? Well -_- I think you should with you 3d designs stay in the the CAD software because this only place when it gonna be theoretical perfect.
Let my ask you - when you a designing something to print you are not taking you printer toleration into account. You are not making you holes slightly bigger so a screw can fit into it? The same rules need to be applied to firmware.
-
@dragonn I said aim for a theoretically perfect printer, and then only add compensation for items which are almost universally relevant: pressure advance being one which I agree with. Auto leveling, axis compensation, etc. are ones which I do not particularly agree with but can live with -- a revamp of the motion control system because a bunch of programmer kids with $200 printers says it's better? No thanks. (Not referring to you or anyone here, but a scapegoat marlin user with the cheapest of cheap printer kits.)
-
@bot I would suggest co calm down. Did you tested it? Probably not.
Calling some one "scapegoat" and "programmer kids" is just rude and only shows you ignorance. They are working on a ASM routine to get working 6th-order jerk motion on AVR-s. Really? Programming kids?! WTF......
-
@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
-
@msquared I couldn't agree with you more. My short answers probably made it seem like I wanted the hobbyists to just leave or something (quite the opposite!! Like you said, we wouldn't be here without them/us).
I also have too limited a knowledge of programming in general to be a main coder on any RRF LTS project, but I will certainly volunteer time and resources to it. As you say, also, only with the support/blessing of dc42 et al. (not because it would be wrong to fork the firmware, legally, but because I want LTS to remain as close as possible to the latest and greatest, so it doesn't confuse people going from one to another)
I think a LTS project would be more documentation-heavy than coding-intensive. The features in the LTS version should/could be much better defined in documentation, because they will be less prone to changing.
*not actually a robot
-
@dragonn I wasn't trying to offend anyone. The scapegoat is hypothetical -- I'm not trying to ricidule anyone. I just disagree with firmware development being driven by the type of person who comes from a coding background, has the worst printer mechanics possible, and tries to "code their way" out of a problem.
*not actually a robot
-
@bot said in 6th-order jerk-controlled motion planning:
(not because it would be wrong to fork the firmware, legally, but because I want LTS to remain as close as possible to the latest and greatest, so it doesn't confuse people going from one to another)
100% or at least have a known / viable transition path between them.
I didn’t mean to insinuate that you meant for hobbiest to go away either lol. Mostly was just taking the opportunity to jump on what you suggested and ended up writing a manifesto hahaha
EDIT:
It could also include making sure that bug fixes were added to the LTS version since they would likely be fixed initially on the Latest version. -
@dragonn said in 6th-order jerk-controlled motion planning:
@bot If we would aim for a theoretically perfect printer we wouldn't have:
- axis compensation
- auto bed leveling
- pressure advance!
- thermal runaway protection!
....................
Please don't take this personally but Just for info, I'm with @bot on this. I don't use axis compensation or auto bed levelling or mesh bed compensation. That's because my bed is inherently flat and level, all axes run true, parallel and "tram". This isn't a brag as I'm by no means alone and it really isn't difficult to achieve. It's just a matter of applying sound engineering principles to the design. It isn't much more costly either - basically make a frame that is rigid, use thick flat metal for the bed and support it correctly. There really isn't much more too it than that.
Of the other things you mention. I'd like to use pressure advance because all hot ends suffer the same problems with pressure build up but for various reasons (multiple extruders, less than perfect gcode etc) I've never been able to get it to work well. Even then, I do believe that that there is an engineering solution to the pressure problem by employing an expansion chamber or similar technique as is already used in other engineering scenarios.
I'm not too bothered about thermal runaway protection either. The reason for that is that I've sized my heater correctly so that if a fault developed and the heater was permanently on at full power, it would not reach dangerous temperature levels.
Now my printer is by no means perfect - there is always room for improvement but I don't need any of the software tools you listed. The reason those tools exist is that many printers are built to a price - a very low price. They have to be in order to sell because competition is very high. So to get the cost down to an absolute minimum and save every last cent, they cut corners and use the very cheapest components and materials. Why do you think sensor less homing was introduced? It can never be as reliable or accurate as using a sensor. But it can be made to work "well enough" and it saves the cost of a micro switch and a bit of wire, so that's a few more cents off the cost.
Also these "features" help to sell printers. Joseph Prusa is very good at this type of marketing. Faced with two similar priced printers, most people will pick the one with the most "features" (such as auto bed levelling, mesh compensation, etc etc). So the other printer which has no need for the "features" because it was designed and built properly, won't sell even though it's a better printer. It's just marketing hype.
-
@bot said in 6th-order jerk-controlled motion planning:
@dragonn I wasn't trying to offend anyone. The scapegoat is hypothetical -- I'm not trying to ricidule anyone. I just disagree with firmware development being driven by the type of person who comes from a coding background, has the worst printer mechanics possible, and tries to "code their way" out of a problem.
I agree with you - coding the way when having worst printer mechanics possible isn't the right way. But I disagree that 6th-order motion falls under this. And is not that I have a crap printer, my Hypercube Evolution is build almost like a tank. Only possible improvement would be to move to linear rails.
@deckingman I don't use axis compensation or auto bed leveling too. But this was just an example for solutions with are already implement. About thermal runaway I disagree - even if you have proper heaters power it is better to have it then not. You never know what can happen, what you heater gets a short and it power goes up? This is possible. A proper designed machine have several levels of safety:
- designed safety by proper heaters power
- software faulty detection
- pure electrical or mechanical protection like a thermal fuse
Using proper heaters doesn't mean you can leave other safety functions out of the way.
But I suggest to stop here. This is getting a big off-topic and shit-storm about ideology and others. @dc42 said it is on his list to look at. And if it will get implemented I am sure it will be an option and you all can just not using it, like axis compensation, auto bed leveling and others. No point wrangle about it.
-
https://github.com/KevinOConnor/klipper/issues/57#issuecomment-381355998
this post is a nice exploitation what does Marlin do and why:
Probably there are better approaches to this, but ensuring acceleration is 0 at the start and end of a movement, and that acceleration changes are smooth over time means applied forces do not change suddenly in magnitude or direction, and that means no vibrations and excitations of mechanical resonances of the machine.
And really don't try to tell my that you printer "professional" doesn't generate any vibrations unless you a running it slow and turn down the acl and jerk. I don't buy that, every sudden force change makes vibrations unless you printer brakes the rules of psychic -_-. When you don't have vibrations you are just not pushing you printer hard enough and they are not 'visible' but they are still there.
closed S-Curve acceleration? #57
-
Well that sums it up nicely "every sudden force change makes vibrations ".
Which is why we use linear acceleration - to avoid sudden force changes. Rather than higher derivatives of position with respect to time which are referred to as jerk, snap, jounce, crackle, pop etc (because of the behaviour that they induce into motion systems).
But this is probably the wisest comment
"But I suggest to stop here. "
Good plan.
-
@deckingman said in 6th-order jerk-controlled motion planning:
Which is why we use linear acceleration - to avoid sudden force changes. Rather than higher derivatives of position with respect to time which are referred to as jerk, snap, jounce, crackle, pop etc (because of the behaviour that they induce into motion systems).
Correct my if I am wrong, but I think I understand this right. Let's take an ideal situation - now resistance in movement. In this situation when only need to apply force when doing acceleration or declaration. In linear acceleration when the acceleration stops it's stop immediately. And this is the point when we are having an sudden force changes. In real world sure we need to apply force when moving too, but this doesn't change that in a linear acceleration motion when the acceleration phases ends they is always a sudden force change.
-
@bot said in 6th-order jerk-controlled motion planning:
Speed improvements and "vibration reduction" has thus far only been proposed for mechanical systems which are less than adequate.
Perhaps I'm misreading what you are saying. Personally, I want more speed, and I want it on my VERY GOOD mechanics. Mechanics that were custom designed for quality, and are at a price/performance point where the next few percent of mechanical perfection will double price, etc. Duet 1.21 and these mechanics produce excellent results at 100 to 120 mm/sec.
If a different motion planner gives shorter print times, with the same or improved quality, I'm all for trying it.
"vibration reduction" I agree should be in quotes, it is a very loosely defined goal. So lets just ignore it completely.
Speed with quality? I'm all in.
-
@danal and everyone else: Yes, I agree. If this (or any) different motion planning system gives improved speed on systems that are already at peak performance, I welcome that addition. I'm just worried that this is being driven (in the marlin community) by people with mostly inadequate hardware. Some of the first "academic" examples of these algorithms used obviously problematic mechanics to demonstrate the "usefulness" of the feature.
I'm not against exploring ideas, but we need to pick and choose which ideas we explore. Because the "we" is really only David at this point (though, I believe a Chris is helping a lot, too -- credit where it is due).
I would vote for not even exploring the implementation of "6th-order jerk controlled motion planning" until 100% of bugs are worked out of the the current firmware, and we can see demonstrable benefits from other firmware.
-
Yeah, I'm a lot more excited about RTOS than a different motion planner. At least for now.
At the same time, I'm using a TinyG on my big CNC because of its superior motion. It has plenty of other flaws and frustrations... the motion wins.
