6th-order jerk-controlled motion planning
-
@shen said in 6th-order jerk-controlled motion planning:
................> I don't know why you are so against the idea of an different different motion system. You want to see real world test results before you believe but every time this is brought up you just strongly oppose the idea, ..................
I'm not opposed to a different motion system. Like I said, show me some real evidence. However, as a mechanical engineer I do have difficulty in understanding how the implementation of jerk in the physics sense, (i.e changing the rate of change of the rate of change of velocity) can lead to better print quality. It comes from spending a great proportion of my working life combatting the effects of non linear acceleration. Variously referred to as "jerk", or in higher orders of magnitude terms such as "snap", "crackle" and "pop". These are maybe desirable characteristics for breakfast cereal but tend to have undesirable consequences in motion systems.
That aside, what I really do have a problem with is the unscientific way in which most of these "features" or firmware requests are presented. It's what I call "cat an dog logic". It goes like this. All dogs have 4 legs and fur. My cat has 4 legs and fur therefore it's a dog. So using the same logic we have a video of a glass of beer being moved smoothly, therefore we can say that if we use the same motion on my printer, it will print better. Huh? Maybe it will, but there are numerous reasons why it might not. That video of the beer glass\wine glass whatever, was made quite a while ago. How come the makers of it haven't released a new video showing that motion translates into improved print quality? I can't help being cynical - it comes with age.
-
@danal said in 6th-order jerk-controlled motion planning:
And, since tone is hard to read on Forums: FUN DEBATE, let's keep going!
Absolutely. We can agree, or agree to differ. All in a mature and adult way and hopefully neither feel aggrieved by other peoples comments nor cause others to feel so.
-
The problem that needs solving is called "vibration".
With the current motion planner, how do I determine the acceleration value for my printer?
As of now it is a kind of trial error process to set the correct speed/jerk/acceleration values that would allow to print quickly enough and without causing the printer to shake too much, without drastically slowing down the print process. just to quote Tom giving guides on calibration: "Protip: If you just can’t seem to get a print right, slow it down. Like, print at half the speed and you will usually end up with much a better print"3d printer industry is very new and motion Control has been studied in depth for more than 10 years. Trapezoidal velocity models can achieve fast motions, but tend to cause overshoots, and excite residual vibrations that require time for the machine to reach the final position with desired precision.
6th-order jerk control would facilitate the calibration and event eliminate the need to specify the jerk/acceleration on the config.g, because the firmware would do the math based on the speed settings. This is a BIG gain for me.
-
I must agree with deckingman!
I thought for a while before commenting deeper the TinyG video, but now that I have started... First of all the TinyG video shows a pendulum attached to a moving "thing". The pendulum is quite loosely connected to its support, having a lot of freedom around the connection point. Maybe 3D printers are similar, just that the distance to the connection point is much shorter, but I don't believe that is true. But CNC machines are nothing like that, with the spindle tightly connected to the system (though it is funny to think of a CNC with the spindle installed like the pendulum in the TinyG video!!! if you want to get into "hilarious mode", just think of the Z axis connected like that to a gantry also connected like that!!!).
All the years spent learning physics and math, though 18+ years ago so plenty of dust settled over most of the knowledge, clearly tell me that there is a difference, but I don't know how significant. School tried to teach me precision is important, real life engineering did the contrary, emphasizing on down to Earth compromises.
With the above said, if I look over the TinyG pendulum video, I see quite a lot of broken end-mills when the breaking starts and the pendulum tends to get ahead of the moving thing. Compensating a pendulum requires a different type of physics when compared to a CNC mill, or a even a decent 3D printer (no pendulum like solutions).
@carlosspr
We develop systems for out customers that involve quite a similar fine tuning (I won't go into details!). Although the systems are theoretically identical, we have to calibrate each of them independently using some specialized setup. Just think of a CNC with a 10kg gantry compared to one with a 20kg gantry. Both could reach the same feedrate, but the acceleration must also be correlated with the steppers, for example. It is like having a racing car and an expensive family sedan - both might reach the same top speed, but the time needed to do that is clearly different! If you spend half a day or even a whole day for finding the right parameters for your machine, that is time well spent. You can avoid that only by buying a fully built and configured machine, where someone else did the same thing for you! -
I also see similarities between this thread and another. In that particular thread, the OP put forward the "theory" that the limiting factor to print speed was friction in the nozzle and that melt rate was not a factor. This was in direct contrast to my own observations after considerable testing which showed that the limiting factor was indeed melt rate. My blog shows the real world testing and the results that I could achieve by employing multiple melt chambers feeding in to a single nozzle. https://somei3deas.wordpress.com/2017/06/22/exploration-of-print-speeds-with-a-diamond-hot-end/. However, despite the real world evidence that I had, the OP insisted that non-linear extrusion was required to overcome friction and enable him to print at much higher speeds. I lost that particular battle and so we now have non-linear extrusion as a firmware feature. Hallelujah!
. So where now is the OP? Where are his high speed prints employing the feature that his theory said would solve all his problems and would be the best thing to hit 3D printing since the beginning of time? Nothing. Zilch. Diddly squat. There has been one other user who claims there are benefits to using non-linear extrusion but the results are "subtle and don't show up in photographs". Personally, I file those types of observation under the heading of "psychological" rather than scientific - more to do with expectation theory than anything else. Since then, I've come across things like this excellent work by Michael Hackney http://www.sublimelayers.com/2017/12/musing-on-under-extrusion-prepare-to.html which shows, in scientific analytical way, that printed parts are actually very tolerant to quite a high levels of under extrusion, which further reinforces my personal belief on just how useful or not that non-linear extrusion is in actual real world printing.However, there is no harm done as I don't have to use that feature. What concerns me now is that a new motion system may not be something that I could choose to use or not. The reason that bothers me is that I have recently had reason to revert to a previous version of firmware because of a second order effect of pressure advance with the latest firmware. It seems that the latest version of firmware is less tolerant of imperfect gcode than earlier versions. This causes havoc when printing arcs whilst employing pressure advance. So now I have a choice of either trying to find a slicer that generates more perfect gcode, or using an earlier version of firmware. Personally I think that firmware should work independently of slicers and be tolerant to their various vagaries and imperfections, but that's another matter. But it does raise concerns in my mind about what other second order effects might creep in with a new motion system. Will we all have to start using one particular slicer for example?
-
@deckingman said in 6th-order jerk-controlled motion planning:
There has been one other user who claims there are benefits to using non-linear extrusion but the results are "subtle and don't show up in photographs". Personally, I file those types of observation under the heading of "psychological" rather than scientific - more to do with expectation theory than anything else.
That will be me you are referring to. Sorry that my satisfaction with the non-linear extrusion feature doesn't fit in with your view of the world. I find your attitude insulting in the extreme. Grow up man, accept that other people with other equipment can achieve results that are at odds with your own narrow views.
-
I'm truly sorry that my personal opinion has upset you. I was very careful not to name anyone, in fact I couldn't even remember who it was. I was merely pointing out that on the one hand, there is hard evidence in support of the fact that printed parts are very tolerant to under extrusion, but on the other hand there is only anecdotal evidence to say otherwise. So for me personally, I tend to believe the hard evidence and my own test results. However, if you read my blog https://somei3deas.wordpress.com/2018/01/15/an-attempt-to-investigate-pressure-in-the-extrusion-system-with-a-diamond-hot-end/ you'll see that I go to great lengths to explain that my findings were based on my own particular printer and that things such as nozzle size could play an important role. I stated there and will repeat it it here that other users may find different results and if they need to use a positive extrusion multiplier, then non-linear extrusion might work for them. To date, no one has yet come back to me to say that it works for them so I'm still of the opinion that there is no evidence to support it's use. Sorry if that upsets you but that's the way I personally see it.
-
@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. -
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.
