Request for variable acceleration(slower acceleration at higher speed)
-
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.
-
I just can't believe what I'm reading here. I'd better go before I say something that I'll regret.
There are all kinds of printers out there. I know you have a corexy printer, this might look completely useless to you but it might be useful to someone with a completely different printer.
-
I just can't believe what I'm reading here. I'd better go before I say something that I'll regret.
I'm assuming your leaning towards the Why bother as acceleration already does all of this ?
Please elaborate as nobody can understand a potential mistake or poor sense of direction if those with the answers don't share.
Jeff
-
In essence what you are looking to achieve is the ability to fit the (currently flat line) acceleration to a non flat line (and possibly a series of lines). The reason for doing this is to have an effect on the velocity though so what would be a good experiment to do to confirm this is a worth while change is to edit some g-code of a simple test print and show the differences. (sorry Ian, I get your point but I am interested to see if there is an observable print quality difference with acceleration changes through test extrusion)
What can be seen as "ringing" on corners is its the manifestation of the nozzle not smoothly moving around that corner, or smoothly extruding around that corner. This can be caused by a springiness within the moving parts within the printer causing oscilation of the hotend, it can be caused by the hotend slowing down and the flow rate in the nozzle not adjusting smoothly (nozzle too hot - ooze, underextrusion, ooze etc) and there are probably other reasons I have not though of.
My understanding (Ian feel free to jump in) is that in an ideal situation the speed (scalar) of the nozzle through the corner will remain constant, the velocity(vector) is obviously going to change because of the direction change. With a smooth speed the extrusion can remain constant (excepting anything clever the slicer might be doing to prevent over packing of corners), that removes one of the variables that could be contribution to poor print quality on corners (changing extrusion rates)
If the aim the the acceleration values is to keep the change of the resultant vector of the axis at a constant speed, can this be achieved with a constant acceleration or not? I an not up for hauling calculus from the depths of my memory right now but would be interested if someone more knowledgeable can chip in.
