Request for variable acceleration(slower acceleration at higher speed)
-
To my understanding Jerk also applies when not starting from a dead stop or while changing direction. Jerk is how the lookahead feature is made possible. For example, when changing direction from [X axis at 50mm/s, Y axis at 50mm/s], to [X axis at 40mm/s, Y axis at 60mm/s], if the jerk value is 10mm/s for both X and Y, then the printer does not have to slow down. If for the same movement, when Jerk is only 5 for X and Y, the end of the first move has to slow down to 25mm/s for X and 25mm/s for Y, and the next move will start at 20mm/s for X and 30mm/s for Y. Keep in mind, the ratio of X speed and Y speed cannot be changed otherwise the direction of the move would change. The transition speed will be lowered just enough so that the instantaneously speed change is within the jerk value.
Yes, that was my understanding as well, perhaps not the best choice of words on my part. I knew it impacted changing direction as well which is what it appears you are saying here. It's why too high of a jerk value can really mess up your prints amongst other things. I think the key is the printer wants to try and get to that jerk value just before a change. It's not going to do a full speed move and then all of a sudden move on another axis at full speed. But yah, it's all about maintaining inertia in a controlled fashion.
Jeff
-
@(In)Sanity:
….................... But yah, it's all about maintaining inertia in a controlled fashion.
Jeff
Exactly!
-
You are right on the jerk setting theory, but what happens in practice is that there is always some "flex" in the system, be it belt flex, members bending or twisting (ever so slightly), motors flexing on their mounts or whatever. So in fact, an instantaneous speed change never actually happens. It's very fast but not truly instantaneous. It can't be if you think about it, because something would just snap.
As for the rest, I could be wrong but it's hard to accept that everything I was taught in college, and that everything I learnt about harmonics, torsional vibration, and the dynamics of mechanical systems in general, through 30 odd years in the automotive industry is also wrong.
First I'm sorry if I made you felt confronted, I tried to use the most natural wording possible. I'm not trying to prove you wrong, I just wanted to explain how my theory could work.
Yes I understand the speed change cannot not be instant. I think the jerk can be thought as a different stage of acceleration. When the steeper "instantly" starts at a certain speed, it creates a tension on the printer. The tension then produces a force to accelerate the printer head, and this accelerate is likely to be faster then the printer's acceleration after the jerk stage.
And I'm not saying what you know is wrong, maybe some of that didn't apply under my condition. For example, my printer can print at least 200mm/s on spiral mode vase, without any artifacts. That means the structure of my printer can operate at higher speed, so ringing is caused by acceleration rather than speed. Also I can print with great quality with either higher speed and lower acceleration or lower speed and higher acceleration. I want to be able to use the higher speed, but I don't want to use a really low acceleration through out the speed curve. The acceleration profile I mentioned is probably not the best but an optimized acceleration profile can defiantly increase the speed without scarfing the quality. -
The purpose of jerk is to allow small changes in direction without coming to a stop, which would be necessary if no jerk was allowed. Jerk is not used when starting or stopping.
-
The purpose of jerk is to allow small changes in direction without coming to a stop, which would be necessary if no jerk was allowed. Jerk is not used when starting or stopping.
Thanks for that, I thought the motors started at the jerk speed and then accelerated up to the run speed , back down to the jerk speed and then moved in another direction. So your saying they go from a dead stop up to the max speed based on acceleration parameters alone.
Actually this makes sense as the first start can happen many different ways and have next to no impact on the print time. It's keeping that inertia that counts.
Jeff
-
In my experience, I find the opposite of what you are proposing to be true in terms of speed and quality. That is to say, I use a high print speed but low acceleration. What this does in effect is slow down short moves to maintain quality but allow higher speeds for long moves. For example, try printing something like a 100mm x 100mm cube (height doesn't matter). Let's say we have a print speed of 100mm/sec (to keep the maths simple) and we are doing infill at 45 degrees so the moves get progressively shorter as we get nearer the corner. For the sake of argument, let's also assume that speed change is instantaneous or the acceleration is really, really high. So, when the distance across the corner is 100mm, it will take 1 second for the print head to complete the move which is fine. Now as we get closer to the corner, the distance becomes less so when that distance is say 10mm, it'll take 1/10th of a second for the print head to complete the move. That means it goes back and forth at 10 times a second which starts to get interesting. As we get even closer to the corner and the distance is say 5mm, the print head moves back and forth at 20 times a second, at 2mm the print head is moving at 50 times a second and probably shakes itself to pieces. So, now we introduce acceleration into the equation. What happens now is that the print head must speed up, maintain a set speed, then slow down. As the moves get shorter and shorter, there will come a point where the print head never reaches the set speed before it has to starts slowing down again. If the acceleration is set low, then you can reach a point where the speed of these short moves is determined purely by the acceleration settings and the maximum speed has no effect (because it never gets up to it). So, this enables you to have a very fast speed but still maintain quality because only long moves will get close to the maximum speed and short moves are speed limited by the acceleration factor.
So actually high speed/low acceleration is the way to go in my opinion.
Also, you need to be careful when thinking about spiral vase mode. The type of file we currently use for 3d printing doesn't actually support arcs. So, even in spiral vase mode, what you are actually printing is a series of very small straight segments. I don't doubt that your printer can withstand printing these simulated arcs at 200mm/ second but imagine trying to print the infill for the rectangle that I was talking about at 200mm/sec with high acceleration. Can the printer withstand the print head moving back and forth 100 times per second or more?
-
In my experience, I find the opposite of what you are proposing to be true in terms of speed and quality. That is to say, I use a high print speed but low acceleration. What this does in effect is slow down short moves to maintain quality but allow higher speeds for long moves.
Sounds like you agree with my post then on the system needs to be intelligent.
Jeff
-
Yes, I agree high speed/low acceleration does give good results, but as you mentioned for short moves the high speed is never reached, the speed is limited by acceleration. When printing some particular shapes, like vertical walls at 2mm, the speed can be dramatically different for printing at high vs low acceleration. That's why I wanted to have low acceleration at high speed, and high acceleration at low speed to take advantage of both world.
And I'm sure my printer won't survive printing at 200mm/s with high acceleration, but it should be ok if I use very low acceleration after 50mm/s. -
I actually had this idea the other day, but opposite. It seems that the higher the acceleration is, the more the ringing is visible on corners. By having NO acceleration on direction change (feedrate is equal to jerk rate), the ringing is completely gone. For this reason I thought having a LOWER acceleration at first and a higher acceleration for fast moves would allow the corner ringing to be damped before the acceleration really ramps up.
-
@bot:
I actually had this idea the other day, but opposite. It seems that the higher the acceleration is, the more the ringing is visible on corners. By having NO acceleration on direction change (feedrate is equal to jerk rate), the ringing is completely gone. For this reason I thought having a LOWER acceleration at first and a higher acceleration for fast moves would allow the corner ringing to be damped before the acceleration really ramps up.
Ahhh..slowness…it burns....
-
If we could have variable acceleration, so that the corners were treated ultra-delicately, but then acceleration ramped up (perhaps after a given "settle time") the slowness would not burn as much…
-
The look ahead code should just add variable acceleration to the move as it sees fit. The algorithm might take a while to prefect and of course should have settable parameters. I've run 160mm/s with 4000 acceleration and it does great on the straights but not so great on the corners. Keep in mind what I'm running before passing judgement.
Jeff
-
@bot:
I actually had this idea the other day, but opposite. It seems that the higher the acceleration is, the more the ringing is visible on corners. By having NO acceleration on direction change (feedrate is equal to jerk rate), the ringing is completely gone. For this reason I thought having a LOWER acceleration at first and a higher acceleration for fast moves would allow the corner ringing to be damped before the acceleration really ramps up.
It's probably because our printers have very different structures.(My printer is extremely rigid, everything is made with metal and I'm using ballscrews for all axis.) But if variable acceleration is supported, it can definitely be used either way.
-
What might work out well is if you could specify a distance range and acceleration percentage.
Range and percentage of default acceleration.
0-10 -20
11-50 0
51-999 20Jeff
-
@(In)Sanity:
The look ahead code should just add variable acceleration to the move as it sees fit. The algorithm might take a while to prefect and of course should have settable parameters. I've run 160mm/s with 4000 acceleration and it does great on the straights but not so great on the corners. Keep in mind what I'm running before passing judgement.
Jeff
An intelligent algorithm is defiantly nice to have, but it might be very hard to implement, that's why I proposed a simple two stage acceleration to start with.
-
@(In)Sanity:
The look ahead code should just add variable acceleration to the move as it sees fit. The algorithm might take a while to prefect and of course should have settable parameters. I've run 160mm/s with 4000 acceleration and it does great on the straights but not so great on the corners. Keep in mind what I'm running before passing judgement.
Jeff
An intelligent algorithm is defiantly nice to have, but it might be very hard to implement, that's why I proposed a simple two stage acceleration to start with.
It wouldn't be hard to use a simple lookup table to implement 1 - xx number of variable accelerations based on my example. It would really boil down to RAM on the boards and how many table entries can be handled. Even if it's just 5 variations that would still allow massive tweaking. I'm a software engineer btw with a strong side of EE.
Jeff
-
@(In)Sanity:
@(In)Sanity:
The look ahead code should just add variable acceleration to the move as it sees fit. The algorithm might take a while to prefect and of course should have settable parameters. I've run 160mm/s with 4000 acceleration and it does great on the straights but not so great on the corners. Keep in mind what I'm running before passing judgement.
Jeff
An intelligent algorithm is defiantly nice to have, but it might be very hard to implement, that's why I proposed a simple two stage acceleration to start with.
It wouldn't be hard to use a simple lookup table to implement 1 - xx number of variable accelerations based on my example. It would really boil down to RAM on the boards and how many table entries can be handled. Even if it's just 5 variations that would still allow massive tweaking. I'm a software engineer btw with a strong side of EE.
Jeff
I do agree with you a lookup table shouldn't be too hard. My first proposal is actually very similar to the range and percentage table you proposed, it's just value vs percentage. I probably didn't read your previous posts carefully, I thought by intelligent you meant something really fancy, everything is situational. Well I'm also a software engineer, but one hates the EE side : p
-
I do agree with you a lookup table shouldn't be too hard. My first proposal is actually very similar to the range and percentage table you proposed, it's just value vs percentage. I probably didn't read your previous posts carefully, I thought by intelligent you meant something really fancy, everything is situational. Well I'm also a software engineer, but one hates the EE side : p
We don't have the resources to do anything AI or fuzzy logic based. I think a lookup table would allow for some really good results. If the table could reach 5 entries or more I think that would be enough to make for some really nice prints with great speeds as well.
In all reality acceleration kind of does this on it's own as it ramps up over distance, I think having the ability to fine tune this would produce even better results. I like a percentage only because it allows for speedups without rework of the entire table map.
Jeff
-
I just can't believe what I'm reading here. I'd better go before I say something that I'll regret.
-
"allows for speedups without rework of the entire table map" thats a very good point.
