CoreXY - speed constrained?

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