Tuning Jerk/Accel/Speed settings

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.

Phaedrux

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

@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.

Yes, my understanding of it was only between moves. I wasn't aware of it being applied from a resting start. @dc42 would have to clarify.

bot

@Phaedrux AFAIK, in marlin et al, jerk is applied all the time no matter what. Those firmwares are (for some reason, last time I checked) unable to drive the steppers SLOW ENOUGH to start from an actual stop.

arhi

@bot can't say really, visually and sound to me seem 100% identical between M566Z0 and M566Z50. I cannot differentiate them. What I can say is that Orion does differentiate them as it reads 775-779 when idling and trigger is set to 850. I move to 0,0 wait 5 seconds and do G30 so the bed starts going up if the M566Z50 the second bed starts to go up I get trigger and if M566Z0 the trigger happens only when the bed hits the nozzle. Looking at the movement, listening to a motor, no difference between the two, but there definitely is something different.

arhi

@Phaedrux I did read the manual, but the behavior I'm seeing does not verify what I read there. During first few layers I don't notice any stuttering with M566Z0 but in any case I did change my script to setup M566Z50 normally and I do M566Z0 only during homing and probing. But again, audio/visuals do not show difference between M566Z50 and M566Z0. I never set P to 1 so whatever is default (0 by documentation).

I run now the M566 without parameters and I set Z0 again and looks like I cannot set zero ?! Maybe it has to do with point that it's printing now but again, nothing set M566 to any value but 0 since the machine was turned on today.

2/20/2020, 8:42:50 PM 	M566Z0
2/20/2020, 8:42:52 PM 	M566
Maximum jerk rates (mm/min): X: 500.0, Y: 500.0, Z: 6.0, E: 6.0, jerk policy: 0

Seems that lowest value for Z is 6.0 ?

Phaedrux

@arhi yes. Right below the section I quoted from the wiki it states the minimum as 0.6mm/s

deckingman

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

.................. Yes, my understanding of it was only between moves. I wasn't aware of it being applied from a resting start. @dc42 would have to clarify.

That's two of us then I wrote "Jerk" doesn't work like that in RRF firmware. Jerk is never applied at the start of a move." To which DC replied "It does in recent versions of RRF if you set the jerk policy to 1 in M566."

bot

@arhi are you positive the Z axis is only moving in one direction when it triggers the piezo? Is the probe command moving the z axis a tiny bit in one direction first? Is any other type of Z compensation enabled when this occurs?

arhi

@bot I'm not sure of anything not easy to see things clearly with all this glass and acrylic. It does look like the bed is put into position and then sits still 3sec as configured and then goes up towards the nozzle. If I set jerk to 0 it works ok, if I set jerk to 60 the start of the movement triggers the piezo.

In any case, none of this is a problem for me, I made it work with analog output and I'm happy with it. It's just confusion about what I'm reading and what I'm seeing first hand. It would be cool to properly understand the behavior that's all.

bot

@arhi I'm glad you got it sorted out!

It's still puzzling that the Jerk value would affect anything in that scenario.

I wish I myself was capable of understanding the source code. I would love to check things over myself but I'm not able to. Not that I don't trust or love the firmware, but there have been a few instances where errant behaviour has gone undetected so I like to highlight problems, no matter how small, when they arise, so they can get attention if they need it.

jens55

I had an Orion sensor for a while. For probing I would set jerk to zero and acceleration to very low (don't recall actual number) in order to not cause false triggers on the Orion. It is extremely sensitive in some respects and not so much in others which is why I eventually reverted back to a BLTouch.

arhi

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

@arhi I'm glad you got it sorted out!

It's still puzzling that the Jerk value would affect anything in that scenario.

No clue, it would never occur to me to try to change it. I contacted precise piezo guys with "what am I doing wrong it is all over the place", the first thing they said was you are using duet, set Z jerk to 0 and you should use analog output it works great with duet, much easier to configure than using the fiddly trimmer. Changed Z jerk to zero - issue went away, returned Z jerk to 60, issue came back, so behavior confirmed. What is weird I can usually hear if not see these changes in speed but I can't hear any difference?!?! Have not tried P=1