Duet Maestro Struggling to Produce Smooth Curves

dc42

The motors have a higher rated current than we recommend for the Maestro, however I doubt that's part of the problem. If it were, then you would see ripples on flat surfaces as well as on curves.

If the faceting occurs only on curves, then it's a feature of the GCode file and/or the slicer, but most likely the GCode file. It might be exacerbated by the extrusion mechanics if the XY jerk settings are too low to allow the facets to be printed at constant speed, and there isn't sufficient pressure advance to compensate that. That effect is clearly visible in your first image. In that image, it appears that about half way up the print, you have increased the allowed XY jerk sufficiently to allow the print to proceed at constant speed. Above that, the firmware is just printing the facets that the GCode file told it to.

If you want finer facets, then I think you will need to go back to the original model and export it to STL with finer facets. Alternatively, you may be able to use a GCode post-processor such as Arc Welder to turn the facets into G2/G3 curves.

CCS86

@dc42 said in Duet Maestro Struggling to Produce Smooth Curves:

Above that, the firmware is just printing the facets that the GCode file told it to.

If you want finer facets, then I think you will need to go back to the original model and export it to STL with finer facets. Alternatively, you may be able to use a GCode post-processor such as Arc Welder to turn the facets into G2/G3 curves.

If you read further down, you will see that I used arc welder to process the cylinder gcode, and still see the faceting. Any ideas on that?

Didn't you mention plans for the motion planner that would use an allowable path deviation to help smooth facets and reduce reliance on jerk?

dc42

@CCS86 said in Duet Maestro Struggling to Produce Smooth Curves:

If you read further down, you will see that I used arc welder to process the cylinder gcode, and still see the faceting. Any ideas on that?

What perimeter printing speed did you use, and what is the diameter of the part? Knowing those, I can work out what segment size RRF will use for the G2/G3 moves.

CCS86

@dc42

I posted a code snippet of a single wall:

G0 F7650 X66.46 Y133.941
;TYPE:WALL-OUTER
G3 X59.665 Y131.199 I-0.004 J-9.780 E18.81959 F2700
G3 X56.678 Y124.500 I6.796 J-7.046 E18.89384
G3 X59.175 Y117.612 I9.776 J-0.353 E18.96800
G3 X65.774 Y114.385 I7.287 J6.541 E19.04236
G3 X72.742 Y116.642 I0.691 J9.751 E19.11650
G3 X76.195 Y123.114 I-6.281 J7.508 E19.19075
G3 X74.174 Y130.180 I-9.725 J1.040 E19.26515
G3 X67.884 Y133.837 I-7.718 J-6.036 E19.33876
G0 F2430 X67.829 Y133.845

I ran at 45mm/s and 60mm/s.

dc42

Look like about 10mm radius then. The segment length used by RRF 3.2 is:

length = min(sqrt(8 * radius * 0.02), speed/50)

subject to a minimum of 0.1mm and a maximum of 2.0mm. Putting your figures in, at 60mm/sec we get:

length = min(sqrt(1.6), 1.2)

so the minimum segment length will be 1.2mm. Does this fit with what you observed?

The Maestro has no hardware floating point unit, so there is limited scope to use smaller segments. However, the arc generation algorithm has been speeded up somewhat in the 3.3beta source code, so there may now be some scope.

CCS86

@dc42

1mm does match up to the faceting I am seeing there.

So RRF is taking the arc and decomposing them back into line segments to drive motion? Somewhat counter productive, if I can already output sub 1mm segments from the slicer. I was hoping that the arcs could help to avoid the segment junction issue, by making them tangent, but it appears to by making them worse in this case.

A Former User

@CCS86

As far as I recall as processors/boards get faster, in the future, the integrated line-segmentation will overtake one day by beeing faster and finer by dirctly controlling the motor (in the long run...)... If you ask me if the duet-community does not want the hardware to be considerably more expensive (I don´t want that) we have to wait until our price-segment cpu etc. get´s faster...

I stay with pre-segmentation in the post-processor til that day because a hot plastic-stripe is anyhow far from being perfect

Hope that is of any help & great post - because thanks to you dc42 posted the formula

CCS86

@LB said in Duet Maestro Struggling to Produce Smooth Curves:

@CCS86

