-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Handling of junction speeds and jerk #9917
Comments
Ah, well so much for my first suggestion… Well, at some point we should try implementing a proper "junction deviation" and see whether it helps … and whether it's expensive to compute. We may be able to get away with using a table or some other cleverness to avoid having to do trigonometry. But before we get into that, we should definitely figure out how to de-couple the E axis from the linear axes. And, it seems XY also needs to be less bothered by Z direction changes. Maybe for Z direction changes we can relax the Z jerk limit a bit. The thing is that Z seldom has anything like the same inertia as the XY axes. You'd think Z would be more amenable to direction changes, especially when going from raising to lowering. |
I think the way we calculating jerk at the moment is already quite good. Check for all axis jerk limitation, reduce entry / exit speed if one axis is exceeding the limit. But as we have to check entry and exit speed for jerk, we need to know about the previous and (that would be new) the next segment. At the moment, the planner assumes exit speed = next entry speed is always OK. So it needs to go into the forward or reverse planner. And it has to make a decision if the junction speed has to be linked or not. Some draft ideas:
Clearly we need to do test prints to simulate some of the effects before start coding. I think I could have some fun doing that, but it's something for the middle future - we don't want to release such a big planner change without intensive tests.. |
I want to put some questions here to think about them. Maybe there are some intresting answers comming?
I'm looking forward to read your opinions! |
This seems to be a legacy of the XY gantry design of the Ultimaker that probably should not apply to Mendel X carriage / Y bed setups. And neither of those should be linked to Z. Before bed leveling came along, in 3D printing Z moves were almost always isolated Z or Z/E moves. The theory of XY gantries seems sound — you do want to limit the inertial load of the carriage block, even though XY each have their own separate inertial loads too. I think you're onto something in pointing out that separated axes should only apply load limits on a per-axis basis and not in terms of the combined motion in the XY plane. Better not to think too hard about deltas. |
Hi, I have been trying Marlin 1.1.8 (https://github.com/ruevs/Marlin_Anycubic_Kossel) and Repetier 0.92.9 (https://github.com/ruevs/repetier_anycubic_kossel) on the same delta printer. The configurations are as close as possible to each other. Max speeds and accelerations are the same. The jerk is 10 in Marlin and 20 in Repetier. As I understand that after this #8888 those values should lead to similar results. |
@ruevs please try the current |
We continue to incrementally improve Marlin's delta support, and have done loads of optimization in recent releases and in the upcoming release. If someone brings us a comprehensive overhaul that addresses delta concerns in the form of a nice PR we would be more than thrilled. |
Perhaps nobody decided to treat Deltas as "Second Class Citizens". Maybe there is another explanation. Deltas have only a small percentage of the users that Cartesian machines have. So this means first of all, it is much harder to get code developed and tested on Deltas. But it also means there are less people even interested in writing code for them. With that said, we do try hard to make the code work well on all machine types. |
Please do not take my comment the wrong way. I realize that Marlin has improved a lot in 1.1.x in terms of delta support. I only said it in response to thinkyhead's comment:
As for a pull request - if I ever have enough time to understand the code deep enough to actually improve or revamp the planner and stepper motor control logic for deltas I would certainly do so. Unfortunately this is unlikely. |
That is to say, for any indirect kinematic system Jerk and Acceleration apply to the movement of the steppers, and not to the linear movement of the tool. Thinking about this too hard may lead to headaches. |
@thinkyhead Just retested the initial test pattern of this issue with the new junction code (#10650, JUNCTION_DEVIATION_INCLUDE_E is disabled) , this is the result: I see some intresting results compared to the initial results:
Enabling JUNCTION_DEVIATION_INCLUDE_E increases the jerk speed for print moves and e-only moves slightly. |
Thanks for bringing this back on topic. I definitely want to make the junction behavior more sensible, whether using the old jerk method or junction deviation. What we really need is to decide what the ideal behavior should be first, and then make needed adjustments to get it to produce those results as closely as possible. Your earlier points can act as a starting guide. |
Just a short addition to my last post: The code change was a good first step, but some more work is necessary to make it secure and fully usable. |
@Sebastianv650 — Which "new jerk code" are you referring to in your comment? We have the sort-of-new jerk code related to the planner refactor (though it should be essentially the same limit-per-axis method) and then we have the new (but optional) |
I'm refering to |
Should Z be excepted from the Junction Deviation technique? It's certainly not like the XY axes. Likewise, with any move not involving X and/or Y… |
Only if you want to disregard 3D CNC Routing, my Z axis is the same as XY (velocity and acceleration wise) and in finishing passes on organic geometry can be moving pretty fast. |
I think we probably want to disregard any axes that have low top speeds. That would filter Z and E on typical 3D printers, while allowing you to use CNC and arcs in vertical workspace planes. |
Maybe we need a two-step approach. For example on acceleration we already use a print acceleration and a max. acceleration per axis. If one axis max. acceleration is violated by the print acceleration, it will get lowered. Same procedure can be applied on junction jerk. If the speed change on an axis from current to previous is bigger than axis max. jerk, limit the junction speed. This might also solve the problem with wrong junction speeds which I pointed out at the start of this issue? |
What is Grbl doing to mitigate the issue? Have we failed to fully duplicate their approach? |
I asked myself the same question, how GRBL sets limits for each axis, when I did my small Excel sheet for junction speed calculation. After reading their docs and code, I came to the conclusion that there is actualy no way to do this in GRBL since they use this jerk method. |
OK I have to correct what I just wrote. It's not very obvious, but I guess @thinkyhead we are realy missing an important piece of GRBL for See https://github.com/gnea/grbl/blob/master/grbl/planner.c#L446, the key is In the Marlin implementation, we use a fixed Should be easy to fix, lets see if I can patch it.. |
@Sebastianv650 there is a hint in the comments in the main fork of the grbl that it should take the minimum acceleration of the two blocks, I think you might need this to cover off both sides of this problem. |
I am completely on board with @Sebastianv650's suggestion of using the actual junction acceleration (I never really understood why we moved to a fixed value). In normal movement this means that junction deviation will factor a heavy slow However, I'm not completely convinced that it will solve this problem completely. Could it be as simple as hard setting the junction speed to 0 for E or Z only moves (with an option to not do this on Z for our CNC friends)? This method could also be applied to both Jerk and Junction Deviation solving the problem in both scenarios. Edit: If done, how would setting a 0 junction speed work (or not work) for the z-hop in fwretract? |
I read that, but this note is no longer present in the recent 1.1 GRBL code with the use of
not necessary. I got the |
I think it would really be needed in order to get this working in all cases. Take the heavy Y bed as an example, if you go from a move along Y to a 90deg corner travelling along X, then this is only going to consider the acceleration on X for this junction, not the lower deceleration needed for stopping Y. The result will be a faster junction speed than Y can sensibly handle. |
At this point I think we've got it sorted in both branches! Anything more to discuss or should we close this thread? |
I think there are still some documentation issues around. Like for instance when should you enable JUNCTION_DEVIATION_INCLUDE_E? Does this interact with linear advance? Does it make sense to enable both? |
Sounds like we will need to gain more experience to be able to answer those questions. |
@Sebastianv650 mentioned removing the JUNCTION_DEVIATION_INCLUDE_E here: #10906 I tend to agree, I think it should always be enabled and the option removed. |
I am somewhat puzzled… I used to have in my working configuration the following acceleration setting… #define DEFAULT_MAX_ACCELERATION { 3000, 3000, 100, 10000 } //tuning lrp 3000, 3000, 100, 10000 } Tested ok except E axis
/**
* Default Acceleration (change/s) change = mm/s
* Override with M204
*
* M204 P Acceleration
* M204 R Retract Acceleration
* M204 T Travel Acceleration
*/
#define DEFAULT_ACCELERATION 1500 // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION 3000 // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION 3000 // X, Y, Z acceleration for travel (non printing) moves
/**
* Default Jerk (mm/s)
* Override with M205 X Y Z E
*
* "Jerk" specifies the minimum speed change that requires acceleration.
* When changing speed and direction, if the difference is less than the
* value set here, it may happen instantaneously.
*/
#define DEFAULT_XJERK 10.0
#define DEFAULT_YJERK 10.0
#define DEFAULT_ZJERK 0.3
#define DEFAULT_EJERK 5.0 I put your formula in excel For a junction deviation = 0.02, this formula gives me Obviously, one or several of my values were out of tune… Max acceleration was too high, the sloop of speed change was ok for the retract… should I conclude that my ejerk was too small??? I am driving a 3mm abs filament thru a greg wade extruder with a couple of gears with a ratio of 37-13... I feel uneasy, did I miss something??? is that "calculated ejerk" value anything but limit or is that value actively used?? Of course I will conduct some testing and learn from my mistakes, but if you could help me make some educated guess, I would be quite thankful. |
@Sebastianv650 If so, should I limit the max acceleration to 1500 leading to an Ejerk of 8,5???? I will be using S-curve-acceleration so this should allow my printer to allow higher number for moves (not higher overall speed I now predict) |
@lrpirlet I'm not sure if I understand you problem. Is it because your initial max acceleration values don't result in the ejerk values you had before junction_deviation using the equation? That's fine, as they were not linked in any means by the "legacy" jerk / acceleration code. You can think of the junction deviation = 0.02 being the new jerk value. Given an acceleration, it results in junction jerk speeds. So you can still tune jerk and acceleration separate from each other, but linked by this value. For linear advance, this ejerk speed value is used as the upper speed limit at which pressure corrections can occur.
The length of a move and the acceleration are not linked. If you mean top speed: With 3000mm/s² you can reach about 110mm/s even when starting from 0mm/s speed after 2mm.
A typical retract speed of 40mm/s is reached after 0.25mm @ 3000mm/s² even without any jerk. So if you want to reach an ejerk of 8.5mm, even an max. e acceleration of 1500mm/s² will not limit your printing speed noticeable. |
@Sebastianv650 Using the new features, I feel like facing a completely new firmware with nearly no relation with the old one… Trying to understand the interaction between the new features is quite a challenge… I do not want to keep hanging on the "good old way of doing things" when what I see could really solve some of the problems I am facing today… Question was and is really: what is a good approach when the examples do NOT use the new features, I did try to understand from a theorycal side… I better have to jump in practical side and make mistakes, I guess… Anyway, I do appreciate your help… thanks again. |
I presume we'll have to document the updated (i.e., corrected) meaning of the jerk parameters for 1.1.9 and give recommendations for the appropriate values to use. And we should also update the configurations with reasonable values. @lrpirlet — What values are working well for you now, and what values were you using before? |
Sorry, I have no experience yet… My heated bed shorted, the FET melted shorted, the RAMPS printed board heavily smoked, the fuse did not (completely) fuse… I am waiting a new bed, a new RAMPS... Not sure to get it before the holliday so not before 3 weeks or so... I can still move the axis of the printer, I think I could extrude, but with ABS, there is no chances to get anything but a big mess… To answer your question, the max acceleration for X, Y Z seems to be compatible (I did run a dryrun print). At completion, I was able to move the hot end back to the exact same place marked before execution. So no steps lost… For E, I will limit the DEFAULT_MAX_ACCELERATION to 1500 giving an equivalent ejerk of about 8,5... I hope the extruder will bear with it… I may have to drop down to 500 if I really need an équivalent ejerk of 5... For what concerns retraction, that used to need 40*60 (2400), I was thinking to use LA and completely forget retraction… AGAIN, NO EXPERIENCE YET... but I feel uneasy with E axis |
I was starting to use junction deviation, currently set my initial parameters according to the equation:
Using my old jerk values and the default junction deviation value of 0.02 I derived my accelerations, this seemed to work fine for x, y and e, it resulted in sensible values and printer seems to be pretty happy with it. But what hapens with the Z axis? Using my old jerk of 0.4, the formula results in an acceleration of 3.3 mm/s^2. This doesn´t seem right. Is this calculated differently? The older acceleration I used in Z, 1500 mm/s^2, leads to a jerk of 8.5. I see on a post above that it was said that this values are fine if they are different becuase they are not linked to previous value. But then, what should it be set to? |
@Itox001 your z axis will most likely be just happy with the values. Prior to all this changes even if you had set the z jerk to 0.4 the real jerk in about 50% of the situations was the XY jerk value. That's because this jerk was only applied to the entry speed, but the end of the move should have ended at z jerk speed also. |
has the new JD calc's not made this one "surplus" or is it still relavant? |
this one has gone stale and discussion could continue on discord Marlin Discord server. Join link: https://discord.gg/n5NJ59y |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This is a follow-up to a topic which already was here a long time ago, but I can't find it anymore. If someone remebers it and can find the issue, you might link it here.
During the research for strange jerk behaviour today I stumbled around the suboptimal handling of junction speeds again. In one sentence: Marlins way of handling jerk and junction speeds leads to exceeded jerk in some daily situations.
The attached test gcode and the results in the table should clarify things a bit. The gcode does the following things:
I printed the following values over serial:
I did two runs, first with X and Y jerk set to 5 and E jerk set to 1mm/s, and a second one switching the values. As you can see, as soon as we are switching between extruder only moves and XY moves things start to get wired. Same should be true for Z only moves and XY moves.
The problem is that Marlin connects each segment by one single junction speed, which is not always what is needed. A simple example like the one from H13 in the table, lets assume a X Jerk of 1, an E jerk of 5. Let's do a print move along X followed by a prime move. What we want ist:
The two axis X and E are not linked, also their junction speeds shouldn't be linked. What Marlin does is in this case is:
It becomes crucial when we replace the first print move by a Z move. Z axis often have 0.x jerk values, but the final speed would be also 5mm/s due to the following retract move.
Conclusion:
Files:
Marlin Junction speeds.zip
The text was updated successfully, but these errors were encountered: