Problem printing circles

deckingman

@t3p3tony said in Problem printing circles:
...................

quite small moves

Can you try using another Slicer as a test to see what difference it makes? I note this is Slic3r Prusa edition version 1.40.1, so maybe try Cura to see the difference?

@deckingman I know there is no pressure advance involved but is this related to the issues you are seeing?

There are certain similarities for sure - although I only see it with pressure advance enabled. I've discovered that increasing extruder micro-stepping to 256x from 16x is a work around for my issue, so it would be interesting to know if doing the same has any effect on the OP's problem.

OBELIKS

That is another thing that I have problems with. If I try to give command "M350 X256 Y256 Z256 E256 I0" I get something like "Drive E0 does not support 256 microstepping"
I will try this and the rest when I get home from work.

deckingman

@obeliks said in Problem printing circles:

That is another thing that I have problems with. If I try to give command "M350 X256 Y256 Z256 E256 I0" I get something like "Drive E0 does not support 256 microstepping"
I will try this and the rest when I get home from work.

That's weird, but try this. Leave everything in your config.g as is but add M350 E256 at the end of your drive section (after the M84 command). This will mean that the steps per mm are first calculated using 16x microstepping, then when you add that line, the micro-stepping will be changed x 256 and the steps per mm for "E" will be automatically recalculated.

You're not using external stepper drivers are you?

OBELIKS

No.
I will try this also. But this should work from gcode console also?

Catalin_RO

@dc42 RRF configurator default max jerk is 15mm/s, hence 900mm/min! Maybe 600mm/min is the default firmware value, but any config.g file generated with the configurator will have it overridden. I'm going to experiment a little bit with the idea, by increasing from the current 300mm/min in 50mm/min steps.

deckingman

@obeliks said in Problem printing circles:

No.
I will try this also. But this should work from gcode console also?

Yes

OBELIKS

@deckingman said in Problem printing circles:

@obeliks said in Problem printing circles:

That is another thing that I have problems with. If I try to give command "M350 X256 Y256 Z256 E256 I0" I get something like "Drive E0 does not support 256 microstepping"
I will try this and the rest when I get home from work.

That's weird, but try this. Leave everything in your config.g as is but add M350 E256 at the end of your drive section (after the M84 command). This will mean that the steps per mm are first calculated using 16x microstepping, then when you add that line, the micro-stepping will be changed x 256 and the steps per mm for "E" will be automatically recalculated.

You're not using external stepper drivers are you?

So first this one, as I said, if I put this in to G-Code Console, I get this error (bug?):

M350 E256
Error: M350: Drive E8 does not support 256x microstepping

But it works if I put it in to config.g exactly as you suggested:

M350
Microstepping - X:16(on), Y:16(on), Z:16(on), E:256:256:16:16:16:16:16:16:16

The result was slightly better. But there were still audible judder.
Setting them all to x256 also did not help more.

Setting jerk to 1200 or even 1800 makes no real difference.

I will test Cura later

deckingman

@obeliks said in Problem printing circles:

So first this one, as I said, if I put this in to G-Code Console, I get this error (bug?):
M350 E256
Error: M350: Drive E8 does not support 256x microstepping
But it works if I put it in to config.g exactly as you suggested:
M350
Microstepping - X:16(on), Y:16(on), Z:16(on), E:256:256:16:16:16:16:16:16:16

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

That error message does rather look a bit like a bug as you don't have a drive E8. Anyway, it doesn't seem to have resolved your problem but it was worth a try.

DocTrucker

Similar issue to something I experienced. Tested with and without pressure advance and as was and increased Jerk. Increased jerk smoothed things out, pressure advance had comparitively little effect.

https://forum.duet3d.com/topic/5834/core-xy-judder-slowdown-on-circle/18

OBELIKS

Before I waste any more of our time, is there any option to make a fresh start on the board?
Would the erase button do that?

JoergS5

@obeliks Erase is not good, because you erase the firmware. You should update your config files with your original files which you created with your online configurator. Through DWC.

OBELIKS

Someday I will try the nuclear option, and I will push the erase button.
But for now I found a workaround, if anybody else has these problems.
In Slic3r go to Print settings -> Advanced and under resolution put in 0.1mm.
I will do some more tests, but this cured the problem.
Mostly. Printer runs smoother, but there is still some ringing on circles.
So I would like to see a better solution someday.

And just to be clear,

Jerk settings were at 1200mm/min at start, I then lowered them to 900mm/min to check, and later even went to 1800mm/min. This did nothing.
I changed microstepping to x256, this helped a bit, but not enough.
Cura seems to do OK, but I do not like it. I will try to set it up.
I generated and uploaded config from the configurator a couple of times, no difference.

If you have any more ideas besides that, please tell me. I will also try with a different SD card, just to eliminate this from the list of possible problems.

But from my observations, DuetWifi just can't handle the Slic3r files with full resolution. At least for me. It looked like it needed some time to catch up with what was passed on. That is also the reason I was thinking of erasing the whole firmware. Maybe something was not uploaded right.

deckingman

@obeliks said in Problem printing circles:
..............................

