CoreXY - speed constrained?

691175002

I'm not sure if I'm misunderstanding something here, but I was under the impression that G1 coordinated moves will always respect the configured acceleration and velocity limits regardless of their orientation.

Physical kinematic limits should only affect motion when the commanded movement is not physically possible, which should never occur outside of deliberate testing.

As mentioned, Cartesian and CoreXY printers can produce faster movement when multiple motors are driven at the same time, but this should be completely irrelevant when slicing or printing models.

(The sole exception would be a G0 uncoordinated move, but I'm not sure if any 3d printer firmwares actually perform uncoordinated movement.)

DocTrucker

There is a g code command to limit the print and travel accelerations.

I'd prefer to set the config file values to the maximum physical capability of the machine and then limit the actual accelerations on a per geometry type as Slic3r allows.

Running up to the physical limits like discussed here would result in different conditions for the deposition of the polymer depending on the deposition direction and that would potentially cause more orientation related artefacts.

Edit: That said Slic3r was implementing that badly last time I checked.

pro3d

@691175002 I am mostly interessted in jerk primarily and then acceleration. Speed is always obtained but if jerk and accel are 50% on diagonals then I need to consider this when setting this in the firmware

Phaedrux

@pro3d said in CoreXY - speed constrained?:

Speed is always obtained but if jerk and accel are 50% on diagonals

I didn't get the impression that this is the case from @dc42 s comments.

deckingman

@pro3d The worse case is moving the entire mass of both carriages with single motor. Unless you've got extremely heavy carriages and extremely small motors, the accelerations you use for printing will be far less than this worse case.

But I think you are being unduly concerned. Do the maths. If you had acceleration set to 1500mm/sec^2, the to reach 60mm/sec would take 0.04 seconds and the print head would move 1.2mm during that acceleration phase. If you then double the acceleration to 3,000 mm/sec^2 then to reach 60mm/sec takes 0.02 seconds and the print head would move 0.6mm.

That's assuming a start and end speed of zero. In reality, you would have jerk configured so the start and end speeds would be non zero.

Phaedrux

@doctrucker said in CoreXY - speed constrained?:

That said Slic3r was implementing that badly last time I checked.

I just checked and from what I can tell Slic3r is using M204 S rather than P and T for acceleration adjustment when using RepRap flavor. Still seems to work though. At least they aren't using M201.

DocTrucker

Are you running dev version of Slic3r or stable 1.3.0?

Phaedrux

@doctrucker slic3r PE 1.41.2

DocTrucker

I'm using Slic3r 1.3.1-dev build commit a4a0d52 downloaded a few days ago. Code in there is:

M201 X500 Y500
M204 P500 T500

This is run before every geometry type. It is a functional, but ugly hack which I'm hoping they fix soon.

The M204 setting limits the acceleration along the length of the vector so so long as this value is below the X and Y values (or a little less in the case of core XY) then this will result in the same acceleration in any direction in the XY plane. I'm thankful for this thread as I was under the understanding that the XY parameters in the M201 command applied to the individual motors, rather than an axis.

It's not so much the time or distance to get to speed that concerns me, it's more how well the system handles the short vectors that most slicers kick out identified in the following linked thread and also in the work @deckingman presented on mixing with small ratios on one of the extrusion axis.

I would like to be able to limit the acceleration on the small perimeters to keep the motion a bit smoother. I would use an unique speed setting for the small perimeters in Slic3r so a parser could identify that block then append a suitable M204 line before the block of vectors.

https://forum.duet3d.com/topic/8484/what-hapens-with-successive-sub-step-relative-extrusions/4

deckingman

@doctrucker said in CoreXY - speed constrained?:

...........................

I would like to be able to limit the acceleration on the small perimeters to keep the motion a bit smoother.

Just a thought Wes but I'd imagine that if the small perimeters are segmented as is likely, then acceleration won't come into it much. It'll start a small segment at the jerk speed and finish at the jerk speed so if it's a small segment then there isn't likely to be much of an acceleration or deceleration phase. All in all, I'd have thought that changing instantaneous speed threshold (jerk) would have more of an effect on the motion of small perimeters than changing acceleration (but I could be wrong - often am ).