[Solved] Curious wood grain pattern on Core XY prints

DigitalVision

I'm seeing very fine wood-grain like patterns on prints. It's pretty hard to spot and only visible on shiny filament with the light from the right direction.

Here's the bottom. The grains are almost but not quite aligned with the x axis (a few degrees off).

and the grains continue up the sides:

What's weird is that the grain pattern is dependent on the Z position. The pattern is not a spiral – it seems to behaves like volumetric slices. The pattern pitch angle is affected by the layer height but not by the extrusion width. I'm at loss explaining it. Any suggestions?

RCarlyle

What board (stepper drivers) and what settings are you running? Z probing?

You can get patterns like this with bed tilt compensation style autoleveling. Basically the printer varies Z height microstep by microstep across the print as a function of XY position based on the probe heights. You might see every microstep show up as a dislocation in the print if your Z steps/mm is really coarse, or you might see intermittent dislocations when you happen to hit a Z microstep that is difficult for the driver to output accurately. It’s like an aliasing error. It can make angled ripples if your layer height is not a multiple of full steps (not eg 16 or 32 or 160 microsteps with 1/16 stepping).

So that’s what comes to mind but I don’t know if it’s germane to your setup or not. Really need more info.

DigitalVision

Thanks Ryan! You nudged me to look deeper ~~and I just found out what it was.~~ It wasn't bed compensation. That was the first thing I suspected too, so I made sure to add both of these before the print. (In addition to never loading the bed compensation in the first place).

M376 H5 ; Taper off compensation by 5 mm
M561 ; Set identity transform

~~Instead the error seems to stem from a misfeature (bug?) in the version of Slic3r I'm using (some recent 1.3.1 build) affecting the Duet (2.02rc2) motion planner.~~ Looking at the gcode file Slic3r generated, it's full of gems like these:

G1 Z0.997 X131.038 Y90.666 E0.05308
G1 Z1.000 X132.006 Y89.051 E0.05144
G1 Z1.000 F9000.000
G1 F2487.1
G1 Z1.003 X133.195 Y87.439 E0.05471
G1 Z1.006 X134.499 Y85.999 E0.05308
G1 Z1.009 X135.939 Y84.695 E0.05308
G1 Z1.013 X137.500 Y83.537 E0.05308

and

G1 Z1.597 X131.038 Y90.666 E0.05308
G1 Z1.600 X132.006 Y89.051 E0.05144
G1 Z1.600 F9000.000
G1 X132.006 Y89.051 F9000.000
G1 F2487.11
G1 Z1.603 X133.195 Y87.439 E0.05471
G1 Z1.606 X134.499 Y85.999 E0.05308
G1 Z1.609 X135.939 Y84.695 E0.05308
G1 Z1.613 X137.500 Y83.537 E0.05308

~~Reslicing with Cura completely eliminates the issue.~~ @dc42, maybe worth considering filtering out zero moves in the planner?

dc42

The planner already filters out null moves. Are you sure that those moves generated by Slic3r are what is causing the problem?

sigxcpu

Why slic3r 1.3.1 instead of Prusa edition?

deckingman

@DigitalVision Were you using "Adaptive slicing" or "Match Horizontal Surfaces" ? If so, try turn them off. If not, just ignore this post.

DigitalVision

@dc42 said in Curious wood grain pattern on Core XY prints:

The planner already filters out null moves. Are you sure that those moves generated by Slic3r are what is causing the problem?

Sorry – I was completely off in blaming Slic3r. Operator error; turned out that I had scaled the cylinder object differently in Cura. Rescaling it in the same way replicates the same issue.

DigitalVision

@rcarlyle said in Curious wood grain pattern on Core XY prints:

What board (stepper drivers) and what settings are you running? Z probing?

Duet Wifi 1.04 (for the X,Y,Z1,E1,Z2 axes) + DueX2 0.8 (for the Z3 axis).

Motion related configuration:

M584 X0 Y1 Z2:4:5 U4 V5 E3                        ; Link the Z motors:  X = motor 0, Y = motor 1, Z = motor 2,4,5, E = motor 3

M92 X88.889 Y88.889 Z400 U400 V400 E96.3          ; Set steps per mm (assuming 16x microstepping)
M350 X64 Y64 Z256 U256 V256 E256 I0               ; Configure microstepping w/o interpolation
M92 U6400 V6400                                   ; UV aren't reset automatically...?

M906 X840 Y840 Z600 U600 V600 E1200 I30           ; Set motor currents (mA) and motor idle factor in per cent

M203 X24000 Y24000 Z1500 U1500 V1500 E4800        ; Set maximum speeds (mm/min)
M566 X1600 Y1600 Z50 U50 V50 E3600                ; Set maximum instantaneous speed changes (mm/min)
M201 X2000 Y2000 Z250 U250 V250 E3000             ; Set accelerations (mm/s^2)

M572 D0 S0.08 ; pressure advance extruder 0

@sigxcpu said in Curious wood grain pattern on Core XY prints:

Why slic3r 1.3.1 instead of Prusa edition?

Ignorance.

Phaedrux

@digitalvision said in Curious wood grain pattern on Core XY prints:

M350 X64 Y64 Z256 U256 V256 E256 I0

Try configuring your steps per mm and microstepping for 16x microsteps interpolated to 256.

I think you may be hitting a step rate limit on curved surfaces.

After a print if you run a M122 do you see hiccups or step errors?

bot

@dc42 said in Curious wood grain pattern on Core XY prints:

The planner already filters out null moves. Are you sure that those moves generated by Slic3r are what is causing the problem?

At what threshold does RRF filter the moves? Does it relate to the current steps/mm setting?

DigitalVision

