Sounds like operator error!
I could have sworn in the past, I had to upload a 3rd file when upgrading RRF and DWC. I thought it was DSF, but must have been something else.
Sounds like operator error!
I could have sworn in the past, I had to upload a 3rd file when upgrading RRF and DWC. I thought it was DSF, but must have been something else.
Maestro. No SBC.
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.5.1 (2024-04-19 14:40:37) running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LLMS4-7J9F6-3SN6Q-KBM2Q
Used output buffers: 1 of 26 (22 max)
=== RTOS ===
Static ram: 23480
Dynamic ram: 67060 of which 0 recycled
Never used RAM 22236, free system stack 178 words
Tasks: NETWORK(1,ready,26.2%,202) ACCEL(6,nWait 5,0.0%,345) HEAT(3,nWait 5,0.1%,338) Move(4,nWait 5,0.0%,310) TMC(4,nWait 5,1.8%,109) MAIN(1,running,64.3%,791) IDLE(0,ready,7.7%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:35:22 ago, cause: software
Last software reset at 2023-06-16 21:25, reason: User, Gcodes spinning, available RAM 17184, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 39.2, current 40.7, max 41.1
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/224/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, read errors 0, write errors 1, ifcnt 22, reads 26058, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, read errors 0, write errors 1, ifcnt 22, reads 26058, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, read errors 0, write errors 1, ifcnt 22, reads 26058, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, read errors 0, write errors 1, ifcnt 17, reads 26061, writes 6, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, read errors 0, write errors 1, ifcnt 13, reads 26061, writes 6, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2024-04-19 13:19:01
Slowest loop: 475.41ms; fastest: 0.19ms
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: 15.0MBytes/sec
SD card longest read time 2.2ms, write time 96.0ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 1895171ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 4, maybepossible 0
=== DDARing 0 ===
Scheduled moves 10, completed 10, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1, chamber heaters -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "M190 R60" in state(s) 0
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
Q0 segments left 0
Code queue 0 is empty
=== Filament sensors ===
check 340708 clear 5979184
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 1020.20ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex
Socket states: 1 5 5 2 2 2
I am trying to upgrade from 3.5.0b4 to 3.5.1, and have already gotten the firmware and DWC installed on my Maestro.
But, every time I try to upload the DSF, it fails on this file:
Failed to upload DuetControlServer.SPI.Communication.FirmwareRequests.AbortFileHeader.html
Your Duet rejected the HTTP request: could not create file
I'm actually not even sure if this is a requisite installation.
@dc42 is this just not going to be explored?
I put my g-code resolution back to the default value and it started generating arcs. It only does it on external perimeters though. So artifacts from linear segmented inner walls can still print through.
But again, for the sake of our discussion, until RRF allows true arc support, the quality with G2/G3 is worse than without.
@MJLew said in Progress on Path Smoothing / Lookahead?:
@CCS86 We do not need to argue about this. Fitting arcs will take longer than not fitting arcs, but there are some (many, probably) use-cases and examples where the time difference is trivial. Your experience is vast and your opinion is valid, but it is quite likely that I also have relevant experience.
It's called a discussion, not an argument. That's the whole purpose of this forum.
If you have relevant experience that leads you to a different conclusion, let's hear it. Just saying that you "likely... Have relevant experience" isn't very compelling.
@MJLew said in Progress on Path Smoothing / Lookahead?:
@CCS86 Well, all I can say is that the latest PrusaSlicer has arc fitting and it seems to slice as fast with it active as it does without on my Mac M1.
Have you looked at the code?
It's easy to go fast when you don't actually fit arcs.
Plus, even when successfully fitting arcs, they inject some variability into the wall surface. You can see something similar if you make the slicing resolution more coarse.
@MJLew said in Progress on Path Smoothing / Lookahead?:
@CCS86 I disagree too, but it is with you I disagree. With modern computers there is no substantial penalty for things that used to be computationally demanding.
If the RepRap firmware uses segments of 1.2mm for an arc of diameter 20mm then the formula for segment lengths is faulty! I have a routine for changing arcs to G1 sequences that I made to accommodate my then new PrusaMK4 which ignored the Z parameter of G2 and G3 commands (now fixed). I found good results for a wide range of radii with the formula of 6*(r+1)^1.5 where r is the radius in mm. That formula gives a segment length of just under 0.3mm for a 20mm diameter. It is easily modified if that is too large.
I'll look at the thread that you linked.
Disagree all you want but proper arc fitting can take a long time, even with powerful modern computers. That is a penalty to the user.
I run a high tech CNC manufacturing facility. I have half million dollar machines that chew through linearly segmented code and produce super smooth motion. Arc filtering everything is not the answer on the highest end CNC machining, and it for sure is not the answer for 3D printers.
@droftarts said in Progress on Path Smoothing / Lookahead?:
@CCS86 this sounds like a slicer problem to me, and reading the paper you linked only reinforces that view to me, ie it’s time to ditch stl and use a proper geometry, eg step, for slicing, to produce G2/3/5 moves (though there is an issue with G5 and 3D printing). Then improve the firmware on those gcodes to the point where microstep-accurate arcs are drawn - I believe RRF splits arcs into 0.1mm straight line segments currently.
Ian
I disagree.
Even in the world of very expensive CAM software packages, "arc fitting" / "arc filtering", or the post processing of linear segmented g-code into arcs, is limited and not applicable to all paths. To expect all these freeware slicers to adopt something that such expensive and advanced software doesn't always do, and is computationally very demanding, is unrealistic.
What is very common and very reliable, as outlined in that paper, is for the NC motion controller to smooth junctions with allowable deviation, to create smooth, continuous motion. Many even have configurable settings to allow the balance between speed and accuracy to be tuned for the current operation.
For RRF arc support, the 0.1mm segment is only the minimum length. In this thread we discussed the formula and for a cylinder of 20mm in diameter, I was getting linear segments of 1.2mm, which is giant compared to what I can achieve with a fine STL and good slicer settings: https://forum.duet3d.com/topic/21825/duet-maestro-struggling-to-produce-smooth-curves/27
@deckingman why are you taking this so personally?
You seemed to be suggesting that low jerk could be used generally. I pointed out that your test was very specific an not representative of general printing. Not sure why that would offend you.
@gloomyandy said in Progress on Path Smoothing / Lookahead?:
@CCS86 Do you have any examples of controllers that implement or papers describing the sort of move smoothing you are asking for here? RRF already performs a fair degree of lookahead, but expecting it to be able to recognise "small loops" or other features seems like something better suited to a slicer or other preprosessor to me.
This has nothing to do with "small loops". We are talking about locally smoothing the junctions of linear segments to allow smooth motion.
https://www.sciencedirect.com/science/article/abs/pii/S089069551630493X
That's one very specific case you tested.
80 mm/s is relatively slow and on a large arc at a slow speed, of course you can reduce jerk significantly, with a finely faceted model.
Things will be different with higher speeds and smaller arcs. All sorts of real world printing scenarios that need to be balanced.
Your point about motor steps being linear is really a moot point. Every CNC machine has a minimum increment of movement, including the most precise, like a wire EDM. These increments are so small, that practically, they are invisible on the finished part. In our application, the issue is with large linear segments interrupting the motion controller's flow. By looking ahead, we can start the change in axis movement speed ahead of the junction, so there isn't such a reliance on jerk, creating much smoother motion.
The fact that printing curves composed of linear segments requires moderately high jerk, but input shaping is somewhat defeated by jerk, is the reason that the real path forward is by using look-ahead / path smoothing, as I asked about here:
https://forum.duet3d.com/topic/32942/progress-on-path-smoothing-lookahead
So, get in there and voice your support.
The only other approach that would work is to have true arc support (RRF just decomposes arcs into relatively coarse linear segments, currently), and reliable arc fitting in the slicer (none that I am aware of, currently).
I was really hopeful for the IS improvements in RC1, but I had a definite reduction in print quality and rolled back. Applying IS to short segments is very important in my eyes, but there are kinks to work out.
That makes sense guys.
I was asking more for the visualization aspect with the DWC plugin, as opposed to using it for mesh leveling.
@gloomyandy said in 3.5.0-RC1: Major Issue with Skipped Steps:
@CCS86 Are you running input shaping? If so try disabling it and see if that makes any difference. Also capturing and posting the output from M122 after a failed print might provide some more information.
Yes, I am running IS.
I'm not sure when I will get a chance to test again, as I run pretty steady production on this machine.
This is a Maestro board.
I'm not sure when I will get a chance to test again, as I run pretty steady production on this machine.
After flashing RC1 on my Maestro and trying a few simple test prints, I did my first actual print last night and it didn't go well. This is a print file I have used many times before.
I heard some strange noises and went to check on the print. Here is what I saw:
I flashed back to B4, made no other changes, and got the successful print behind.
; Configuration file for Duet Maestro
; Drives
M569 P0 S0 ; drive 0 goes backwards
M569 P1 S1 ; drive 1 goes forwards
M569 P2 S0 ; drive 2 goes backwards
M569 P3 S0 ; drive 3 goes backwards
M569 P0 D2 ;D3 V468 ; X Stealthchop2 till about 10 mm/sec
M569 P1 D2 ;D3 V468 ; Y Stealthchop2 till about 10 mm/sec
M569 P2 D3 V40 ; Z Stealthchop2 till about 46.9 mm/sec
M569 P3 D2 ; Extruder in Spreadcyle
M584 X1 Y0 Z2 E3 ; Drive mapping
M92 X160.0 Y160.0 Z401.5 E727 ;E695 ; Steps per mm
M350 X16 Y16 Z16 E16 I1 ; Microstepping with interpolation
M201 X8000.00 Y8000.00 Z230.00 E2500.00 ; Max accelerations (mm/s^2)
M203 X18000.00 Y18000.00 Z2100.00 E3000.00 ; Max speeds (mm/min)
M204 P2500 T8000 ; Accelerations (mm/s^2)
;M205 X8.55 Y8.55 Z3 E4.5 ; Maximum jerk rates (mm/s)
M566 X513 Y513 Z180.0 E300 P1 ; Maximum jerk rates (mm/min)
;M593 P"ZVD" F75
;M593 P"MZV" F37
if !exists(global.IS_freq)
global IS_freq=75 ; Input Shaping Frequency
if !exists(global.IS_type)
global IS_type="ZVD" ; Input Shaping Type
M593 P{global.IS_type} F{global.IS_freq} S0.04 ; Input Shaping
M572 D0 S0.030 ; Pressure Advance
M906 X1500 Y1500 Z1400 E420 I50 ; Motor currents (mA) and motor idle factor
M84 S30 ; Idle timeout
; Axis Limits
M208 X0 Y0 Z0 S1 ; Axis minima
M208 X195 Y180 Z220 S0 ; Axis maxima
;Filament Sensor
M591 D0 P1 C"e0stop" S1 ; presence sensor connected to E0 endstop for drive 0, enabled
;M950 J1 C"e0stop" ; define logical input for filament auto load
;M581 P1 T2 S0 R0 ; define trigger for filament auto load triggers trigger2.g
M950 J2 C"e1stop" ; define logical input for filament unload
M581 P2 T3 S0 R0 ; define trigger for filament auto load triggers trigger3.g
; Endstops
M574 X1 S1 P"!xstop" ; Active-high endstop for low end on X via pin !xstop
M574 Y1 S1 P"!ystop" ; Active-high endstop for low end on Y via pin !ystop
; Z-Probe
M574 Z1 S2 ; Z endstop controlled by probe
M558 P5 C"^zprobe.in" H5 F500 T6000 A1 ; Z probe type to bltouch and the dive height + speeds
M950 S0 C"zprobe.mod" ; create servo pin 0 for BLTouch
G31 P25 X19 Y-14 Z.92 ; Z probe trigger value, offset and trigger height
;X20 Y-7.33 Z2.17
;X14 Y-18.5 Z2.13
;X12 Y-18.0 Z2.37
M557 X19:195 Y0:166 S18.8 ; define mesh grid
M376 H1.5 ; mesh taper
;Accelerometer
M955 P0 C"twck0+twd0" R12
; Heaters
M308 S0 P"spi.cs1" Y"rtd-max31865" ; configure sensor 0 as a PT100 sensor in the first position on the Duet 2 daughter board connector
M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M143 H0 S120 ; set temperature limit for bed heater 0
M308 S1 P"e0temp" Y"pt1000" ;T100000 B4725 C7.06e-8 ; configure sensor 1 as PT1000 on pin e0temp
M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S260 ; set temperature limit for nozzle heater 1
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M308 S2 Y"drivers" A"DRIVERS" ; configure sensor 2 as temperature warning and overheat flags on the TMC2660 on Duet
M308 S3 Y"mcu-temp" A"MCU" ; configure sensor 3 as thermistor on pin e1temp for left stepper
; Heater model parameters
;Bed
;M307 H0 R0.194 C896.8 D2.07 S1.00
;M307 H0 R0.190 K0.196:0.000 D2.03 E1.35 S1.00 B0
M307 H0 R0.190 K0.174:0.000 D1.95 E1.35 S1.00 B0
;Hotend
;M307 H1 R2.523 C231.0:134.5 D5.90 S1.00 V24.3
;M307 H1 R2.324 K0.389:0.146 D3.76 E1.35 S1.00 B0 V24.3
M307 H1 R2.459 K0.398:0.160 D3.91 E1.35 S1.00 B0 V24.3
; Fans
M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 C"Part Cooling" ; set fan 0 value. Thermostatic control is turned off
M950 F1 C"fan1" Q500 ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T45 B1.5 X180 C"Hotend" ; set fan 1 value. Thermostatic control is turned on
M950 F2 C"fan2" ;Q800 ; create fan 2 on pin fan2 and set its frequency
M106 P2 H1:2:3 L1 X1 T53 ; set fan 2 value
M950 F3 C"e1heat" Q250 ; create fan 3 on pin fan0 and set its frequency
M106 P3 S0 H-1 L255 C"AUX" ; set fan 3 value. Thermostatic control is turned off
; Tools
M563 P0 S"E0" D0 H1 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C
M595 P40
; Custom settings are not defined
; Miscellaneous
T0 ; select first tool
;M501 ; Load config-override.g