Would separate jerk setting for printing/travel be a good thing?

[DocTrucker]

I'm in favour of a second command but for different reasons.

My issues with using 566 are:

• There needs to be a command that defines a safe limit for the hardware, and another that allows variations.
• Current implementations based on 566 specify jerk limits relative to axis whereas the print and travel limits are relative to the dorection of travel. This results in the jerk changing dependant on angle of the vector.

Yes, I have seen ultimaker destined gcode with variations in jerk (M205 I think), but I personally prefer my slicer to not be aligned too closely with any single manufacturer.

[deckingman]

@doctrucker I would just like to refer people back to my earlier post because I think it's important. Jerk or more correctly instantaneous speed change is a threshold which gets applied at the boundary between two moves. Therefore, when transitioning between a print and a non print move, there is only one boundary so one can only apply one "jerk" speed to that boundary. So if a different jerk value is used for a single non print move, then it must be applied to the end of the previous print move and to the beginning of the next print move. So it's impossible to have a different jerk value for a single non print move without changing the jerk value for the print moves which are either side of it. Or conversely, if we maintain the integrity of the jerk value for print moves, then it is impossible to apply a separate jerk value for single non print moves.

[dc42]

RRF doesn't use jerk for travel moves, because it isn't necessary. The only reason for jerk is so that the tool head can follow a gentle curve made up of straight line segments without slowing down whenever the direction changes.

That said, I've just realised that jerk is probably not being applied to cutting moves on laser cutters, and I should change that.

[burtoogle]

@dc42 said in Would separate jerk setting for printing/travel be a good thing?:

RRF doesn't use jerk for travel moves, because it isn't necessary. The only reason for jerk is so that the tool head can follow a gentle curve made up of straight line segments without slowing down whenever the direction changes.

That said, I've just realised that jerk is probably not being applied to cutting moves on laser cutters, and I should change that.

Hi @dc42 , thanks for that info.

So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

[DocTrucker]

@deckingman I'm not fussed about the travel moves. They can default to the highest values as defined in the config. I'd like infill some where in the middle and perimeter lower still. It's not as easy to apply as variable acceleration due to the event happening between two vectors but there is already look ahead in the code so this shouldn't be too difficult to work around.

[dc42]

@burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

Correct. I can't see any advantage to using jerk in travel moves, except that it would make the moves slightly faster. But it would also be more likely to excite ringing.

[burtoogle]

@dc42 said in Would separate jerk setting for printing/travel be a good thing?:

@burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

So, if I understand correctly, changing the jerk using M566 for a travel move imbetween two extrusion moves, is, essentially, a no-op? If that is true, I will change Cura so that when generating RRF flavour g-code it doesn't bother trying to change the jerk for travel moves.

Correct. I can't see any advantage to using jerk in travel moves, except that it would make the moves slightly faster. But it would also be more likely to excite ringing.

Thanks, I shall remove the M566 for travel moves in Cura.

[Phaedrux]

@burtoogle Does that mean jerk is being applied to travel moves in the ultimaker firmware?

[burtoogle]

@phaedrux said in Would separate jerk setting for printing/travel be a good thing?:

@burtoogle Does that mean jerk is being applied to travel moves in the ultimaker firmware?

Sorry, I don't know the answer but I would guess, yes. The ultimaker firmware is based on Marlin (I believe).

[Phaedrux]

@burtoogle said in Would separate jerk setting for printing/travel be a good thing?:

Thanks, I shall remove the M566 for travel moves in Cura.

@dc42 @burtoogle
How will this change affect the combing travel moves that have direction changes in them? Such as those to avoid crossing perimeters, or to only travel within infill. Wouldn't you want jerk to apply to these moves since they aren't traditional point to point travel moves?

[burtoogle]

@dc42, having just removed the setting of jerk for travel moves in Cura, I took a look at the RRF source. To my horror, it looks like it does do lookahead (and hence uses the instantDv values) between two non-printing moves as the test that controls the call to DoLookahead() simply requires that this and the previous move both involve xy movement and both are either printing or non-printing moves.

Please check the code and tell me that I am wrong so I don't have to go back to the Cura devs and ask for the PR to be reverted!

[dc42]

@burtoogle, I am sorry to have misinformed you. You are right, RRF does apply jerk between two non-printing moves. I can see now that there would be a number of issues if it didn't.

[burtoogle]

Hi @dc42. Understood, no problem.

So a separate setting for travel jerk could be implemented if it was considered worth doing? However, I think the only real benefit would be that it would cut down on the number of M566 commands required when printing areas like skin where you often have very many printing and non-printing moves in sequence. I'm sure you have enough to do though without this. Let's forget this thread.

[bot]

@burtoogle

IIRC, jerk and accel settings are not acted upon immediately in RRF. I think it can take a few moves until they kick in.

I have been advised in the past to avoid dynamically changing accel and jerk within gcode of a print.

Has anything changed in that regard?

[dc42]

@bot said in Would separate jerk setting for printing/travel be a good thing?:

IIRC, jerk and accel settings are not acted upon immediately in RRF. I think it can take a few moves until they kick in.

The jerk value is used in the lookahead queue. As new moves are added to the queue, the latest value of jerk is used to join them to moves already in the queue. Depending on the state of the queue, the firmware may have to look at other moves already in the queue; so the latest jerk valuet might be applied to moves already in the queue too. This is likely to apply to other firmwares as well as RRF.

What is the purpose of changing jerk in the middle of a print?

[Phaedrux]

@dc42 said in Would separate jerk setting for printing/travel be a good thing?:

What is the purpose of changing jerk in the middle of a print?

I use seperate values for external walls and for infill, for example. Same for acceleration. Cura has the option to specify different values for inner walls, outer walls, solid infill, sparse infill, first layer, top layer, travel, etc.

[DocTrucker]

@dc42 said in Would separate jerk setting for printing/travel be a good thing?:

What is the purpose of changing jerk in the middle of a print?

Because high jerk is quicker but can trigger ringing and cause ghosting. This isn't a problem for infill that is in the middle of a part with three outer contours and three top and bottom layers.

From what I think you've said in the past ideal jerk is related to acceleration setting amongst other things, particually when referring to ringing, and cancelling the ring. Therefore where you can specify acceleration in a slicer we should also be able to adjust jerk.