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

burtoogle

On request, I have been adding some more accel/jerk settings into Cura and I am wondering if it would be beneficial to have jerk specified separately for printing and travel moves (i.e. have the jerk equivalent of M204 which can set acceleration separately for print and travel moves)? As it is now, the slicer has to generate a lot of M566 commands when travel and print moves are interleaved. This bloats the gcode and probably has a performance impact also. Any thoughts?

Veti

the duet cant really differentiate between printing and travel moves in all cases.

the performance impact should not be a problem since the duet print from sd card.
this can become an issue when printing over serial which has limited throughput.

deckingman

@burtoogle I'd have thought that it might be difficult to implement in practice. From my (limited) understanding that "jerk" is the instantaneous speed threshold. So for a single travel move, if "jerk" is applied at the start of that travel move, then it must of necessity be applied to the end of the preceding print move. Conversely, to apply a different "jerk" speed to the end of a travel move, then it must of necessity be applied to the beginning of the next print move. So in that scenario, I can't off hand see how "jerk" could be applied differentially between print and non-print moves. I guess what I'm trying to say that there is only one cut off point between print and non-print moves, so one can't apply two different thresholds to that single event.

DocTrucker

The way Slic3r runs at the moment it would be easy to inject lines to change jerk for moves after slic3r changes to the acceleration speeds set for the travel and or print moves.

I've got it on my radar to try this so infill is high jerk, but perimeter lower. There is also hints that ideal jerk settings are related to acceleration, so if like me you lower the acceleration for perimeter then the ideal jerk would also change.

Veti

cura already has the ability to set different jerk an acceleration for printing an travel moves.

burtoogle

The point I am making is that RRF already has M204 to set separate accel for print and travel moves so would it make sense to have a similar command for setting the jerk rather than having to have very many M566 commands as you do now when the jerk is being changed due to different jerk being requested for printing and travel moves.

SteveYYC

Wouldn't you effectively get separate jerk settings for printing and moving if you set the jerk for E to the print jerk and X,Y,Z to the move jerk?

The firmware would be smart enough to never jerk the move axes faster than the extruder can keep up, so during printing wouldn't this effectively limit the jerk on the move axes to the E axis value?

burtoogle

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

Wouldn't you effectively get separate jerk settings for printing and moving if you set the jerk for E to the print jerk and X,Y,Z to the move jerk?

The firmware would be smart enough to never jerk the move axes faster than the extruder can keep up, so during printing wouldn't this effectively limit the jerk on the move axes to the E axis value?

Maybe, but I think people would just get confused with two different kinds of jerk.

SteveYYC

@burtoogle

It would just be one line in the GCODE:

M566 X2000 Y2000 Z2000 E1200

where 2000 is the movement jerk in mm/min and 1200 is the extruder jerk in mm/min.

I already use a command like this so I'm interested if I'm making an error in my assumptions about whether it's using the higher jerk setting for movement-only and the lower for printing.

bot

@steveyyc

E jerk isn't applied in the way it seems you think it is. The E axis is a linear axis just like X Y Z, etc. For any given feedrate (the speed at which the nozzle travels through physical space) and layer height/extrusion width/filament diameter combination, there is an E axis speed that corresponds. In the case of most typical 3d printer setups, the E axis speeds are much lower than the feedrate when extruding at standard layer heights and extrusion widths.

For example, the printing feedrate might be 100 mm/s, but during those printing moves the E axis might be moving 10 mm/s. Note these are not volumetric measurements.

What this has to do with what you're saying is that the E jerk (and accel, max speed, etc.) refer to the E axis speed itself. The speeds of the axes are all coordinated to respect the lowest max speed, acceleration, jerk value etc.

Basically, the command you showed sets the E jerk at 20 mm/s, which is way higher than is needed to restrict the jerk of the X/Y axes.

If, for example, the XY axes instantly change speed to 10 mm/s, the E axis will only need to instantly change speed to about 1 mm/s. Therefore, if you want to restrict the jerk of the X/Y axes, you need to have an E jerk value at least an order of magnitude lower than the XY jerk values.

This depends on the individual setup and printing parameters, but generally this is true.

That said, there could be downsides to having an E jerk value too low. @deckingman has, I think, experienced some issues in relation to pressure advance and also rounding segmented arcs, as we do when we export meshes into gcode.

TL;DR: lower that E jerk value if you wanna try out what you're talking about.

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?