After swapping out my Ultimaker Original+ glass bed for a MIC6 aluminum plate + Fulaflex, replacing the perimeter shafts and overly stiff motor couplers, I was able to really get the print surface flattened out!

My back right corner is just a bit low. I might add a jack screw over there to coax it up.

If anyone is interested, my friend and I developed a Cura post processing script (he did the hard part). I really think this would be better off a firmware feature, like I wrote a request for. But, in the meanwhile, for those using Cura:

You pass it a single parameter (mesh spacing value), and it parses the first layer gcode for min/max X and Y coordinates, and then replaces the M557 line in your start gcode.

LevelingMeshOptimizer.py.txt

Just remove the .txt, and drop it here: C:\Program Files\Ultimaker Cura 4.5.0\plugins\PostProcessingPlugin\scripts\

You must have a static mesh leveling command in your start gcode, like: M557 X0:200 Y0:200 S20

You sound much more interested in convincing everyone that "you did the right thing" in reverting to RRF2, than in fixing the issue you ran into.

Maybe it's a bug. But, more likely, it is a mistake that you made.

Instead of telling us how everything you did was perfect, like Trump; post both config files and stop snapping at everyone who is spending their time trying to help you.

After doing a lot of testing to find ideal accel and jerk rates for each axis, I realized that even with ideal printing acceleration set, your travel acceleration can still impact your outer wall at the seam.

Sometimes the travel move is short, when seams are aligned. But other times a longer travel move lands you right at the start of your external wall. This can cause ringing in your outer wall.

The best thought I have had so far, is to be able to define a separate deceleration rate.

Occasionally I end up with one or two "outlier" points in my bed leveling mesh. This can be due to hitting a small piece of debris on the bed, finding a gap in blue tape, or being right at an axis limit and having some chassis contact deflection.

I was think that a useful way to avoid compensating for an erroneous point would be to either do a TRIMMEAN, where you toss out anything in the upper and lower percentage away from the mean.

Or, you could go another direction and have an allowable point-to-point delta, which when exceeded, the point gets thrown out. This could be harder, because you have to decide which point stays and which goes. You could just keep the one closest to the mean I suppose.

I know that there are ways to avoid these points in the first place, but 'ish happens, right?

Thoughts?

Here is my heavily upgraded Ultimaker Original.

My recent upgrade to Duet Maestro control really brought it into the modern era.

Essentially every non-metal/wood part is my own design, and I actually have the whole thing built as a CAD assembly for ease of designing new parts in assembly context.

https://www.youtube.com/watch?v=QCCw3QC3H-k

Thanks guys.

I think this is probably the case, because shortly after I was able to upload the same file with no issue. In the process of backing up, I found an unexpected EOF error on a macro, so it seems like the SD was flaky.

Using (the awesome) RFM I was able to pull almost every file off the card (even though windows wouldn't properly mount it), and push them all to a new card. Boom, up and running without missing a beat.

Oddly, despite the DWC working on my local computer, when I try to load it from an external network, I get some errors in the console:

It seems odd, since I don't know why it would be using different files. But, I'll reinstall DWC and see if that fixes it.

• Fixed after reinstall

I wanted to open up a discussion about ways to improve pressure advance functionality in the future, especially for bowden based printers.

I'll describe my experience and setup first. I am running a custom extruder drive that uses a 5:1 geared stepper, driving a set of Bondtech dual drive gears. It has been relocated high and central, embedded in a bearing mount to allow rotation. This has let me minimize the bowden length to 450mm of Capricorn tubing. From there it goes through an E3D V6.

With everything I can think of done mechanically to improve extrusion response, I worked on tuning pressure advance. Adapting code from the Marlin linear advance calibration print (https://marlinfw.org/tools/lin_advance/k-factor.html), I honed in on S values for my printer. Even using "fast" and "slow" values that aren't very extreme (25 mm/s & 65 mm/s), I need S values around 1.4 to achieve a constant extrusion width through these speed changes.

While the test print looks great, getting real world prints to work with M572 S1.4 (or even S0.5 for that matter) has been an unsuccessful challenge so far. There seems to be some combination of factors in real prints that upsets the pressure advance algorithm. You have a lot of influence in tuning motion, with pressure advance enabled, using E axis jerk and acceleration. I found the best balance to be a fairly high max E_accel (8000 mm/s/s), and lower E_jerk (4 mm/s), for a max E_speed of 40 mm/s.

For certain prints, like cylindrical shells, where everything is concentric walls and you have long periods between acceleration and deceleration, this can work very well. But, once you get into normal infill, with lots of reversals and direction changes, it seems to lose control of extrusion rate and tend towards over-extrusion.

From watching the extruder action when it is not working well, I noticed some things. Mainly, that corrections can come in such rapid succession that the hope of having their affect time with the nozzle seems unlikely.

I don't know the details of the current implementation, but this is my understanding: Any given extrusion rate is associated with a certain nozzle pressure, which requires a certain amount of filament/extruder preload to achieve (determined with the S value). This amount is added at the beginning of any acceleration (as fast as the extruder axis settings allow), and the print head motion is bounded in acceleration/jerk to prevent it from outpacing the extruder. Everything is reversed during deceleration. This approach of forcing synchronization probably works pretty well with very small S values (direct drive printers). But I think it falls apart at larger values.

One question I have: Is pressure advance taking into account (sum total) XY jerk and (sum total) XY acceleration, when deciding whether to act? I swear I have seen it taking action during print head direction changes that appear to keep the nozzle at a constant velocity, either through jerk, or by X deceleration being made up for by Y acceleration. Maybe I am mistaken.

My best ideas at the moment:

• try to look ahead in the motion planning and determine the amount of time where extrusion rate will not match print head speed; choosing to stay inactive unless that time exceeds a user defined value. My gut says that if the mismatch time is under say 50 ms, there wouldn't be an observable quality difference with or without PA, and staying inactive could save a lot of E axis "chatter".

• acknowledge that there is a time delay between a PA compensation and a change in nozzle pressure / extrusion rate. Ideally, through another user defined parameter, you attempt to correct for this delay. But, it's possible that this is very difficult to implement.

• allow de-synchronization of the print head and the extruder. The more time the print head spends accelerating or decelerating, the more opportunity we have for extrusion rate mismatch. With no pressure advance, I tend to get the best results when XY accel and jerk are high enough to allow for very crisp motion. Allowing the print head to move unrestricted and have the extruder just "do its best" for E max values defined, may offer some improvement. Maybe just an M572 flag to enable this behavior.

• allow PA to be disabled during infill. I realize that this would require parsing data from the slicer, and that labeling conventions vary. But, the upside for PA in infill is pretty small. Most of the benefit is realized in perimeters IMO.

I definitely don't think that I have this all figured out. So, I'd love to hear from other people and their pressure advance experiences, where I might be wrong, and what other ideas are out there!

Any chance of revisiting this topic?

https://forum.duet3d.com/topic/4802/6th-order-jerk-controlled-motion-planning

@dc42 said in Independent input shapers per axis:

The second is that if you use per-axis input shapers, then the print head will not longer follow exactly the path specified in the GCode. This generally doesn't matter for travel moves, but does for printing moves. This may be what the Klipper documentation refers to as "smoothing" when more complex input shapers are used.

You could argue, that because of the resonance / ringing, the unaltered input isn't allowing the nozzle to exactly follow the path, and that the shaped input's intentional path "deviations" actually allow more precise tracking of the nozzle to the path, no?

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.

@Phaedrux

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.