Problem printing circles
-
I have a problem I have not noticed before. It was always present, but I did not print circles except for the M3 holes. So I did not notice.
Anyway, if it not seen from the video, on the big circle printer keeps speeding and slowing. It is choppy.
And the weird thing is, there is a pattern in the circles. I get 3, 4, 5, 2, 5, 4 lines.
My config is here (fresh), I also attached the gcode file
Here is a octagon, so I could test straight lines, as you can see it works perfectly. Ignore the ugly print.
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta2(RTOS) running on Duet WiFi 1.02 or later Board ID: 08DGM-956GU-DJMSN-6J9F4-3SD6M-1VR3G Used output buffers: 3 of 20 (16 max) === RTOS === Static ram: 28484 Dynamic ram: 96032 of which 0 recycled Exception stack ram used: 420 Never used ram: 6136 Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3616) Owned mutexes: === Platform === Last reset 00:41:35 ago, cause: software Last software reset at 2018-07-16 21:09, reason: User, spinning module GCodes, available RAM 6208 bytes (slot 1) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 42.9, current 43.2, max 44.2 Supply voltage: min 12.4, current 12.6, max 12.8, under voltage events: 0, over voltage events: 0 Driver 0: standstill, SG min/max 0/383 Driver 1: standstill, SG min/max 0/458 Driver 2: standstill, SG min/max 0/652 Driver 3: standstill, SG min/max 0/524 Driver 4: standstill, SG min/max not available Date/time: 2018-07-16 21:51:26 Slowest loop: 101.17ms; fastest: 0.08ms === Move === Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 150, MaxWait: 0ms, Underruns: 695, 1 Scheduled moves: 0, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.5 === GCodes === Segments left: 0 Stack records: 2 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 172.91ms; fastest: 0.08ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.21 WiFi MAC address 5c:cf:7f:76:5f:98 WiFi Vcc 3.33, reset reason Turned on by main processor WiFi flash size 4194304, free heap 15296 WiFi IP address 192.168.1.119 WiFi signal strength -38dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0 === Expansion === Test gcode: https://www.dropbox.com/s/hfvgd5zj1sb30em/Cylinder test.gcode?dl=0
Stl: https://www.dropbox.com/s/hkadyoitr26z2r4/Cylinder test.stl?dl=0 -
I have noticed similar surface quality on circles and smooth arcs but don't get the same exaggerated pause behaviour as seen in your video. I'll try printing your STL and see if I can duplicate it.
Can you post your config.g?
Are you using pressure advance? -
Config.g is in the end of the post.
No pressure advance, I was trying it, but I didn't manage to dial it in.
The worst was on the big circle. And stl was prepared for 0,4mm nozzle, walls are 0,45mm thick.
I just realized, I gave too little information. Printer is cartestian with steel frame, motors are supposed to be these: https://3dprint.wiki/reprap/anet/a8/steppermotor and the board is version 1.03
And I put the octagon and square in so I could see if I have the same problems on them, I guess that would mean that it's not a problem with the board. -
@phaedrux I also checked the pressure advance @OBELIKS posted his config at the bottom of his post, no pressure advance enabled (thought thar as well after @deckingman's experiences
-
Just a quick thought, is there any buffers or cache that can be flushed?
-
I once had a similar problem with another board and it was too little jerk. The circles came out exactly like yours. I’m not surr it’s the same problem, but increasing the jerk value solve the issue.
-
@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?
-
@obeliks Sorry about that, I think the string of numbers made me glaze over that link.
-
I just looked at your config.g and I don’t think low jerk values are your problem. I think I’m using the same values...
-
I assume you are printing from SD card. The usual reason for this type of issue is that the XY jerk is set too low for the print speed.
-
@t3p3tony I will try Cura tomorrow. I don't like setting it up, but I will try. But I know that S3D gives more or less the same results. It's a bit annoying, that the old Anet board gave me no problems like that. But I hope we can get this sorted out.
-
-
@dc42 I actually went from 20mm/s to 15mm/s just to check. It is also true that it was even worse with my old configuration (I havent stored it. I will check, but I think it is gone). Then the circles were flat on top and bottom.
What jerk setting would you suggest? -
@obeliks said in Problem printing circles:
@dc42 I actually went from 20mm/s to 15mm/s just to check. It is also true that it was even worse with my old configuration (I havent stored it. I will check, but I think it is gone). Then the circles were flat on top and bottom.
What jerk setting would you suggest?The default value of 600mm/min works well for many users, but some users increase it to 900 or even higher.
-
I have them at 900 st the moment. I will make a test tomorrow with 1200 and 600, so we can see the difference. And with Cura.
-
@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.
-
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. -
@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?
-
No.
I will try this also. But this should work from gcode console also? -
@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.