Duet Maestro Struggling to Produce Smooth Curves

Phaedrux

I'm no expert on this but it makes me think there is increased motor cogging torque at the higher speeds?

o_lampe

@Phaedrux
I'm no expert in steppers, but motors in general have the same max. torque until 50% of their max. RPM. Then the torque fades out. (This rule is for current limited drivers)
The cogging torque instead is a mechanical thing, not based on electric current, but magnetic attraction. Why would that grow at higher speeds, where instead inertia takes over?

@CCS86 My last straw are the linear bearings. Do you hear or feel any flat spot in the bearings or resonance at higher speeds? I watched the short video and couldn't hear anything except the fans.
I can highly recommend using IGUS Drylin linear bearings against the ball racing bearings.

gloomyandy

I notice you have the following for your steps/mm:
M92 X159.93 Y159.75 Z400.00 E510
that seems a little odd what are the actual mechanics of the X and Y axis?

What sort of results do you get with just a single wall is it the same? If you print a test and vary the motor current from lower to higher do you see any difference?

Argo

I'm also using the "rounding" feature of Supermerill's SuperSlicer.

My jerk settings are: 240 mm/min and
acceleration for external perimeter: 800mm/s
Print speed for external perimeter: 25 mm/s

The results are very clean with almost no ringing or artefacts, printing a round object made "rounder" with SuperSlicer.

Even if the preview in the Slicer looks round I don't think this translates 1:1 into gcode or the printer and if you print too fast you can still see artefacts.

Maybe it is possible in the future to have some sort of "logic" so the firmware detects a round objects and does not strictly follow the gcode but plans it own round path.

CCS86

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

I'm also using the "rounding" feature of Supermerill's SuperSlicer.

My jerk settings are: 240 mm/min and
acceleration for external perimeter: 800mm/s
Print speed for external perimeter: 25 mm/s

The results are very clean with almost no ringing or artefacts, printing a round object made "rounder" with SuperSlicer.

Even if the preview in the Slicer looks round I don't think this translates 1:1 into gcode or the printer and if you print too fast you can still see artefacts.

Maybe it is possible in the future to have some sort of "logic" so the firmware detects a round objects and does not strictly follow the gcode but plans it own round path.

Which setting are you talking about? There isn't one called "rounding". There is "model rounding precision". Or maybe you are talking about "curve smoothing"?

Either way, my results show that increasing the segment count in a curve (reducing the angular change at a segment junction) improves quality. It just seems like something about the RRF motion control is a bit too sensitive to these junctions. But printing G2/G3 arcs actually makes quality a bit worse.

Getting high quality at 25 mm/s is no problem. I'd like to expand that up to ~60mm/s for nice smooth curves.

CCS86

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

I notice you have the following for your steps/mm:
M92 X159.93 Y159.75 Z400.00 E510
that seems a little odd what are the actual mechanics of the X and Y axis?

What sort of results do you get with just a single wall is it the same? If you print a test and vary the motor current from lower to higher do you see any difference?

Are you talking about the difference in steps for X and Y? It's an Ultimaker motion system, so rotation is converted to linear motion of the print head by GT2 pulleys. They have tolerances like everything else, so small changes in the pulley diameter can cause slight differences like this. It's only 0.1% different, but it makes for more accurate prints.

1 wall prints are the same. I started doing them in 2 and 3 wall to make sure it wasn't the actual print oscillating.

I like the idea of varying motor current. I'll probably give that a try too.

Argo

@CCS86

Yep curve smoothing. Wasn't on my computer when posting so I couldn't look up the exact name of the feature.

Can you print nice round objects with Marlin 2? The results at 60 mm/s look pretty much the same with my SKR 1.4 and Marlin 2. I don't think it's a problem of RRF.

CCS86

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

@Phaedrux
I'm no expert in steppers, but motors in general have the same max. torque until 50% of their max. RPM. Then the torque fades out. (This rule is for current limited drivers)
The cogging torque instead is a mechanical thing, not based on electric current, but magnetic attraction. Why would that grow at higher speeds, where instead inertia takes over?

@CCS86 My last straw are the linear bearings. Do you hear or feel any flat spot in the bearings or resonance at higher speeds? I watched the short video and couldn't hear anything except the fans.
I can highly recommend using IGUS Drylin linear bearings against the ball racing bearings.

The linear bearings seem to be in great shape. I have checked them individually. I think that if I had issues with bearings: 1) I would see them even during straight wall sections (I don't), and 2) the artifacts wouldn't be so perfectly spaced

CCS86

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

@CCS86

Yep curve smoothing. Wasn't on my computer when posting so I couldn't look up the exact name of the feature.

Can you print nice round objects with Marlin 2? The results at 60 mm/s look pretty much the same with my SKR 1.4 and Marlin 2. I don't think it's a problem of RRF.

I haven't printed with Marlin 2 in a long time, so I couldn't say.

Curve smoothing seems to be mainly for improving low resolution STLs. The vast majority of my prints are from my own designs, so I can output them at whatever resolution I need.

CCS86

I really want to make sure my stepper motors themselves and configuration aren't holding me back.

There are 2-phase motors, yes? Does that mean that they are rated for 4 amps in the same context as this recommendation, or it is just an accident that it looks like "amps per phase"?

Duet 2 Maestro (recommended maximum motor current 1.4A RMS with good fan cooling) => Stepper motor rated current <= 1.7A. Hower, if you use motors with lower rated current (e.g. 1.0 to 1.2A) and 24V power, then the drivers will run cooler.

I am running at 24v, and have them in Spreadcycle mode because the Stealthchop switch is pretty ugly.

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!