Tuning Jerk/Accel/Speed settings

wcj97

@Phaedrux Mind if I send you the excel sheet in this thread?

wcj97

@Phaedrux Also, I should note that after looking a bit closer, it wasn't my extruder that was skipping, but rather the bondtech gears becoming unmeshed. I tried increasing the pressure on the gears, but then I went too far and the printer started grinding the filament real bad, so now I have to clean that up.

Phaedrux

@wcj97 said in Tuning Jerk/Accel/Speed settings:

@Phaedrux Mind if I send you the excel sheet in this thread?

It's your thread. Do as you wish.

wcj97

@Phaedrux Extrusion_Speed_Calculator.xlsx

wcj97

@Phaedrux Ha! I realized where I messed up immediately after posting that file. I determined my max volumetric flow rate to be the max speed I could move my extruder for a given temp/nozzle size, multiplied by the area of the nozzle orifice. That would be incorrect. I fixed that calculation so that now it's the max extruder speed multiplied by the cross-sectional area of the filament and my numbers look much more appealing now. Something more like 110mm/s print feedrate. This is why it's important to always double-check your math, I guess.

wcj97

Here's the updated spreadsheet, just in case anyone else would like to take a gander and maybe make use.Extrusion_Speed_Calculator.xlsx

jens55

This post is deleted!

Phaedrux

@wcj97 said in Tuning Jerk/Accel/Speed settings:

Here's the updated spreadsheet, just in case anyone else would like to take a gander and maybe make use.Extrusion_Speed_Calculator.xlsx

Yeah that looks reasonable. The exact shape of the extrudate isn't super critical. It's just a ballpark limit to work within. I usually suggest a 10% safety margin to allow for instances where the amount of plastic being pushed is heavy enough and continuous enough to cool the hotend significantly enough to temporarily drop your volumetric throughput. Such as may occur in large areas of solid infill.

We're just measuring a brief instance of volumetric throughput. What we really should be measuring and modeling is the melt rate of the plastic in relation to the thermal system of the hotend, including pressure feedback, elasticity, drag/friction, expansion, etc, etc, but that's way beyond complex and a bit superfluous for our needs. We just need to know how much plastic we can reliably extrude in a time frame long enough to capture 99% of all printing moves.

wcj97

@Phaedrux Coming back to this thread for a quick question regarding jerk (instantaneous speed change).

The instantaneous speed setting is the speed the motor can jump to before acceleration is taken into account, correct? So if my max speed for my extruder is 6mm/s, and I set my instantaneous speed settings to 360mm/min (6mm/s), acceleration isn't being taken into account at all, right? The controller is assuming that it can instantaneously accelerate from 0 to 6mm/s?

Currently, performance is good at my current jerk values, which are set well above my max speed. I guess what I'm asking is: at this point, increasing jerk or acceleration settings doesn't really make any difference right? I've already told my printer that it can instantaneously jump to extrusion speeds well beyond my max speed, so does increasing my jerk values from here (or making any change to my accel values for that matter) have any affect at this point?

Phaedrux

@wcj97 said in Tuning Jerk/Accel/Speed settings:

if my max speed for my extruder is 6mm/s

That may be the max for extrusion, but not the max for retraction. So don't set your extruder M203 that low.

You'll want to set your extruder jerk higher than that as well so that your retractions can be faster and so that pressure advance can quickly change direction.

The extrusion speed is so low that it doesn't really matter, but retraction and pressure advance can be much quicker.

The extruder doesn't have a lot of mass to throw around like the other axis do, it's just rotation, so your jerk/accel can be quite high without issue (without skipping of course). Basically you can set the max speed and jerk/accel high enough that they ever really come into play. That allows pressure advance and retraction and the acceleration and jerk of the XY axis to dictate.

deckingman

@wcj97 No. "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move. (True instantaneous speed change is actually impossible in any case). Think of it as a speed change threshold which gets applied when a the object is in motion and there is a change of direction. So instead of one move slowing down to a complete standstill before the next move starts, the move will slow down to the instantaneous speed change threshold (jerk) instead, and the next move commences at that speed. Given that any print move will be a combination of XY and E, and the speed will be the lowest of any of those axes at any point in time, then the only time that extruder jerk would be applied to a print move is if it is set to give a lower speed than X or Y, in which case it would slow down the entire print move. There are only two (I think) instances where extruder jerk is applied. One is when using pressure advance, and I can't remember the other. But in both cases, setting extruder high rather than low is the way to go.

