Request for variable acceleration(slower acceleration at higher speed)
-
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.
-
I can't understand at all why accelerating fast, for slow moves makes sense. Maybe that is what deckingman is thinking. What is the point of variable acceleration, if not to improve visual print/surface finish quality? If the point is to improve surface finish, I don't see how accelerating FASTER during slow moves and slower during fast moves is going to help at all. This is why I proposed the opposite – which would be useful to everyone, including those with ballscrews instead of belts for motion.
Why would it be useful to accelerate faster during slow moves, and slower during fast moves?
-
I'm thinking the term acceleration might not be the best approach here.
Goals should be outlined:
- I want the printer to move as fast as possible where possible
- I want the printer to be careful in some areas where too much speed will cause quality issues
- I want to be able to adjust the settings to best fit my printer model to achieve #1 and #2
So this might be speed and/or acceleration change. It might be as simple as a dynamic implementation of the speed factor already present based on move complexity.
Jeff
-
A further point. This is already achievable in slicers to a certain extent by setting different max speeds for different areas. maybe the right answer is get slicers to have a "max velocity" as well as max speed.
Btw Shen - that is one solid looking printer (/cnc machine!)
-
A further point. This is already achievable in slicers to a certain extent by setting different max speeds for different areas. maybe the right answer is get slicers to have a "max velocity" as well as max speed.
Well that would be nice, unlikely to happen…but nice.
