Vertical banding on COREXY machine
-
@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.
-
@mrehorstdmd It's not merely overextruded. The extrusion is periodic, like a sine wave. Even if overextruded, there shouldn't be periodic variation. I've played with extrusion and I've got it about perfect for PETG. My solid fill meets up with neither a ridge nor a valley (thought I think a difference in sheen is mostly my slicer). This is also the exact same pattern I've seen others have - all with Duet hardware.
As the contributor above mentioned, this uneven extrusion at low levels seems to be firmware-related, hence the improvement with layer height as well as speed, and the 100% improvement when people go to Klipper.
-
-
@donstauffer I wonder, if acceleration is done in "quanta", rather than smoothly (it almost has to - digital computers), could this be the incrementing of speed from acceleration being "out of phase" between extruder and XY? Imagine, extrusion increases, then speed, then extrusion, then speed, etc. You'd get a pulsing effect, in terms of extrusion per mm travel. Except then it would only happen when speed is changing, I guess. Well, just a thought.
-
@mrehorstdmd no, that's not the reason, if I were overextruding the perimeter will be higher than 0.4mm I set but consistent and that's not the point and also y speed is double or later height double should show another different issues.
-
@donstauffer I don't know, that's out of my knoledge. What I can say is I inspected the gcode file and the gcode for the cube sides is go from A to B extruding C ammount of plastic at F speed so the extruder has one only order to follow and the cilinder has small tiny segments to be printed in the same way, if I can this afternoon will try to print a cube of 20mm and another of 80mm to see if it vary something but I think it will not.
Maybe @dc42 can shed some light to this issue
-
@zabana This is problematic, because I can't do much about regular ringing without low acceleration, but I can't eliminate this banding without at least 1200 acceleration, I assume because lower accelerations slow down printing. My ringing is at around 60Hz, and DAA at that frequency reduces it, but it must lower acceleration too much because the banding returns. My jerk is already around 300, and any lower seems to mess up corners without improving ringing.
So right now, the best I can do seems to be to have moderate ringing (reasonably high acceleration), or mild ringing and moderate to severe banding (rather low acceleration). And I don't have the option I do on my other printer to slow printing down to get nice prints.
PA between 0.15 and 0.20 seems to have helped basic print quality at high speed, so that at least enables me to print fast so I have minimal banding. I just have to tolerate moderate ringing.
I have no ideas what else to try, except to consider Klipper.
-
@zabana I do think you misunderstood my conjecture, although it may be wrong anyway. I wasn't suggesting it was overextrusion. I was suggesting that rather than a simple pulsing of the extruder, it might be the extruder and XY movements leapfrogging each other. That would cause alternating over- and under-extrusion, but little or no average difference in extrusion.
-
@donstauffer I'm seeing this identical issue on my Railcore II also. Test cubes and such show "waviness" identical to the images @DonStauffer posted. LDO 0.9 steppers and duet2 wifi (my Railcore is a filastruder kit version of recent vintage). Oddly it only seems to happen on X and not on Y. I've hooked up an accelerometer and captured some data with the 3.3 beta and note the difference between an identical simple move in the X and Y direction:
X
Y
These were something like a 100mm move at 80mm/s. I see basically the same thing at 40mm/s also as I recall.
After trying many different mechanical tweaks, and looking at some other prusa forum posts Don had mentioned, I was thinking it's possible it is stepper based and will be trying some moons steppers to see if that smooths and improves anything. It certainly could be how the steppers are being driven by the duet2 as well, though, of course, something I hadn't considered.
A bit of a mystery is why X seems more affected.. both steppers are moving, just in different directions, for a pure X and pure Y move, right? That's why I was inclined originally to think it was a mechanical vibration issue with my X carriage or X rails or something, but all sorts of tweaks and changes to that didn't yield any real notable changes to the accelerometer data.. even being able to make it worse would be an indication that it was mechanical, but I haven't been able to really change things much with mechanical tweaks. I could be just not doing the right thing, of course... I'm a computer engineer so real-world physical hardware is not my forte
Fixing or at least improving this would make a big impact on my print quality, so quite interested in any possible solutions. I will do some experiments with higher speeds as well, that is interesting.
-
@skrotz In corexy, moving Y moves only 4 of the pulleys on the belts. Moving X moves all the pulleys. It is a larger mechanical load on the motors to move the extruder in X than it is to move in Y- try pushing it manually with the motors off and you'll see.
