Request for variable acceleration(slower acceleration at higher speed)
-
@(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.
-
@(In)Sanity:
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.
Well maybe unlikely to happen, depends on your slicer and how much coding you fancy doing
I think there are sometimes calls for implementing features in firmware that are best left to the slicer to achieve. This one is on the fence because it relates to the specifics of the machine, but slice3rs already make decisions about print speed/quality based on the area of the object being sliced.
-
@(In)Sanity:
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.
Well maybe unlikely to happen, depends on your slicer and how much coding you fancy doing
I think there are sometimes calls for implementing features in firmware that are best left to the slicer to achieve. This one is on the fence because it relates to the specifics of the machine, but slice3rs already make decisions about print speed/quality based on the area of the object being sliced.
Kind of a mixed bag really, if you have hardware/firmware that makes all slicers work that much better it's a win win. In the end you really want all printers to want to run your hardware, so firmware features can really help with sales. Just look at the mobile phone industry.
-
@bot:
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?
In my case I don't get ringing when decelerating from under 60mm/s with high acceleration, but I do when decelerating from 100mm/s with high acceleration. However I don't get ringing when decelerating from 100mm/s with low acceleration. This probably caused by the resonance frequency of the printer? I'm sorry if I'm misleading, but I'm not trying to say high acceleration at low speed is the way to go. I only wanted a way to set this so we can adjust it according to our needs.
-
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!)
Thanks. Yes, I designed it to be a printer and cnc machine based on the tool head. It prints very nicely, but with the 6kg Y gantry the vibration is huge I had to put it in the basement.
-
Okay, I think we are all confusing each other. At the end of the day, we all seem to agree. Tony's conclusions seem best for now. Set your feedrate for the region as best as your slicer can. I agree with him that it would be nice if slicers could change acceleration on the fly. This would actually be very easy for it to do, though I'm not sure if acceleration change gcodes are executed in-time with the motion-planning. If not, this would be a good place to start for this: to allow the slicer to set the acceleration (and jerk values?) in real time.
-
I made small test, it looks like there is a small delay to the M201 command which changes the acceleration. I'm going to see if there is any command that would cause the M201 command to apply(as a side effect).
Update: Looks like adding a G92 command before the M201 command produces the correct behavior, at least for the simple test I made. I will run some variable acceleration test, as soon as I finish reworking my extruder/hotend assembly. -
Interesting discussion.
-
I made small test, it looks like there is a small delay to the M201 command which changes the acceleration. I'm going to see if there is any command that would cause the M201 command to apply(as a side effect).
Update: Looks like adding a G92 command before the M201 command produces the correct behavior, at least for the simple test I made. I will run some variable acceleration test, as soon as I finish reworking my extruder/hotend assembly.M201 will not affect the acceleration of moves that are already in the move queue. If you want to insert M201 in a gcode file, put a M400 command before it to wait for all previous moves to complete.
