New beta firmware 1.20.1RC2 and DuetWiFiServer 1.20+1
-
There was a report earlier about DWC "layer X of Y" showing the wrong numbers for dual extrusion prints. I have a similar issue with the start (only) of a single layer print. At the end of this message, I'll include a link to the gcode file being referenced, but let me describe what is going on:
When the print starts (waiting for tools to heat), the DWC shows layer 0 of 111.
When the print moves to the part of the gcode that displays a message "Purging and Wiping T1", the DWC shows layer 2 of 111. This part of my startup code does two Z movements before moving on to the real print.
When the print moves on the build plate and actually starts printing the first layer (identified in the gcode with the comment "; layer 1, Z = 0.162"), DWC still shows "layer 2 of 111" and the head position Z is correctly noted as 0.16
When the print moves to the next layer (identified in the gcode with the comment "; layer 2, Z = 0.342"), DWC still shows "layer 2 of 111", and the head position Z is correctly noted as 0.34
Finally, when the print moves to the next layer (identified in the gcode with the comment "; layer 3, Z = 0.522"), DWC finally catches up showing "layer 3 of 111."
My WAG is that my startup gcode that does the "purge and wipe" is confusing the duet because of multiple Z moves up and down. However, if that's the case, I don't understand how it "catches up" at layer 3. If my guess is correct, is there something I can include in my gcode to let the duet know that "here is where the actual print starts, so reset the layer to 1"?
gcode file: https://drive.google.com/file/d/1MWXt1cxYU0ZMMG2RMMgH25-8_ynrjyHl/view?usp=sharing
Thanks
Gary -
Hi David, I think I have discovered why I am seeing underextrusion when I use M592 on my Kossel XL fitted with a flex3drive extruder. With A and B set to 0, the x/y motion and the extruder activity start/stop at the same time (as close as I can tell by eye/ear). When I set non-zero values (e.g A=0.015 and B=0.0012) I notice that the extruder stops before the x/y movement stops. The faster the feedrate, the more obvious the gap becomes.
Here's the relevant config lines:
[[language]] M350 I1 X16 Y16 Z16 E16 ; all axes use x16 microstepping with interpolation (steps/mm will get adjusted automatically) M92 X160 Y160 Z160 ; Set axis steps/mm (20 tooth pulleys, 0.9deg/step motors) M906 X1000 Y1000 Z1000 E1000 I60 ; Set motor currents (mA) M201 X3000 Y3000 Z3000 E400 ; Accelerations (mm/s^2) M203 X18000 Y18000 Z18000 E1200 ; Maximum speeds (mm/min) M566 X300 Y300 Z300 E10 ; Maximum instant speed changes M92 E4320 ; Set extruder steps per mm (flex3drive)Thanks, I look into it.
-
I found the problem. I'll get a new 1.20.1RC out soon with a fix.
-
A new 1.20.1RC would be most welcome!
-
Any chance of a new RC? I am keen to try out the fixed M592.
-
I am working through bug reports at the moment, trying to get some fixes implemented before I release it. However, there is a pre-release Duet Wifi build at https://www.dropbox.com/s/8pvnkzaf0hqxf7x/DuetWiFiFirmware.bin?dl=0.
-
Thanks, I'm trying it now…
-
Appears to work as expected, testing PETG at 240C, 0.4mm v6, flex3drive extruder. Preliminary results indicate A=0.05, B=0.004 work well up to 3.5mm/S. From 4mm/S upwards, compensation not really effective which doesn't surprise me as I've never been able to reliably get much more than approx 6 mm^3/S out of the v6. Will continue to test but it's looking good so far.
-
Thanks for the feedback. I have not tested whether increasing the spring tension on my Titan affects the amount of nonlinearity.
-
The flex3drive extruder doesn't appear to have any means of adjusting the "grip" - hasn't been a problem so far except for some TPU like stuff I have which is only 1.55 dia and so I have to add some packing to the over-centre lever otherwise the filament slips. The extruder works OK but it's a shame that it doesn't have any means of adjusting for filament diameters that aren't close to 1.75.
-
Done some prints with M592 active and they look very good. I believe the quality in terms of extrusion amounts has been improved. Here's a couple of images…
-
Discovered an interesting side effect of the non-linear extrusion - now that it doesn't underextrude (so much) at the higher extrusion rates, I found that a print using TPU like filament failed because the extrusion rate on a skin layer increased sufficiently to reach the throughput limit of the extruder/hotend combo. So a gcode file that had printed OK before, now doesn't print well. The solution was to reslice the part with a reduction in the speed at which the skin was being printed so that the throughput limit was no longer being reached.
-
I did not get my machine to reproduce the slowdown issue I posted about in another thread. However, after updating to this firmware and printing for the last 30 minutes I checked the diagnostics and got the following:
[[language]] SENDING:M122 === Diagnostics === Used output buffers: 1 of 32 (16 max) === Platform === RepRapFirmware for Duet WiFi version 1.21RC0+1 running on Duet WiFi 1.0 + DueX5 Board ID: 08D6M-91AST-L23S4-7JTD8-3S86K-1PX1K Static ram used: 15448 Dynamic ram used: 100464 Recycled dynamic ram: 2872 Stack ram used: 3584 current, 8472 maximum Never used ram: 3816 Last reset 00:57:06 ago, cause: software Last software reset at 2018-01-22 15:05, reason: User, spinning module GCodes, available RAM 3536 bytes (slot 0) Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 8 [ERROR] Error status: 8 Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 177.8ms MCU temperature: min 27.9, current 28.9, max 29.3 Supply voltage: min 24.3, current 24.6, max 25.1, under voltage events: 0, over voltage events: 0 Driver 0: ok, SG min/max 0/1023 Driver 1: ok, SG min/max 0/1023 Driver 2: standstill, SG min/max 0/624 Driver 3: ok, SG min/max 0/237 Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max 0/97 Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Expansion motor(s) stall indication: yes Date/time: 2018-01-22 16:02:33 Cache data hit count 4294967295 Slowest main loop (seconds): 0.179090; fastest: 0.000046 === Move === MaxReps: 4, StepErrors: 0, LaErrors: 0, FreeDm: 220, MinFreeDm 155, MaxWait: 4292717656ms, Underruns: 0, 0 Scheduled moves: 2116, completed moves: 2109 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.1 === GCodes === Segments left: 1 Stack records: 4 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 doing "G1 X318.756 Y289.891 E0.00223" in state(s) 0 serial is ready with "M122" 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 === Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.20+1 WiFi MAC address a0:20:a6:16:e6:c6 WiFi Vcc 3.26, reset reason Turned on by main processor WiFi flash size 4194304, free heap 16832 WiFi IP address 10.0.0.115 WiFi signal strength -38dBm, reconnections 0, sleep mode modem HTTP sessions: 1 of 8 Socket states: 0 0 0 0 0 0 0 0 Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
Can you provide a link to your post in the other thread?
-
Can you provide a link to your post in the other thread?
