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

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