arhi

@deckingman said in Tuning Jerk/Accel/Speed settings:

Jerk is never applied at the start of a move.

How does the start of the move look like? I had an assumption that start of the move, since going from 0, will always use acceleration from 0 but I had issues with new Orion sensor triggering falsely and the guy's from precise piezo asked me to set the Z jerk to 0 as Z move would "jump to jerk speed" and that triggers the Orion. I made the change and solved the problem so looks like that jerk value do affect the start of the move.

dc42

@deckingman said in Tuning Jerk/Accel/Speed settings:

"Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move.

It does in recent versions of RRF if you set the jerk policy to 1 in M566.

arhi

@dc42 this is interesting. why would

M566 X500.00 Y500.00 Z0.00 E6.00

not trigger my piezo on G30 while

M566 X1500.00 Y1500.00 Z50.00 E6.00

will trigger G30 when the bed starts to rise?

that's the only M566 in all the files, I never set P to 1 ?

It is confusing me. I kept the M566Z0 as I didn't notice any difference in print behavior between Z0 and Z50 and with Z0 piezo sensor works ok. Why I would like to know how it actually behaves is I was thinking about adding support of RRF to the gcodestat so that I can calculate precise print time from a g-code, but I'm waiting for the few more 3.x versions as I see you are still changing things

deckingman

@dc42 said in Tuning Jerk/Accel/Speed settings:

@deckingman said in Tuning Jerk/Accel/Speed settings:

"Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move.

It does in recent versions of RRF if you set the jerk policy to 1 in M566.

I missed that - thanks (and thank goodness its optional)

bot

I seem to recall having similar behavior displayed on my machine when commissioning the Z axis. It wasn't related to a piezo probe, but merely the fact that jerk was "being applied" from a stand still. I'm not certain of this, but it rang a bell for sure. I even remember making a thread about my Z axis making noises at one point.

Phaedrux

@arhi said in Tuning Jerk/Accel/Speed settings:

@dc42 this is interesting. why would

M566 X500.00 Y500.00 Z0.00 E6.00

not trigger my piezo on G30 while

M566 X1500.00 Y1500.00 Z50.00 E6.00

will trigger G30 when the bed starts to rise?

that's the only M566 in all the files, I never set P to 1 ?

It is confusing me. I kept the M566Z0 as I didn't notice any difference in print behavior between Z0 and Z50 and with Z0 piezo sensor works ok. Why I would like to know how it actually behaves is I was thinking about adding support of RRF to the gcodestat so that I can calculate precise print time from a g-code, but I'm waiting for the few more 3.x versions as I see you are still changing things

Having Z jerk set to 0 would cause stuttering in X and Y when using mesh bed compensation since it would be trying to slow down to nothing in X and Y while it waited for the Z axis to adjust position.

The gcode wiki entry for M566 is instructional here.

https://duet3d.dozuki.com/Wiki/Gcode#Section_M566_Set_allowable_instantaneous_speed_change

When mesh bed compensation is used, movement may be jerky if the allowed Z jerk is too low, because the Z speed needs to change abruptly as the head moves between squares in the mesh.

The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

Phaedrux

@deckingman said in Tuning Jerk/Accel/Speed settings:

I missed that - thanks (and thank goodness its optional)

I've had good results with jerk policy 1, I think mainly because it reduces the pause time between the end of a print move and the start of a travel move. Since before jerk was only being applied between two consecutive print moves or travel moves, but not between print moves and travel moves.

bot

@Phaedrux I agree. I could see how it could help alleviate bulging at termination points. I might try it out and see how it goes. If anything, it just makes every move consistent. The beginning and end of every print move would be the same.

deckingman

@Phaedrux said in Tuning Jerk/Accel/Speed settings:

@deckingman said in Tuning Jerk/Accel/Speed settings:

I missed that - thanks (and thank goodness its optional)

I've had good results with jerk policy 1, I think mainly because it reduces the pause time between the end of a print move and the start of a travel move. Since before jerk was only being applied between two consecutive print moves or travel moves, but not between print moves and travel moves.

Interesting. But I don't think I'd want to attempt an instantaneous speed change from rest with the 3Kgs of mass that I have to shift.