Vertical banding on COREXY machine
-
@zabana
Finding the sweet spot between too slow and too fast is one step on the learning curve. And it can change, when you set different jerk settings. -
@o_lampe dont know but after more than 10 years printing I do prefer certain perimeters slow at 30 for quality printings
-
I had the same problem with artifacts in my prints. I found that even "higher grade" Bondtech drive gear clones sometimes have severe runout. Upgrading to genuine Bondtech gears solved the problem. They are really worth the price.
-Max
-
@maxgyver said in Vertical banding on COREXY machine:
drive gear clones sometimes have severe runout.
That's definitely worth looking for, but a runout wouldn't cause such fine lines. That would show up twice per turn of the drive gear.
With the right formula it would be possible to calculate where the problem is.
Microsteps, gear ratio, drivegear diameter, filament diameter, extrusion width, layer height vs. vertical line distance. -
@maxgyver that's something I am thinking about to buy, also ceramic bearings so the full setup will be top notch but I am afraid more money expended with same result as it was to purchase genuine LL gates idlers and pulleys
-
@o_lampe as time pass and the more test I do I am more convinced that thus is something related on how the firmware process small ammounts of filament extrusion and send the steps pulses to the stepper, because if the requested ammount to ve extruder is the same but faster seems to be ok or if the ammount to be extruded is higher due to 0.4 layer height instead 0.2
Maybe someone can give light about it... -
@zabana said in Vertical banding on COREXY machine:
@o_lampe as time pass and the more test I do I am more convinced that thus is something related on how the firmware process small ammounts of filament extrusion and send the steps pulses to the stepper, because if the requested ammount to ve extruder is the same but faster seems to be ok or if the ammount to be extruded is higher due to 0.4 layer height instead 0.2
Maybe someone can give light about it...Maybe inertia at high speed solving a lack of microstepping torque at slow speed?
-
@zabana
If it turns out, Klipper produces better results even without acceleration sensor/input shaper, it would be interesting to compare the e-step pulses on a scope. It can't be hardware related then, so it's in the code. Although @droftart confirmed, both FW use the same default settings for stealthchop: it's what you make of it...
Faster extrusion makes the driver change from stealthchop to spreadcycle mode and suddenly your result looks better...? Why can't we switch off stealthchop for extruders? -
@o_lampe said in Vertical banding on COREXY machine:
@zabana
If it turns out, Klipper produces better results even without acceleration sensor/input shaper, it would be interesting to compare the e-step pulses on a scope. It can't be hardware related then, so it's in the code. Although @droftart confirmed, both FW use the same default settings for stealthchop: it's what you make of it...
Faster extrusion makes the driver change from stealthchop to spreadcycle mode and suddenly your result looks better...? Why can't we switch off stealthchop for extruders?That would be very interesting. I'm suffering resonance at lowish speeds, and I wonder if there could me some slight mistimming in the step signals that klipper got better.
-
@o_lampe if I am right the duet wifi is not on stealth but in spread so if it does is not programmable or modificable.
This afternoon will try because just in case with absurd high jerks and accelerations on the extruder -
@o_lampe In this case (using a Duet WiFi) the drivers (TMC2660) do not support stealthchop so switching is not likely to be an issue.
What makes you think that you can't set an extruder driver to be in spreadcycle mode all of the time (on boards that have drivers that support both modes)? As far as I'm aware there is nothing to stop you using the D2 option to M569 with a driver that will be used as an extruder.
-
@gloomyandy
my remarks were about the various threads about vertical lines. Other users with Duet3 Mini have reported similar issues, so I thought it was worth mentioning.
It's good to know, that there's a way to modify driver settings. It's the first time someone mentioned it in this context. -
@zabana
They don't have to be absurd high, just enough so they aren't the bottleneck in the whole motion. -
@o_lampe yes, I know, and now they are good enough but because just in case I will try it but doesn't have too much espectation about it solving the problem.
-
Is that a self-made extruder design?
-
@phaedrux it is the sherpa mini but instead to print the original pieces I modded then to be integrated in the carriage instead to print separately and bolt it to the frame so the internal geometry and such is everything totally the same so that´s why it should work as well as any other sherpa mini.
-
Latest tests I did:
- Printed in 1/8 instead 1/32
- Disabled P.A
- Increased steps so in full steps is a round number of 44 instead 43.1825
- Increased jerk from 600 to 3600 and acceleration from 1000 to 3000
- Increased current from 750 to 1300.
- Normally my current line in config.g is M906 X1600.00 Y1600.00 Z1700.00 E700.00 I30 but tried without the I30
- Disabled M592 command
- Tried M593 F90.90 (there are 3 rippling per mm at 30mm/s so 30/0.33= 90.90)
I did each change separately and no one of them improved the print quality so everything the same.
I also noticed that at slow speed if I print a 40mm diameter cilinder (not vase mode) it doesn´t show the pattern so probably because the direction changes to draw the circle in each layer so the extruder works different than in a straigh line like in the cubes, if I print faster then it shows normal ringing due acceleration and deceleration. So maybe something related to any kind of ahead look planification in the lines printing? thinking_face:
-
I just tried now changing Jerk Policy to 1 with this command M566 X600.00 Y600.00 Z600.00 E600.00 P1 and it didn´t work neither...
Just in case it helps my M122 shows this:
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3RC2 (2021-05-11 14:55:01) running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F2MS4-7J1FA-3S46Q-THS0D
Used output buffers: 3 of 24 (20 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 75568 of which 0 recycled
Never used RAM 12116, free system stack 124 words
Tasks: NETWORK(ready,13.3%,211) HEAT(delaying,0.0%,330) Move(notifyWait,0.1%,277) DUEX(notifyWait,0.0%,24) MAIN(running,86.1%,445) IDLE(ready,0.5%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:01:01 ago, cause: software
Last software reset at 2021-06-02 21:53, reason: User, GCodes spinning, available RAM 11940, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 28.0, current 28.2, max 28.9
Supply voltage: min 23.1, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/12/0, gc cycles 0
Driver 0: position 74496, ok, SG min/max 0/123
Driver 1: position 18304, ok, SG min/max 0/121
Driver 2: position 663, ok, SG min/max 0/1023
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0, ok, SG min/max 0/38
Driver 6: position 0, standstill, SG min/max not available
Driver 7: position 0, standstill, SG min/max not available
Driver 8: position 0, standstill, SG min/max not available
Driver 9: position 0, standstill, SG min/max not available
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-06-02 21:54:27
Cache data hit count 2049737558
Slowest loop: 125.67ms; fastest: 0.16ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.0ms, write time 2.4ms, max retries 0
=== Move ===
DMs created 83, maxWait 40009ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 54, completed moves 48, hiccups 1, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 1
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) 3
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== DueX ===
Read count 1, 0.97 reads/min
=== Network ===
Slowest loop: 157.74ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address b4:e6:2d:53:14:72
WiFi Vcc 3.41, reset reason Power up
WiFi flash size 4194304, free heap 26136
WiFi IP address 192.168.1.41
WiFi signal strength -35dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
@zabana Remarkable.
I never would have thought doubling the printing speed would vastly IMPROVE a defect! But even these bad pictures show that. (I know, I've got ringing to deal with, but before it was hard to separate that from the stripes):
-
Maybe you're over extruding and at the higher speed the extruder can't keep up, so extrusion is reduced. Try the lower speed print with extrusion reduced.