@phaedrux said in Curious wood grain pattern on Core XY prints:

@digitalvision said in Curious wood grain pattern on Core XY prints:

M350 X64 Y64 Z256 U256 V256 E256 I0

Try configuring your steps per mm and microstepping for 16x microsteps interpolated to 256.

I think you may be hitting a step rate limit on curved surfaces.

After a print if you run a M122 do you see hiccups or step errors?

I changed all steppers to 16x stepping – kept interpolation disabled. Except for the printer being much noisier I couldn't see any difference. The grain patterns were identical. M122 output:

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC2(RTOS) running on Duet WiFi 1.02 or later + DueX2
Board ID: 08DGM-9T6BU-FG3SN-6J1D6-3S86Q-KAZHF
Used output buffers: 3 of 20 (20 max)
=== RTOS ===
Static ram: 28460
Dynamic ram: 98340 of which 0 recycled
Exception stack ram used: 508
Never used ram: 3764
Tasks: NETWORK(ready,408) HEAT(blocked,1192) MAIN(running,3484)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:12:49 ago, cause: software
Last software reset at 2018-10-06 15:43, reason: User, spinning module GCodes, available RAM 3988 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
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 34.5, current 35.1, max 36.2
Supply voltage: min 24.0, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/259
Driver 1: standstill, SG min/max 0/240
Driver 2: standstill, SG min/max 60/200
Driver 3: standstill, SG min/max 0/0
Driver 4: standstill, SG min/max 13/197
Driver 5: standstill, SG min/max 0/234
Driver 6: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 1970-01-01 00:00:00
Slowest loop: 131.22ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 127, MaxWait: 10ms, Underruns: 0, 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.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: 173.23ms; 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 Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16552
WiFi signal strength -51dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===
DueX I2C errors 0

Phaedrux

@digitalvision is that M122 from 16 microsteps or before?

Interpolation would deal with the noise.

DigitalVision

@phaedrux Yes, this M122 is with 16x microstepping. Same gain pattern as with the higher microstepping settings. Confirmed that interpolation eliminates the noise – I just wanted to see what raw 16x produced.

Phaedrux

@digitalvision what kind of extruder are you using? The only time I've seen similar surface artifacts was when a bearing had failed in my titan aero.

DigitalVision

It's a custom direct driven extruder. Mk7 drive gear directly on the stepper shaft, spring loaded bearing opposite for grip.

So I keep peeling the onion. Two prints:

P1: 0.2 mm layers, 0.4 mm extrusion width
P2: 0.15 mm layers, 0.5333 mm extrusion width

This should result in identical motion on X,Y,E axes, and slower motion on Z.

The grain pattern density increases by the corresponding amount (I count ~14 grain lines vs 10.5 grain lines) over the same Z distance at the same part of the prints.

So with this, the Z stage should be eliminated as a source.

Next,

P3: 0.2 mm layers, 0.6 mm extrusion width.

The extruder now runs 50 % faster than P1. Almost but not quite the same grain density. I count 9.5 rather than 10.5 grains. The grain patterns are still aligned with the X axis.

So the issue seems mostly (but possibly not entirely) unrelated to the E axis. Another variant:

P4: 0.3 mm extrusion width.

Now the extruder is running 25 % slower than P1. Identical pattern to P1 though.

For all three cases, P1, P3 and P4 the extruder runs at different speeds – but the grain pattern is still aligned with the X axis of the printer and is basically similar (P3 maybe slightly different).

If it were a bad bearing or similar in the extruder I would expect dramatic changes in the pattern when the extruder vs XY relative motion changes.

RCarlyle

You’ve turned off any kind of Z probing / autoleveling routines (including in override config file if you have one) right?

What happens if you print two objects side by side? Are the lines continuous across the objects (ie hold up a straightedge before taking them off the bed if you can)?

Is it more visible at higher print speeds or lower print speeds?

Phaedrux

Have you tried without pressure advance?
0.08 seems a little high for a direct drive extruder

DigitalVision

The issue is solved now. Thanks everyone for valuable input.

The fact that I got slightly different grain density between 0.6 and 0.4 mm extrusion width made me suspicious. Looking deeper at the grain patterns, comparing them side-by side, I found that they were not perfectly consistent print-to-print. This made me suspect something mechanical.

The other clue was the fact that the grain patterns changed not with Z, but with layer count. Basically, the shift happened every time the y axis moved. And what could mechanically gradually shift several centimeters over the duration of a print? I could think of only one thing. The recirculating balls in the linear bearings. So I took my y axis apart. The motion of the two bearings felt perfectly smooth when moved by hand, but I still took them apart, took all the balls out – cleaned them with mineral spirits and dried them with ethanol – and among the small pieces of dust and debris that came out of one was what looked like a tiny piece of aluminium shaving. Repackaged them with PTFE grease and issue solved.

@phaedrux said in Curious wood grain pattern on Core XY prints:

0.08 seems a little high for a direct drive extruder

I calibrated it using this technique: https://forum.duet3d.com/topic/6698/pressure-advance-calibration Really quick method to get the value dialed in accurately. (The only other thing I needed to do was to increase the default infill-to-perimeter overlap setting in my slicer, since you can no longer rely on blobbing at the end of long infill lines to fill in the gaps.)

@rcarlyle said in Curious wood grain pattern on Core XY prints:

Is it more visible at higher print speeds or lower print speeds?

Changing print speed made almost no difference at all.

T3P3Tony

@DigitalVision Thanks for the report on how you solved it., Just goes to show how many intersecting issues can cause these sorts of print artefacts.

RCarlyle

Pretty crazy that the debris shifted a consistent enough amount per layer to produce lines like that.