Request for variable acceleration(slower acceleration at higher speed)
-
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.
-
I'm assuming this firmware is fast enough that the M400 wouldn't even be noticed , i.e. the queue will empty and fill again before the motors even have a chance to slow ?
Jeff
-
No, the motors will come to a standstill because the move scheduler won't know that a new move is about to arrive.
-
No, the motors will come to a standstill because the move scheduler won't know that a new move is about to arrive. However, I've thought about it some more, and I don't believe the M400 is necessary after all. The situation in which you get a delay is if you are printing from SD card and you send the M201 command from another channel e.g. the web interface.
-
No, the motors will come to a standstill because the move scheduler won't know that a new move is about to arrive. However, I've thought about it some more, and I don't believe the M400 is necessary after all. The situation in which you get a delay is if you are printing from SD card and you send the M201 command from another channel e.g. the web interface.
Makes sense, so more or less the speed change from the SD card just falls inline with the normal queue and nothing else is needed. Got it.
Jeff
-
I was wondering, that, too. So if it's inline with the gcode, it will be picked up just like any other move gcode and put in the queue?
Also, would it be easy to implement a "dwell" term to the jerk rate? As in, a period of time in ms that would be waited after hitting the jerk rate, before acceleration begins? This might make it easy to tune the ringing out of corners while maintaining a high acceleration.
-
@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?
That was exactly my point - well one of them.
Back to basic physics. The first derivative of position with respect to time is velocity. The second derivative is acceleration. So variable acceleration would be the third derivative - i.e the rate of change of acceleration. Now go look up the definition of the third term of position - I'll save you the time, it's variously known as jerk, jolt, lurch, or surge. This is what you want to introduce?
-
Ian, yes that would appear to be what is being asked for. but I am still not sure its required to maintain the desired velocity curve.
The velocity is actually the variable we are trying to control.
-
Ian, yes that would appear to be what is being asked for. but I am still not sure its required to maintain the desired velocity curve.
The velocity is actually the variable we are trying to control.
That is my point. The rate of change of velocity is acceleration and it should be linear for smooth motion. The moment you start varying it, i.e putting a curve on to it, you introduce jerk (in the physics sense). It is unavoidable.
A couple of simple illustrations. When you are driving your car and you break to a standstill, it may sop with jerk. Learner drivers do this all the time. Some of us adapt and just before the car actually stops we ease off the brake, very slightly (my wife doesn't and all the passengers nod their heads). You probably do it subconsciously but next time you are out driving, think about how you come to a stop. What happens is that as the breaks heat up, they become more efficient and the rate of deceleration actually increases for the same pedal pressure, so you come to stop with jerk. When you ease off the brake pedal ever so slightly, you maintain a linear deceleration and come to a smooth stop. It is very important to know that you are NOT slowing the rate of deceleration when you do this, otherwise you would never actually come to a stop at all, you are merely maintaining linear deceleration.
We see it in engineering all the time. Camshaft profiles are designed to give linear acceleration to the valve stem. When they don't, valves bounce off their seats instead closing smoothly. In extreme circumstances the torsional vibration will strip the teeth of the belts or pulleys and wreck the whole valve train. Have you ever driven a car with severe turbo lag? It's awful and another example of non-linear acceleration. Designers and engineers spend hours and hours designing throttle linkages so that you get nice progressive, linear response to the movement of the pedal. If they didn't you'd find either the first 1/16 of the pedal movement gave you half the acceleration and the remaining 15/16th gave you the other half (or vica versa) which would make the car un-driveable.
So having spent half a lifetime dealing with various manifestations of non-linear acceleration and deceleration, you can maybe begin to understand why I think it a bad idea.
-
If my driving had a jerk setting it would be around 150
It best start fast and stop sudden, I rarely have passengers. -
@(In)Sanity:
If my driving had a jerk setting it would be around 150
It best start fast and stop sudden, I rarely have passengers.Yes, I've come across quite a few drivers with high jerk settings.
-
This is a great explanation. I used to drive for business a lot, with passengers who were important to the company, so I got good at "limousine stopping" as they called it. You couldn't even tell precisely when we stopped, it was so smooth.
-
So now we need hot end assemblies that float in a magnetic field and perfectly brake when slowing down via precisely controlled magnetic force. Lol, a magnetic shock absorber if you would.
Jeff
-
I want that very much: linear stepper motors.
http://www.intellidrives.com/AppNotes_Linear_actuators_LinearSepperMotorsHowLinearStepperWorks.htm
-
Also guys, don't forget that the amount of extruded filament has to follow what the axes movements are doing. Even if you could persuade the head to move in the manner that has been suggested, do you seriously think that the filament would do likewise? All you'd get are pressure pulses adding even more unpredictability into the system.
-
Also guys, don't forget that the amount of extruded filament has to follow what the axes movements are doing. Even if you could persuade the head to move in the manner that has been suggested, do you seriously think that the filament would do likewise? All you'd get are pressure pulses adding even more unpredictability into the system.
Your no fun
-
Interesting debate. Here's my 2p.
When the nozzle turns into a corner it's accelerating independently in X and Y directions according to the respective stepper motors.
Steeper corners require BOTH more braking (deceleration = slowing / stopping of the current direction of movement) and acceleration (starting off in a new direction of movement).
My hunch is that ringing type problems are not created by the acceleration into the new direction, but the deceleration from the old one (if you'll forgive the distinction).
According to this way of looking at things, the job of a "look ahead" system would be to calculate the amount of the present extruder velocity that must be eliminated by the exit of the curve, then to pre-emptively slow the extruder before the curve actually begins (so to speak).
Thus gentle curves will not provoke much in the way of pre-emptive slowing (of the current direction of movement, whatever combination of X and Y that may be), but right angle bends an awful lot.
Is it possible from the gcode with a suitably modest amount of computation to estimate how much deceleration of the current velocity will be demanded by upcoming moves?