But for now I found a workaround, if anybody else has these problems.
In Slic3r go to Print settings -> Advanced and under resolution put in 0.1mm.
I will do some more tests, but this cured the problem.
Mostly. Printer runs smoother, but there is still some ringing on circles.
So I would like to see a better solution someday.
....................................

But from my observations, DuetWifi just can't handle the Slic3r files with full resolution..................................

Now that is a very interesting observation. Maybe, just maybe, it might also explain the problems I've been having with curves and pressure advance. I'm stuck in the middle of something that prevents me doing any printing right now but I'll try this at the first opportunity. I haven't played around with the resolution option with Slic3R, leaving it set to the default 0 which effectively disables any simplification. For anyone else not familiar with slic3r, the pop up description of the resolution option in slic3r is quote:

"Minimum detail resolution, used to simplify the input file for speeding up the slicing job and educing memory usage. High-resolution models often carry more detail than printers can render. Set to zero to disable any simplification and use full resolution for input. (default: 0)."

End of quote.

Strange choice of words in that quote...........

OBELIKS

Oh, for f... sake. The initial problem that was the reason I went in to this is still here:
alt text

As you can see, the circles, well they are not exactly circles.

Is there any chance that this could be a problem with steppers?
I will need to revert to the old board to test that, and I do not have the time and energy for that at the moment.

And I am really sorry about the amount of messages I put out. When I get annoyed I tend to do that. At leas online.

@deckingman See here: http://manual.slic3r.org/topics/draft-quality They consider 0.05 and 0.1 draft quality.

burtoogle

@t3p3tony said in Problem printing circles:

@obeliks there is a print buffer of moves during printing as the firmware needs to know what the next move is. That made me think about if the issue is related to having very many very short moves. so i looked at the gcode. There are loads of sections like this:
G1 X159.018 Y101.352 E0.16013
G1 X159.019 Y101.357 E0.00036
G1 X159.020 Y101.362 E0.00036
G1 X159.348 Y103.498 E0.16013
G1 X159.349 Y103.503 E0.00036
G1 X159.350 Y103.508 E0.00036
G1 X159.528 Y105.136 E0.12129
G1 X159.585 Y105.657 E0.03882
G1 X159.586 Y105.662 E0.00036
G1 X159.586 Y105.667 E0.00036
G1 X159.727 Y107.824 E0.16012
G1 X159.728 Y107.829 E0.00036
G1 X159.728 Y107.834 E0.00036
G1 X159.775 Y109.995 E0.16012
G1 X159.775 Y110.000 E0.00036
G1 X159.775 Y110.005 E0.00036
G1 X159.728 Y112.166 E0.16012
G1 X159.728 Y112.171 E0.00036
G1 X159.727 Y112.176 E0.00036
G1 X159.620 Y113.805 E0.12092
quite small moves

Can you try using another Slicer as a test to see what difference it makes? I note this is Slic3r Prusa edition version 1.40.1, so maybe try Cura to see the difference?

@deckingman I know there is no pressure advance involved but is this related to the issues you are seeing?

The config.g posted earlier shows 425 steps/mm for the extruder but a lot of the extrusions in the gcode snippet above require less than 1 step so they will probably just get omitted. This would lead to poor surface finish for that sequence of lines.

deckingman

@burtoogle said in Problem printing circles:

The config.g posted earlier shows 425 steps/mm for the extruder but a lot of the extrusions in the gcode snippet above require less than 1 step so they will probably just get omitted. This would lead to poor surface finish for that sequence of lines.

Good spot. But if you look at the X and Y moves, these too are bu**er all so it's very tiny segments being generated, not just extruder moves. Maybe such tiny segments make the firmware pause for thought? Having said, the OP thought changing the slicer resolution had fixed his problem but now it seems it hasn't......

OBELIKS

It fixed the problem with pauses, the accuracy is still to be researched.
And printer still sounds rough.

dc42

@obeliks said in Problem printing circles:

So first this one, as I said, if I put this in to G-Code Console, I get this error (bug?):
M350 E256
Error: M350: Drive E8 does not support 256x microstepping

Unless you have used M584 to limit the number of extruder drives, you have an E8 drive implicitly. By default it will be mapped to driver 10, which is on the CONN_LCD connector and therefore assumed to be a dumb step/dir/enable driver.

The command M350 E256 means set all extruder drives to x256, hence the error message. Use e.g. M350 E256:256 to set just E0 and E1 to x256.

Phaedrux

Just going through your slic3r profile and slicing the stl and noticed you have some layer change gcode.

; before_layer_gcode = ;BEFORE_LAYER_CHANGE\nG92 E0.0\n;[layer_z]\n\n

Is there a reason you'd want to reset your extruder distance each layer? Is that normal?

Phaedrux

You're also trying to extrude a single wall 0.45 wide into a wall less than that, you have detect thin walls enabled, which is compensating for it by chopping up the extrusions, hence the tiny moves. If you turn off detect thin walls you see in the preview that it's basically unprintable and has bits and pieces all over the place. If you explicitly set your extrusion width to 0.4 and disable detect thin walls it slices properly. I think that will solve your jerky movement.