As far as I recall as processors/boards get faster, in the future, the integrated line-segmentation will overtake one day by beeing faster and finer by dirctly controlling the motor (in the long run...)... If you ask me if the duet-community does not want the hardware to be considerably more expensive (I don´t want that) we have to wait until our price-segment cpu etc. get´s faster...

I stay with pre-segmentation in the post-processor til that day because a hot plastic-stripe is anyhow far from being perfect

Hope that is of any help & great post - because thanks to you dc42 posted the formula

I don't think this is a hardware limitation. The Maestro can already chug through super dense code to approximate curves with smooth motion. It would be far less taxing on the hardware to use motion planning that allowed path deviations to virtually erase these segment vertices, and not rely on jerk (not a trivial coding task though).

Is anything like that planned @dc42?

dc42

@CCS86 said in Duet Maestro Struggling to Produce Smooth Curves:

It would be far less taxing on the hardware to use motion planning that allowed path deviations to virtually erase these segment vertices, and not rely on jerk (not a trivial coding task though).

Essentially you are askling RRF to second guess that the user wanted a curve, not facets. IMO that's the wrong approach. Jerk does not produce facets, it merely allow them to be printed without slowing down at each junction.

The correct approach is for the input GCode to have either facets too fine to see, or not gacets at all and G2/G3 curves instead. The focus of RRF should be to be able to print those curves without visible facets. As it happens, I already did some work in RRF 3.3 to make the computations more efficient, which will allow finer segmentation of curves. If you wish, you can try out a 3.3 internal build and we can work together to establish how fine we can make the segments.

CCS86

@dc42

That's a fair point for sure. Inferring the user intention is very difficult.

One approach could be to only allow this "path smoothing" on segments below a certain length threshold and below a certain angular separation; both user defined, along with the max deviation. It seems like this would put the user firmly in control.

I'm happy to do some testing on 3.2 vs 3.3. I actually haven't managed to choke 3.2 yet, so that would be the first order of business!

MJLew

@dc42 Does the firmware use a finer G2/G3 arc segment for Duet boards with better calculation capacity?

I'm working with G2/G3 segments on my Duet 2 Wifi and I can occasionally see fine facets in cylinders (occasionally as in when everything else worked well!).

dc42

@MJLew said in Duet Maestro Struggling to Produce Smooth Curves:

@dc42 Does the firmware use a finer G2/G3 arc segment for Duet boards with better calculation capacity?

I'm working with G2/G3 segments on my Duet 2 Wifi and I can occasionally see fine facets in cylinders (occasionally as in when everything else worked well!).

Currently, all boards use the same segment length. It would probably make sense to use finer segments on boards with floating point hardware.

CCS86

Okay, it looks like I was able to choke the Duet Maestro with RRF3.2 at 95mm/s printing 0.17mm segments.

So, just about 560 segments per second.

Scheduled moves 97706, completed moves 97706, hiccups 0, stepErrors 0, LaErrors 0, Underruns [26740, 0, 19], CDDA state -1

Added cylinder in Superslicer (20x20x20).
2 walls.
Speed varied every 2mm from 60mm/s - 112mm/s.
XY accel = 3000 mm/s/s.
XY jerk = 10 mm/s

choke.gcode

dc42

Thanks, it looks like there is scope to increase the maximum segments/sec for G2/G3 moves then.

CCS86

@dc42 said in Duet Maestro Struggling to Produce Smooth Curves:

Thanks, it looks like there is scope to increase the maximum segments/sec for G2/G3 moves then.

I'm guessing that on your end steps/sec might be more important, these are 0.9* steppers with the following configuration:

M92 X159.93 Y159.75                       ; set steps per mm
M350 X16 Y16 I1                           ; configure microstepping with interpolation

dc42

@CCS86 I have put new 3.3beta firmware builds with finer G2/G3 segmentation at https://www.dropbox.com/sh/ian1cpllo0oexzy/AACLMSPaWhTXSrGcMieHT2uoa?dl=0.

_Domaa

@ccs86 Hello, i think i have a similar problem with printing smooth curves. Have you solved this problem, and if so, how? Thanks

CCS86

@_domaa said in Duet Maestro Struggling to Produce Smooth Curves:

@ccs86 Hello, i think i have a similar problem with printing smooth curves. Have you solved this problem, and if so, how? Thanks

I would suggest reading this whole thread. There is a lot of good info, not just one answer.