Feedrate, Acceleration, and Max Speed.

Hi all,

Is the set feedrate specified in the G1 code the maximum speed the deposition nozzle will reach along a vector, or do any of the firmware packages purposly exceed this value in order for the average feed rate to equal the specified feed rate up until it hits the maximum speeds set in the config file?

Thanks!

Edited 3 time(s). Last edit at 09/09/2017 11:25AM by WesBrooks.

I'm working on a python based model of the process in order to get a better understanding of it and a break down of where time is spent in the build process.

My understanding is the g-code speed, entered in the slicer, is the maximum speed you want the head to move. The firmware will limit the speed to the values set in the firmware. The firmware has move look-ahead function, which it uses to accelerate and decelerate before and after a change in direction. The print head can't stop in one direction and achieve instantanious speed in a different direction (physics). On short print vectors the print head might not reach the speed in the g-code. On long print vectors, the print head will not exceed either the g-code speed or the firmware speed, which ever is slower.

Thanks, that's a second on my original interpretation of what goes on. That said, since it's the jerk and acceleration that cause machine issues I can't see my alternative causing issues. The max speed in the config file should protect the system from running at speeds the stepper drive system can't sustain.

I'm interested to see a brake down of total time spent accelerating, at the feed rate, etc. With the way jerk is applied I'm also wondering if radius on part corners could actually improve build rates, likewise a contour fill strategy rather than raster hatch.

I'm going to have a stab at the estimator and see how close get before seeing if the raw source code is readable and translate that back to English / sketches. Just to be clear, when I say see if it's readable that's coming from the point of view of someone who's not a seasoned c programmer. Too much bit shifting or global variables and things become about as readable as a regular expression to me! ;-)

Edited 2 time(s). Last edit at 09/10/2017 01:41AM by WesBrooks.

I use an Atmega 2560 and Ramps 1.4 running Marlin firmware. The following statements are based on my experience with this hardware (maybe the most common(?)).

The g-code doesn't contain information regarding acceleration or jerk (time spent in acceleration/deceleration and/or distance). That information is only available within the firmware. You will need to know your hardware and firmware really well. For instance, both, the amount of time, and the distance, it takes your machine to arrive at the desired speed specified in the g-code (dissect the firmware (?)) need to be factored in for each axis.

Regarding the way jerk is applied, any angle from one print vector to another print vector where an obtuse angle is formed should help. A radius is composed of many small segment print vectors and while jerk shouldn't have an impact, acceleration/deceleration of all the small segments probably will. Depending on the size of the radius this can have a dramatic impact on print time. Also the circumference of the radius will need to be calculated to determine the amount of time spent in each radius for each perimeter.

There is always a trade-off between quality and speed.

Good point, my experience comes from the Duet 0.6 onwards and I only recently came across a tuning guide for one of the other boards where the settings were locked at compile stage of the firmware. You certainly have to be far more determined to optimise your system if each installation is a recompile and firmware flash rather than text file edit over a web interface and restart!

My settings at the moment are:

Jerk: 15mm/s
Acceleration: 800mm/s
Perimeter: 60mm/s
Slow down on external perimeter: 0.7

These have not been tested in a build yet and are likely to cause artefacts on the surface of the model as the machine does shake a bit at those settings.

Smallest vector on which the machine could reach the perimeter speed and stop again based on those numbers would be 4.6mm on the perimeter speed or 2.2mm on the external perimeter. It would most likely ring a bit and the machine would shake, most probably unacceptably. This is just looking at the numbers.

So looking at the jerk speed the simplest assumed application would be it is only used where the change in velocity in a specific axis is less than the jerk speed and the speed change is applied instantaneously and lag of the stepper in the speed change isn't great enough to pull it out of step. so the question is if heading along a vector at 60mm/s how much of an angle is that? To simplify things I would assume the nozzle is travelling along at 60mm/s purely along the x-axis and suddenly at a vertex applies a 15mm/s speed in the y-axis. To keep the 60mm/s speed the x-axis would only need to drop to 58.1mm/s and the 15mm/s y component would give a vector travel speed (terminology may be a bit wonky here, but then again I'm in good company with whoever called jerk jerk!) of 60mm/sec. This would be an angle change of 14 degrees (edit: 4.6mm radius achievable), so the axis would need to be slowed down and accelerated for a pure 90 degree corner, but putting a radius on that so that the difference in angle between the vectors didn't exceed 14 degrees would result in a higher average speed. However, id the system can reach 60mm/s inside 2.3mm then I guess the time saving isn't great.

The second level of complexity is that the jerk effectively skips the first bit of acceleration. This would fit with the old description of the jerk being minimum speed, although appreciate that jerk is not now the minimum speed - at least on the duet systems. This interpretation would reduce the size of the vector that the system assumes it can accelerate up to the desired feed rate and back down again as there is an initial speed this reduces the minimum vector length where the feed rate is achieved to: 4.2 for the 60mm/s and 1.9mm/s for the 0.7 speed external perimeter. If this is how it is applied I can see the system skipping the speed changes between the jerk speed and zero and zero to the jerk speed when the angle between the two vectors dictates that the application of jerk alone with no other acceleration before or after the jerk can't force the required vector angle change.

