Different jerk settings for travel and print moves

vp

Problem
Travel moves should be as fast as possible, to minimize oozing and print time. Travel moves do also include “travel moves avoiding crossing outlines”, which means several travel moves in series. In this case, when a travel move follows directly another travel move, the jerk and acceleration settings could be much higher. Only for the deceleration part of the very last travel move jerk and acceleration settings should be low.

Solution
Right now it is possible to adjust the acceleration for travel and print moves differently but not the jerk settings. But travel moves could be done much quicker by using different jerk settings for travel and print moves. So we have to be able to set the jerk values differently for print and travel moves.

DjDemonD

Or perhaps jerk could be just factored in the firmware for travel moves by 2?

thehair

Wouldn't this be more of a slicer thing instead of the duet? The duet has no way of knowing what is a travel move and what is a printing move, other that the fact that one has extrusion and one doesn't. I think all you would need to do is have your slicer insert a M566 command before (and after) a travel move in order to change the jerk setting for that specific move.

DjDemonD

Well you've answered your own question the firmware does know the difference as it is either extruding or it isn't.

M204 exists to set max acceleration for print and travel, so why not jerk also?

Whether it will make a difference is not 100% clear but if it were possible to implement it then we could experiment.

Having the slicer add M556 commands before and after travel moves would be a possible workaround but would double the size of some gcode files.

dc42

I would like slicers to flag each move with the type of that move (except where the type is the same as the previous move) as I described in my proposal for GCode that is less printer-dependent. See http://forums.reprap.org/read.php?1,803621,page=1.

DjDemonD

Does that provide more detail than presuming a move with extrusion is a printing move and a move without is a travel move? Just curious.

dc42

It isn't just printing vs. travel moves that I would like the firmware to know about.

sigxcpu

Wasn't G0 defined for this? The problem is that slicers "reinvented" G-code.
G0 is a fast, move without the need for axes synchronization (e.g. travel) , G1 is a coordinated move, where all axes need to reach the endpoint at the same time, therefore each has to have a specific speed.

So the slicers could've been done the right thing and implement it like it was supposed to be implemented. There is no point in having a coordinated move for travel.

BMMal

@dc42:

I would like slicers to flag each move with the type of that move (except where the type is the same as the previous move) as I described in my proposal for GCode that is less printer-dependent. See http://forums.reprap.org/read.php?1,803621,page=1.

I would really like this too. It just makes sense from a usability stand point - it also allows you to easily tweak settings in the machine while it's printing rather than having to stop reslice and restart. I would also like to see the filament files in firmware become more robust and have a UI that allows you to set any filament related parameters in the machine.

I know nobody really likes $tratasys but they are a good example to learn from. Their slicers only tell the machine trajectories and extrusion sizes, support trajectories, and some set up info like nozzle size (which limits the layer height and extrusion widths), as well as checking for special cases ie min layer time and special geometry, etc. Because so much of this work is offloaded for later, their slicing is much faster. You don't even have to tell it what material you are using (the machine takes care of this through the cartridge eeprom) although it can be input (I'm not sure how that affects the results). They have a couple hundred parameters in each of their material files which is specific to every material, model of machine, and nozzle size. The machines then use the on-board parameter files and the incoming information from the slicer to compile the actual moves the machine makes as the print runs.