Stuttering print, only on CW circles
-
@dc42 said in Stuttering print, only on CW circles:
I suspect that it is speed-dependent. For a given segment size, there is a maximum speed that can be maintained when there is a long sequence of vert short moves. Firmware 3.2beta2 and later can maintain higher speeds than earlier versions under some conditions.
Thank you. I have two basically identical printers that I've been upgrading to Duet. I have just a little work left to do on the second machine. Once I get the second wrapped up I'll start moving to the V3 firmware on one of them.
-
I tried adding P1 to the M566 line in my config.g.
Did not resolve the issue.That was an easy one to test - more in-depth testing will need to wait. Might be motivation to move to the V3 firmware sooner than later before I bang my head against the wall too much on this.
Thanks for the input.
-
@Veti said in Stuttering print, only on CW circles:
if the fragments are to small then this will cause a problem.
Is this because the STL model is too fine?
IIRC, there are way to simplify the STL model, when exporting the STL, with STL editors or with slicer's resolution settings.
-
@zapta said in Stuttering print, only on CW circles:
@Veti said in Stuttering print, only on CW circles:
if the fragments are to small then this will cause a problem.
Is this because the STL model is too fine?
IIRC, there are way to simplify the STL model, when exporting the STL, with STL editors or with slicer's resolution settings.
It does improve with a coarser STL export, but the fact that it only stutters when printing inner CW circles and not the outer CCW paths when the STL segments are identical lengths inside and outside the cylinder walls is what I find particularly baffling.
-
@zemlin said in Stuttering print, only on CW circles:
it only stutters when printing inner CW circles
Are both the inner and the outer circles of the same feature type from slicer's perspective? (outer perimeter, inner perimeter, infill, top, bottom, etc).
The slicer may set different parameters for different features. Also, you can look with an STL viewers at the triangles at both sides and see if you see any difference, e.g. with triangle density.
BTW, from the video, it looks as a high quality motion system, speed of movement, sound and such.
-
@zapta - yes - feature type is the same. Both inner perimeters and outer perimeters stutter. Only when printing the inside of the cylinder, not the outside.
-
Can you send M122 after a print and post the results?
-
8:33:49 PMM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet WiFi 1.02 or later
Board ID: 08DJM-9178L-L4MSN-6JKD0-3SJ6S-K93AQ
Used output buffers: 1 of 24 (11 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 93240 of which 0 recycled
Exception stack ram used: 448
Never used ram: 11672
Tasks: NETWORK(ready,628) HEAT(blocked,1176) MAIN(running,3760) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 02:01:13 ago, cause: software
Last software reset at 2020-12-07 18:32, reason: User, spinning module GCodes, available RAM 11728 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 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 51.8, current 52.9, max 53.9
Supply voltage: min 23.1, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/542
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2020-12-07 20:33:47
Cache data hit count 4294967295
Slowest loop: 156.72ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 79, MaxWait: 43293ms
Bed compensation in use: mesh, comp offset -0.016
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 172, 0
=== 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.4
=== 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: 15.32ms; fastest: 0.00ms
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.23
WiFi MAC address 84:0d:8e:b3:59:bd
WiFi Vcc 3.41, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24816
WiFi IP address 192.168.1.130
WiFi signal strength -63dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0 sensor: ok
- WiFi -
-
Can you share the stl and the sliced gcode file?
-
This post is deleted! -
@Phaedrux - gcode is 6MB and the forum doesn't allow zip files. Suggestions? Do I need to post it on drop box or something? What's up with no zip files?
GCODE: https://drive.google.com/file/d/1_aMcfSjBaq4Vxs93n-LVL8NGJz0dkshM/view?usp=sharing
There are 2 STL files in that print.
nafs600f28edvr2-sleeve-hk35.stl nafs600f28edvr2-ring-hk35-b.stl
-
Try another slicer. Simplify is generating a 6MB gcode file and PrusaSlicer with similar settings is 3MB.
-
@Phaedrux I have tried slicing my models with Cura, Prusa, and Ideamaker. The other components I run in these builds have extensive single-extrusion fill requirements. Only S3D produces the results I want on the fill - the other slicers won't do a continuous single extrusion fill in many of the layers.
I am printing lens hoods for large camera lenses, so numerous variants of the same basic design. I have printed dozens of sets without issue. Just once in a while I have an issue with the stuttering.
From what I had read on other threads, I though it would be related to bed mesh compensation, but I disabled the bed mesh yesterday and that didn't change the stuttering.
I was beginning to think it was machine related as I had only seen the stuttering on the N2+, not the N2, but I put the stuttering g-code on the N2 yesterday and it stuttered the same. That's good news from a troubleshooting standpoint because the machines are identical.
I've had to very nearly identical prints run - one that stuttered and one that didn't - same STL, same slicer, slightly different settings in the slice (like extruder multiplier, horizontal offset, part scaling - all very small tweaks between setups or material lots).
I might have to run some test prints stair-stepping some settings to see if I can force it to turn on and off on the same print job.
-
@zemlin said in Stuttering print, only on CW circles:
the other slicers won't do a continuous single extrusion fill in many of the layers.
I think prusa slicer should if thin wall detection and gap fill is enabled, though you might have to play with the extrusion width a bit.
Otherwise it would be interesting to see how 3.2 beta 4.1 handles it as suggesting by DC42 earlier.
There were no hiccups, you're not using high microstepping, and you've ruled out mesh compensation interacting with low z jerk.
-
Just this week I got both printers to a "finished" state with my upgrades and conversions. Needed to get to that point before potentially taking one down with a muffed update. Might be able to try that this weekend. Thanks for your insight.
-
For the update to RRF3, start with 3.0 and then 3.1.1. You can generate a RRF3 config set using the online tool and then compare to your existing config to add in anything custom. Once it's running you can update to the beta (or RC if it's out by then.)
-
With some help from the forum here I got one of my machines running 3.2 Beta4?
No change in the stuttering. Tried 566 P1, that doesn't have an impact either.
Update - found the 3.2.beta4.1, but since it was mentioned that anything after 3.2 would have the improved processing, not going to duplicate the tests unless you think it's worthwhile.