Given the small differences in the vector lengths It's likely that I won't be able to resolve which way the system is behaving just based on comparing build time estimations from the M37 command to that of my software estimate - and so will struggle to verify my model. I will try though! The lack of radii on some printed parts of my system bug me from a stress raiser point of view, but if they actually sped up the build process that would be more incentive for people to consider them in the final stages of reprap like component design.

Edited 3 time(s). Last edit at 09/11/2017 03:57AM by WesBrooks.

In relation to my original question you can see that where ever there is a vector longer than 4.6mm there is an opportunity to increase the maximum feedrate beyond the specified perimeter speed in order to raise the average traverse speed over the contour to the specified feed rate, so long as the limits of any of the axis are not exceeded in the move. This should not happen if the firmware/config file is set up well. As far as part qualities are concerned it's not really the peak speed that causes issues, it's the accelerations and jerks that shake the system about.

Being a real devils advocate in an ideal world should we be forgetting about feed rates and just changing accelerations and jerk on the fly instead? After all what we are really trying to achieve in english is "Please print this contour in a not very shakey way so it looks good!", or " I don't really care if the machine shakes a little for this sequence of vectors because it's hatching or internal core fill!"

Not as easy to explain to a newbie, but then again that shouldn't really be a driver of the development of these systems. There are ways to hide that complexity in the user interfaces.

Edit: Forget about all feed rates apart from the maximum stepper speed which is limited by factors such as stepper drive voltage. If the 12mm³/s limit of the E3D v6 nozzle mentioned in my machine set up guide is an accurate value then it is likely this would limit the speed of extruding traverse before the motion axis hit 150mm/s.

Edited 3 time(s). Last edit at 09/11/2017 05:08AM by WesBrooks.

150mm/s is often cited as a recommended maximum feed rate (9000mm/min) for some systems. Mostly reserved for non extrusion moves. Based on my current settings start-peak-stop is achievable in vectors of 27.8mm and longer. The maximum angle change would be much smaller than 14° were this speed could be maintained - more like 5.7°. Still, significant scope for speed up on gentle contours and hatching.

Edit: More fag-packet maths suggests the minimum radius would be nearly 80mm with the 14mm segments. Only really scope for speeding up straight sections of contours or hatching.

Edited 1 time(s). Last edit at 09/11/2017 03:36AM by WesBrooks.

If you want to perfectly trace the desired toolpath the machine must come to a full stop at every corner; and if you want to maintain maximum speed the machine will be unable to accurately follow the toolpath.

Proper motion controllers solve this by allowing you to choose how much to "round" off the toolpath. You specify an allowable toolpath deviation and the controller will run as smoothly and as quickly as possible under that constraint.

[wiki.linuxcnc.org]

Junction deviation was designed to avoid stepper stalls, and does not really achieve the same purpose as properly calculated corner rounding.

As you have noted, replacing corners with fillets should improve print times; but can have unpredictable effects on junction deviation depending on how finely the curves are segmented. A very small radius fillet that has been faceted finely enough to keep each segment angle under the deceleration threshold will make the printer corner at maximum speed.

There is a good explanation of junction deviation here, but implementations vary across firmwares: [forums.reprap.org]


In practice you often want printer velocity to be as constant as possible because the extruder responds very slowly. Even if you are applying fast and fine control to the filament being pushed into the melt-zone, the melted plastic will respond slowly and come out at an averaged rate. If the printer is wildly varying its speed it will be placing a lot of plastic in slow areas, and not very much plastic in fast areas.

Pressure advance can probably overcome this effect at low accelerations, but at some point the control bandwidth of melted plastic is just too far below that of the positioning system.

Regarding the compile/reflash process, it's not required. I just edit the EEPROM value I want to change and restart the processor or reload the values from EEPROM.

Actually, the steps/mm, acceleration, jerk as well as other values can be changed in the g-code. After the printer behavior is characterized, the changes can be made on a print by print basis, if needed/wanted.

Quote
jmrobert48
Actually, the steps/mm, acceleration, jerk as well as other values can be changed in the g-code. After the printer behaviour is characterized, the changes can be made on a print by print basis, if needed/wanted.

I was thinking of trying to run the M commands that specify the jerk and accelerations in the build file to see if they were changed outside of the part where the system I use reads in the config values. It would be interesting to see if these were read by the look-ahead bit of the firmware and don't introduce a delay in a sequence of vectors. Regarding the EEPROM then in practice not much more effort than adjusting the configuration, as a restart of the system is required to read those values in too.

Quote
691175002
In practice you often want printer velocity to be as constant as possible because the extruder responds very slowly. Even if you are applying fast and fine control to the filament being pushed into the melt-zone, the melted plastic will respond slowly and come out at an averaged rate. If the printer is wildly varying its speed it will be placing a lot of plastic in slow areas, and not very much plastic in fast areas.

Pressure advance can probably overcome this effect at low accelerations, but at some point the control bandwidth of melted plastic is just too far below that of the positioning system.

That is enlightening, thanks. I hadn't really considered the squishy nature of the polymer melt. I had begun to think about constant rate issues that are seen on industrial extruders but not the melt flow/elastic behaviour. Cheers for the link too, I'll look through that. This would suggest making up for time within a contour would not get great results. There may still be hope for other scan strategies than raster, but I'll get a better idea once the build time breakdown code is working.

Edited 1 time(s). Last edit at 09/12/2017 02:26AM by WesBrooks.