Bravo printbus, I'm loving this thread! I will definitely run some of these tests as soon as I am able. Keep up the good work.
Bravo printbus, I'm loving this thread! I will definitely run some of these tests as soon as I am able. Keep up the good work.
Quote:
Originally Posted by TopJimmyCooks
Thanks. I'm just another one of us trying to better understand their printer. I had no idea I would be digging into the details like this when I started the thread. I guess I was hoping for someone already in the know to jump in and explain the Marlin move planning - the code seems overly esoteric, and I've found little related information on the web that seems both helpful and trustworthy. As I've said in multiple threads, the more we share, the better off we all are in being able to selectively pick the information we feel is important. In the end, there may be some conclusions here that are debatable, but it'll at least have been an interesting read in getting there. This is another thread where I frequently go back and edit prior posts. Those just reading new posts as they appear may want to skim through the thread from the beginning at some point.Quote:
Originally Posted by misquamacus
EDIT: esoteric: per google, "intended for or likely to be understood by only a small number of people with a specialized knowledge or interest". Yeah, that fits.
TESTING EXTRUDER MOTOR DRIVE WITH GCODE
Silly me. All I wanted to do here was provide a means for accelerating and decelerating the extruder motor so I could listen for noise to tune away with the stepper driver adjustment. That worked with X, Y and Z, so why not here? As it turned out, this simple endeavor started to expose some of the intricacies of Marlin move planning.
!! BE SURE TO REMOVE THE FILAMENT FROM YOUR EXTRUDER BEFORE RUNNING ANY OF THIS GCODE !!
We see a few new things in this gcode. To prevent bad things from happening, Marlin normally won't allow the extruder motor to be driven unless the hot end is near printing temperature. The M302 gcode command allows us to over-ride that, and drive the extruder motor with the hot end cold. Even coming up with the M302 to use here was interesting. On first use of a new gcode, I typically search within marlin_main.cpp for the Mxxx or Gxxx label to make sure our Marlin supports that code. When I did that with M302, it suggested M302 is NOT supported. More web search assured me it SHOULD be in the Marlin build, so I tried it, and it worked! Huh? Well, it turns out that the person who added the M302 code didn't include the M302 label in the comments for it. Freeware. Anyway...Code:; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302 ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G0 F900 ; set feed rate to be used in mm per minute
G0 E25 ; spin motor for what would be 25mm feed
G0 E-25
G0 E25
G0 E-25
G0 E25
G0 E-25
Then we see the M204 T gcode used to manipulate the acceleration and deceleration of the extruder motor. The M201 command for over riding the DEFAULT_MAX_ACCELERATION values doesn't work here. Why? The Marlin move planning is smart enough to know we're not extruding while also moving the carriage, so this is considered by Marlin to be a "filament only" move. Retraction and the recovery from a retraction would be the typical filament only moves, and someone decided a different acceleration setting should be possible for them. Hence the DEFAULT_RETRACT_ACCELERATION constant, and the separate gcode for manipulating it. The value of 10 mm/sec per second here is purposely slow in order to listen for vibrations and resonation as the motor ramps up and down. Note the 'T' included with the M204 gcode. That implies the retraction acceleration.
G0 F900 sets the feed rate to be used for the extruder. I'm currently running my printer with the E term in DEFAULT_MAX_FEEDRATE set to 15 mm/sec, or the 900 mm/minute shown in the gcode. Like with the Z motors, if you want to test at a rate faster than what you have in your firmware for DEFAULT_MAX_FEEDRATE, you need to load new firmware or set Vmax E higher with the LCD. The remaining G0 commands repeat through what would be filament feed and very excessive retractions.
Running the gcode, the extruder did make noise that could be tuned away with the trimpot on the extruder stepper driver. I'll have to test this setting with filament installed later, but I was able to put a lot of hand resistance on the large extruder gear without noticing any motor skipping. I have a Kysan motor installed here, but I later measured the stepper driver adjusted to a lowly 0.09V.
Let's get this more interesting and take out the minus signs on the retraction values -
If you run this right after running the prior gcode, the extruder motor will spin for just one movement and then quit. I apologize for starting to turn this thread into a gcode tutorial too, but in the prior test Marlin was defaulting to assume absolute positioning. We were effectively telling Marlin to move between positions E=25mm and E=-25mm on the filament, and we left it at E=-25mm. Along comes this gcode, and we first spin the extruder to get back to E=+25mm. For the rest of the G0 E25 gcodes, we're already at E=+25mm, so Marlin concludes no further movement is necessary. This we can manipulate with a G91 gcode to enable relative positioning, and each move will be made with respect to the current location -Code:; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302 ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G0 F900 ; set feed rate to be used in mm per minute
G0 E25 ; spin motor for what would be 25mm feed
G0 E25
G0 E25
G0 E25
G0 E25
G0 E25
Now what happens? You get the acceleration and deceleration of a 25mm feed, followed by one really long one. Huh? This is where the smarts of the move planner are getting involved. It knows that the subsequent commands continue a movement in the same direction and at the same rate, so no deceleration and acceleration is required between them. I'm not going to try to address why there still is deceleration and acceleration between the first G0 E25 and the second one. I just assume it's a nuance of the planning algorithm.Code:; gcode for testing the extruder drive motor
; REMOVE FILAMENT FROM THE EXTRUDER BEFORE EXECUTING.
M302 ; allow cold extrusion
M204 T10 ; this will override DEFAULT_RETRACT_ACCELERATION
G91 ; relative positioning
G0 F900 ; set feed rate to be used in mm per minute
G0 E25 ; spin motor for what would be 25mm feed
G0 E25
G0 E25
G0 E25
G0 E25
G0 E25
Note that once the printer is in relative positioning from the G91 command, it will stay that way until reset or instructed to go to absolute positioning with a G90. For example, if you now go attempt to run one of the X or Y tests, you won't get far since the routine will try to move +180, go another +180, etc. and the printer won't let you move outside the set print area. The lesson here is that it doesn't hurt to preface all of your custom gcode files with the setup commands pertinent for it in order to ensure the routine does what you expect it to. Metric dimensions, absolute vs relative positioning, etc.
HOMEWORK AND INDEPENDENT STUDY
Add a bit of dwell delay between the move commands by inserting something like a G4 P10 between them. Now the planner knows moves should stop and wait between each segment, so each segment accelerates and decelerates.
Experiment with different values for the retraction acceleration term. Seems like this can be set pretty high, at least with the dry extrusions we're doing here. Settle on a value and test it on some filament. Until educated otherwise, my plan is to set DEFAULT_RETRACT_ACCELERATION and the E term in DEFAULT_MAX_ACCELERATION to the same value. While they can be set to different values, they don't have to be.
Play around with slower E feedrates if you want. You could even insert commands to change the feed rate between the G0 commands and have some of the segments go fast, and others go slow.
Think about how this kind of gcode should be helpful in initial testing of newly printed gears for a Wade's extruder. Those teeth on the small gear don't always firm up properly, do they?
REFERENCES
Google is your friend as far as learning about gcodes. In addition to the reprap wiki, searching on a specific gcode command will often bring up links to forums where people have ran into questions or issues in using those codes. I usually find those links to be more helpful than the brief description provided in the reprap wiki.
LET'S RECAP
- We've identified the key settings in configuration.h and configuration_adv.h pertinent to motion moves. Where applicable, we've shown the correlation between these settings, the settings on the LCD, and gcode commands available to manipulate them.
- We've identified a means to increase the speed of homing for the Z axis
- We've covered how the values in DEFAULT_STEPS_PER_UNIT are calculated for the X, Y, and Z axes
- Using the reprap wiki guideline of 16 kHz as a step rate limit, we've defined theoretically "achievable" values for DEFAULT_MAX_FEEDRATE of {200,200,5,17}. The "run hot" type stepper motors on at least my printer limit my Z feed rate to about 2.
- Using a more conservative 10 kHz step rate based on firmware insight, we've suggested 100-120 mm/sec as a top end on X Y print speeds to use in our slicer, reserving the theoretically achievable feed rates for use in travel moves.
- We've explored some gcode that allows us to see real-world effects of settings like DEFAULT_MAX_FEEDRATE, DEFAULT_MAX_ACCELERATION, and DEFAULT_RETRACT_ACCELERATION on our hardware. In addition to validating tentative settings, the gcode routines are handy in looking for vibrations or resonations, and even adjusting the current limit setting on the stepper motor driver boards.
We've also discussed how multiple settings can affect the same thing. There is an order of precedence between them -
- The settings loaded in the printer set the high/fast limit on feed rates. There are the DEFAULT_MAX_FEEDRATE settings in a firmware build or stored in the printer's EEPROM. Gcodes sent to the printer can only command settings lower/slower than the printer settings.
- Adjusting feed rate from the LCD has no such constraint. The LCD can be used to change a feed rate setting higher/faster than the installed firmware build or the current setting in EEPROM.
- For settings other than feed rates, gcode commands can be used to adjust settings both lower/slower and higher/faster than the respective DEFAULT value in the firmware build or EEPROM setting
- HOMING_FEEDRATE can only set speeds lower/slower than DEFAULT_MAX_FEEDRATE
- MANUAL_FEEDRATE for use with LCD commanded moves can only set speeds lower/slower than DEFAULT_MAX_FEEDRATE
- DEFAULT_MAX_ACCELERATION applies to to X, Y, Z. The E term applies only to extrusions while moving. DEFAULT_RETRACT_ACCELERATION is applied to the extruder for retraction and replenish filament-only moves.
- And here's the new point for this post. Acceleration factors for X, Y, Z and E moving extrusions are limited to the lower term in either DEFAULT_MAX_ACCELERATION or DEFAULT_ACCELERATION. DEFAULT_MAX_ACCELERATION simply allows you to manipulate each axis individually. If DEFAULT_MAX_ACCELERATION is set high enough, you can manipulate them all lower through a single setting or gcode command using DEFAULT_ACCELERATION. What happens in a retraction and subsequent recovery is not affected by this, since they are controlled by DEFAULT_RETRACT_ACCELERATION
The jerk settings are the motion settings we haven't addressed yet. And then we need to see how the feed rate, acceleration, and jerk settings all tie together.
HOMEWORK AND INDIVIDUAL STUDY
Gcode M204 Sx is the command for setting DEFAULT_ACCELERATION, where x is the acceleration value you want in mm/sec per second. Go back to some of the gcode exercises where the M201 command was used to manipulate acceleration factors for individual axes. Add an adjacent row for the M204 Sx command, observing which takes precedence over the other based on the value given to each.
UNDERSTANDING JERK SETTINGS
There's a couple of ways to look at what the jerk settings do. From a dead stop, the jerk setting defines the first move rate Marlin will factor into the move planning, and it will accelerate from that rate as required. When already moving and about to make a change in speed or direction, the jerk setting defines the instantaneous step Marlin can make in the feed rate.
Visualize this on a motor vehicle. For the smoothest ride, you put the vehicle in gear and slowly let out the clutch and give it some gas to gradually accelerate from a stop. To corner nice and smooth, you slow down to a near stop to complete the turn and then gradually accelerate back up to the speed limit. All this takes time. If you're in a hurry, you can drop the vehicle into gear without using the clutch and the vehicle will lurch forward. To save more time, you can screech around the corners almost to the point the vehicle goes out of control. Completing the turn, you might need to adjust the steering for a while to get the vehicle moving in a straight line again. In a similar way, the Marlin jerk settings allow you to set where in the range you want the printer to run - slow and conservative, or fast and bouncy.
Let's fire up some gcode on the printer -
After homing the X axis, this gcode will just move the carriage back and forth on the X-axis. Gcodes are provided for manipulating feed rate, acceleration, and jerk settings pertinent to the X-axis. As provided, the M205 gcode command sets the XY jerk setting to 0. Acceleration has been set low so that we can observe any jerkiness at the movement end points (otherwise fast acceleration from the end points might mask it). This is the slow and conservative extreme. Run this, perhaps with a finger resting on the xcarriage to feel for any jerk or snap at the movement extremes. It's nice and smooth. Focus on the movements in the middle, not the first and last ones where Marlin is factoring coming from/to a dead stop. It doesn't matter in this test, but that's an important consideration for later when we raise the jerk setting from zero.Code:; gcode for demonstrating XY jerk setting in X axis movements
;
G21 ; metric dimensioning
G90 ; absolute positioning
;
M201 X500 ; restore safe & fast acceleration value for homing; mm/sec per second unit
G28 X ; Home X to initialize the zero reference point
;
G0 F6000 ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 X100 ; override DEFAULT_MAX_ACCELERATION for X with this; mm/sec per second unit
M205 X0 ; override DEFAULT_XYJERK for XY with this; mm/sec unit
G0 X180
G0 X20
G0 X180
G0 X20
G0 X180
G0 X20
G0 X180
G0 X20
Now rerun the gcode, increasing the value on the M205 command each time. At about M205 X30, you might start to feel a bit of a bump or tick as the carriage snaps to the opposite direction. Get real aggressive and try M205 X100 to observe how that bump or tick gets very distinct. If you haven't tried the value, load M205 X20. 20 mm/sec is the MakerFarm default setting for XY jerk. In the non-scientific testing we're doing here, that seems pretty appropriate. Those that have the ability to measure vibration with their phone are certainly welcome to do so in comparing the effects of settings. Share the results.
Now let's do the same test on the Y axis instead of X -
This starts at an XY jerk setting of 0 again. This time rest your finger on the Y-bed as it moves. The bounce at the endpoints can get pretty pronounced when you get to high value settings. Note that X and Y share the same jerk setting. You use the M205 Xx command to set it. There is no separate command for Y.Code:; gcode for demonstrating XY jerk setting in the Y axis
;
G21 ; metric dimensioning
G90 ; absolute positioning
;
M201 Y500 ; restore safe & fast acceleration value for homing; mm/sec per second unit
G28 Y ; Home Y to initialize the zero reference point
;
G0 F6000 ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 Y100 ; override DEFAULT_MAX_ACCELERATION for Y with this; mm/sec per second unit
M205 X0 ; override DEFAULT_XYJERK for XY with this; mm/sec unit
G0 Y180
G0 Y20
G0 Y180
G0 Y20
G0 Y180
G0 Y20
G0 Y180
G0 Y20
Now we'll get more interesting and experiment with the extruder -
!! WARNING: REMOVE THE FILAMENT FROM THE EXTRUDER BEFORE RUNNING THIS GCODE !!
Like our earlier testing with the extruder, the gcode will rotate the extruder motor back and forth the equivalent of 20mm filament feed movements. The gcode starts with the extruder jerk setting at 0, it runs smooth. Adjust it upwards and you'll start to feel the snap at the ends of the rotation. The MakerFarm default for extruder jerk is 5 mm/sec. IDK - I don't feel much difference between that and say 10 mm/sec. NOTE: My printer didn't seem to like high jerk settings like 40 mm/sec; the motor buzzed like it was missing steps. I didn't repeat it to diagnose or figure out exactly what jerk setting causes problems.Code:; gcode for demonstrating extruder jerk settings
;
G21 ; metric dimensioning
G91 ; relative positioning
M302 ; enable cold extrusion
;
G0 F900 ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M204 T5 ; override DEFAULT_RETRACT_ACCELERATION with this; mm/sec per second unit
M205 E0 ; override DEFAULT_XYJERK for E with this; mm/sec unit
G0 E10
G0 E-10
G0 E10
G0 E-10
G0 E10
G0 E-10
G0 E10
G0 E-10
There's another very important aspect related to jerk showing up in this test. Go back and rerun the gcode with different jerk settings. Note the difference in gear rotation speed that is obtained. The feed rate and acceleration settings in the gcode were purposely selected so you can see how controlling the jerk at endpoints can and does affect the max speed obtained of the overall movement. In our test example here, accelerating and decelerating to a stop at the end points using the acceleration constraint it's given, Marlin can't let the motor spin as fast mid-movement like it can if it's allowed to jump-start the feed rate to say 20 mm/sec. We're showing this on the extruder simply because it's where I lucked into the right combination of settings to notice it, and here we don't need to shut down the movement once we're out of room. The same concept would apply to the other axes. More importantly, we should be worried about this effect on X and Y since we're moving in those axes all the time.
OK. Now we know that having small jerk settings might lead to better prints but they might take longer to print. Higher jerk settings will help get prints completed faster, but at risk of some ringing in the print corners as hardware settles from being snapped around.
There's still more to know regarding jerk settings. Load up this gcode -
Here I've taken the movements from the earlier Y jerk demonstration and added some Z moves that are occurring at the same time. No, we're not going to use this to determine what Z jerk setting works. When you run it, the bed slowly moves forward and back, and the carriage slowly moves up and down. No snapping at endpoints. Now - edit the M205 Z0 to M205 Z20. Make sure you edit the M205 Z0 line. What's going to happen? Something on the Z-axis, right? Well, maybe, but we now get a pronounced snap on the Y-axis movement. Say what?Code:; gcode for demonstrating simultaneous Y and Z jerk settings
;
G21 ; metric dimensioning
G90 ; absolute positioning
;
M201 Y500 ; set safe & fast acceleration value for homing; mm/sec per second unit
G28 ; Home all to initialize the zero reference point for Z and Y
;
G0 F6000 ; override DEFAULT_MAX_FEEDRATE with this; mm/minute unit
M201 Y100 ; override DEFAULT_MAX_ACCELERATION for XY with this; mm/sec per second unit
M204 T10 ; overrude DEFAULT_RETRACT_ACCELERATION for E with this; mm/sec per second unit
M205 X200 ; override DEFAULT_XYJERK for XY with this; mm/sec unit
M205 Z0 ; override DEFAULT_ZJERK for Z with this; mm/sec unit
G0 Y180 Z10
G0 Y20 Z8
G0 Y180 Z10
G0 Y20 Z8
The gcode as provided has the Z jerk term set to 0, and the Y jerk term set really, really high. When you run it, the low jerk setting for Z dominates the move planning and the high jerk setting for Y doesn't come into play. Welcome to Marlin move planning. It is solving in a three-dimensional world, and constraints you apply in one axis can and will affect the performance of what's happening in other dimensions where a move is occurring at the same time.
I admit that I don't know the ins-and-outs Marlin move planning, but this seems to suggest it may be best to use jerk settings that are consistent for all three axes. The MakerFarm defaults are 20 mm/sec for XY, 0.4 mm/sec for Z, and 5 mm/sec for the extruder. Without knowing more about exactly how Marlin multi-axis moves, it seems we're at risk of the low value for Z affecting moves in the other axes. We were able to demonstrate that here. Again, without knowing more about Marlin planning code, this could be affecting not only Z-axis layer shifts, but also printing with spiral contours or ABL where Z is frequently adjusted, or especially with Z-lifts on retraction if that is enabled in the slicer. In the demonstrations here, I couldn't see any negative effect of running with the Z and extruder jerk settings the same as XY. So why worry about possibly constraining move planning by having them set lower?
I'm running out of demonstrations to add to the thread. But the next test is where everything we've discussed gets combined.
HOMEWORK AND INDEPENDENT STUDY
About that snap we could see in the Y axis. Why couldn't it be in the Z axis as it changes direction? Ignoring the obvious fact that we feel it in the Y-bed... Change the gcode so the Z movements keep moving in the same direction. Marlin shouldn't be decelerating and accelerating Z anymore, right? Is the snap still there?
I didn't try this, but you could put together some g-code with just Z axis movements to experiment with Z jerk settings. My guess is that nothing new is to learned by doing it, but...
...ive got to go back and read this!
Probably tomorrow while im at work
UNDERSTANDING ACCELERATION
No demonstration or conclusions in this post. For those that need it, this provides a basic explanation of acceleration. Those that are already comfortable with it can roll their eyes and go back to what they were doing.
Assume an object with a fixed linear speed. Acceleration describes how rapidly the speed is changed. If the speed is going up, acceleration is positive. If the speed is going down, the acceleration is negative, and is usually called deceleration. A high acceleration leads to a rapid change in speed. Low acceleration leads to a slower change in speed.
For our printers, the acceleration units could be stated as something like mm/sec^2, mm per squared seconds, or mm per seconds squared. In this thread, I've been consistent at describing the Marlin acceleration units as mm/sec per second, since I find that to be the best way to describe them. Speed is given in mm per second, or mm/sec. Acceleration is an amount of speed change, in mm/sec, that will occur for every second of duration. Or mm/sec per second.
EXAMPLE: An object is at rest and accelerated at 10 mm/sec per second. After one second, the object is moving 10 mm/sec. After two seconds, the object is moving 20 mm/sec. After three seconds, the object is moving 30 mm/sec. And so on.
Now consider a printer axis capable of 500 mm/sec per second acceleration and a maximum axis feed feed rate of 100 mm/sec. The axis will accelerate rapidly from a dead stop and quickly hit the maximum feed rate of 100 mm/sec. The speed stops increasing, and the axis continues moving at the 100 mm/sec limit.
The post describing the Marlin jerk settings demonstrated how a low jerk setting in one axis can dominate over higher jerk settings for other axes in a three-dimensional move. The same applies to acceleration settings. The rate at which Marlin accelerates from a point will be affected by the lowest of the acceleration settings for the axes involved in the movement.
As with the jerk settings, the farther apart the axis acceleration settings, the more this limitation can come into play. Again, without knowing enough about Marlin move planning to think otherwise, this suggests a premise that acceleration settings are best set to the same value or the at least the same ballpark.
Reiterating a point mentioned on the prior recap post, Marlin has two acceleration settings in the configuration.h file. DEFAULT_MAX_ACCELERATION has terms for specifying an acceleration for each axis. DEFAULT_ACCELERATION has a single value. Look at these as just two ways to control the acceleration, with separate gcodes. The acceleration used will be the lowest value that from the two. The MakerFarm default for DEFAULT_ACCELERATION is 500 and DEFAULT_MAX_ACCELERATION is {1000,1000,5,1000} for X,Y,Z and E. Based on the lower values between the two, the acceleration terms used will be 500, 500, 5, and 500 mm/sec per second for X, Y, Z and E respectively.
MARLIN MOVE PLANNING
Marlin does the three dimensional move planning in the planner.cpp file. I don't pretend to know enough about it to say more than I have. There are some comments in the file, but I found them lacking.
Probably the best summary I found regarding move planning was http://www.extrudable.me/2013/04/02/...th-of-z-speed/. I ran across this in searching for info on what the jerk settings are all about. The article focuses on increasing the speed of the Z axis on an Ultimaker, but the author does provide a couple of paragraphs that summarize what happens in the move planning. I can't attest to the complete accuracy of the description, but it fits the bits I was starting to grasp as I studied the move planning code. When I found that article, I stopped trying to understand the code and focused on how I could demonstrate things on my printer.
If you are going to post theoretical descriptions of things then you need to differentiate between speed and velocity then make sure you use the correct one in your description.
With no other input being provided,I've simply been documenting my learning experience as I explore the motion settings. It doesn't surprise me to find out that some of my words, examples and demonstrations may not be academically correct. If there's a distinction between speed and velocity that makes a difference in understanding the motion settings and how to optimize them, you are welcome to share that knowledge.Quote:
Originally Posted by Mjolinor