CoreXY - speed constrained?

pro3d

I did set firmware to 300 max speed

In this video I ask for 300mms just to check the mechanics. Somehow it says 212/214 on some movements

What can be the reason?

Go to 2 minutes in the video
https://youtu.be/hVf9eABEwaI

JoergS5

This post is deleted!

dc42

Movement on a diagonal is done by just one motor working twice as hard, so the firmware limits the speed and acceleration to half the values for pure X or Y movement that you configure in the M203 and M201 commands in config.g.

deckingman

@pro3d Can you post your config.g and also a sample of the gcode file you were trying to print.

BTW, having looked at your video and heard your comments, it is possible to print at 300 mm/sec

https://somei3deas.wordpress.com/2018/10/14/real-3d-printing-at-high-speeds-and-even-higher-melt-rates-with-a-large-nozzle/

Here is what it looks like (300mm/sec is from about 10 mins 20 secs) https://www.youtube.com/watch?v=rUV5IZxfAxU&t=697s

thwe

recently I had also checked my mechanics - see the video:

https://youtu.be/Vj9jpNAjHS4

movements in the straight were also fully extended, the oblique movements and the circle are at max. 330 - 360 mm/s

(I think that's more than enough )

pro3d

@dc42 said in CoreXY - speed constrained?:

Movement on a diagonal is done by just one motor working twice as hard, so the firmware limits the speed and acceleration to half the values for pure X or Y movement that you configure in the M203 and M201 commands in config.g.

Thanks for the response. I did not understand what you mean. Pure perpendicular movement when both motors are working has half the acceleration? So when 1500 in accel it does 750? Or the other way around?

Edit
I confused myself. Did you mean xy movement has acceleration reduced? Diagonally moved? One motor

dc42

The firmware has to treat accelerations and speeds on CoreXY machines differently from Cartesian.

On a Cartesian printer, the X and Y motions are independent, so X and Y speed limits and accelerations are applied independently. This means that the speed and acceleration that the firmware will allow for a diagonal move is sqrt(2) times the speed for a pure X or Y move (if the X and Y speed limits ar3e the same, and similarly for the accelerations).

On a CoreXY printer, pure X and Y moves are done by both motors contributing equally. But pure diagonal moves are done by just one motor. So whereas on a Cartesian printer, you can execute diagonal moves with greater acceleration and speed than X or Y moves, on a CoreXY the reverse is true.

You could argue that for a pure diagonal move, the speed and acceleration limits should be one quarter of the limits for pure X and Y moves: one half because one motor is doing all the work, and another half because that motor is moving both the X carriage and the Y gantry. But the current firmware doesn't go that far, it only takes account of how much of the total work each motor is doing.

pro3d

@dc42 so what do I have to do to get same performance for diagonal movement as perpendicular? Or is this not possible

Phaedrux

@dc42 I've sometimes wondered if it would make sense to rotate the solid infill direction in the slicer 45 degrees to take advantage of using both motors at the same time.

dc42

@pro3d said in CoreXY - speed constrained?:

@dc42 so what do I have to do to get same performance for diagonal movement as perpendicular? Or is this not possible

It's not possible for a CoreXY printer to have the same peak performance for diagonal moves as for X or Y moves, that's in the nature of the mechanics. It would be possible to change the firmware to restrict the pure X and Y acceleration and speed so that it doesn't exceed what can be managed for diagonal moves; but would that really be useful?

deckingman

@pro3d On the basis that two motors will always have more torque than one, then no - it isn't possible to get the same theoretical performance in both diagonal as perpendicular. Having said that, your ultimate print speed is constrained not by how fast you can move the axes, but by how fast you can melt and extrude filament. The simple thing to do is to spec the motors so that one motor is capable of accelerating the entire mass at the desired rate.
@Phaedrux On a coreXY yes, you could set infill to 90 degrees (or 0 degrees) but are you likely to be able to make use of that extra torque? Is you print speed currently constrained by the available motor torque? Or to put it another way, do you have to print 45 degree infill at lower speed because motor torque is the limiting factor?

pro3d

@deckingman I don't really print much faster than 60mms so my questions is due to my curious nature.

It was also new to me so I wonder how I can obtain the smoothest movement if jerk and acceleration is half on the diagonals. Then if I want minimum accel at 1500 I must set 3000 as accel if I understand. Then it will accelerate 3000 on perpendicular moves. Jerk will be the same and with 30 in jerk I think I will push the limits so I need to figure out what would be the solution with the best and smoothest performance in my case

Speed is not the issue here but acceleration and jerk

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