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.
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.
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
Here is a good example of why my first idea might work. It's a very common situation: line infill.
These infill lines sweep back and forth, connected by a small travel movement. With XY moving optimally, the amount of time spent below commanded infill speed is tiny. If you watch the extruder, even with the small travel move instead of a print move connection, the dwell is hard to even see. With no pressure advance, the amount of over-extrusion in the direction change areas is negligible. Yet, pressure advance will fully advance and bleed for every move. When these infill lines are in a tight area, with only a few mm of travel, they happen in rapid succession and the whole thing falls apart.
Seeing that the dip in required extrusion rate will be extremely short and filtering out a pressure advance correction could solve this issue all together.
@DigitalVision said in A Software Solution to Eliminate Ringing?:
A short update.
I managed to get some hours to spend on this today, so I rewrote the test code from before mostly from scratch and turned it into a G-code filter. I can now take a regular slicer output file, pass it through the filter and feed the result to the printer. This makes it easier to do realistic testing. The code only really supports linear paths to far, so curves with high tessellation counts will end up looking terrible, but it should work OK for calibration cubes and similar objects. In the process of rewriting it I also implemented some improved machine limits so I won’t have to worry about it trying to move the Z-axis on my cartesian printer at 120 mm/sec.
Here are some quick-and-dirty results.
speed: 80 mm/s, accel: 10 m/s² (10,000 mm/s²), jerk: 2 km/s³ (2,000,000 mm/s³)
That is a beautiful print!
@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?
It would be great if the height map plugin could search for saved maps in sub-directories in <system>. This way we could avoid clutter in the system directory, and still have easy access to load saved maps from within the plugin.
Thanks
Running pressure advance calibrations at different printing speeds shows the need for different ideal values, based on speed.
I haven't done enough testing yet to see what the shape of the speed vs PA curve is, but I think even a linear lookup would be an improvement over a single static value.
Adding one more thing:
When my part cooling fan is set from 1% - 49%, the "tool fan" shows 0%. Set from 50 - 100% the "tool fan" shows 1%.
When manipulating the "tool fan" slider, the behavior is even more strange:
@o_lampe said in Vertical banding on COREXY machine:
@zabana
Since you are using a sherpa mini too, I think I will reconstruct the front bearing holder with a slightly larger distance between the main shaft and the hole that takes the pinch bracket shaft. The dual gears must not mesh too hard before the filament pinch force is right.
A bit of play between the gears is easier to accept than 'clenched teeth'
I went a different direction in separating the gear lash from the filament crush. Gear side axle support is elongated, allowing an M2.5 bolt to act on the axle and dial in gear lash independently:
I have an accelerometer hooked up and working, but found that the output results were a bit inconsistent, depending on how the data was gathered.
I found that a very effective method involves using custom after-layer gcode insertions in Super Slicer. Basically, you set up whatever test print you want, make sure speed and acceleration are set sufficiently high to induce ringing. Then enter custom codes like this:
{if layer_num < 33}M593 P"none"
{else}M593 P"MZV" F{(layer_num)*1.5}
{endif}
Vary the multiplier and layer number to sweep the range of frequencies you want to cover. Then, let it rip!
You can repeat the test print with the other shaper methods and see which one works best for you. I actually like MZV. It seems to be the best blend of effectiveness and minimal slowdown.
Find the Z height where you like the result best, and reference the formula (or gcode) to see which frequency this was. Then you can repeat the test, sweeping a narrower range of frequencies around your optimum.
Maybe I'll try this test with the damping factor as well.
@Adamfilip said in Input shaping without accelerometer:
Is it possible to calibrate input shaping without an accelerometer
Can you just print a test tower with different frequency settings and compare results.
since tests are needed to confirm results what is the main benefit of using accelerometer sensor?
Absolutely.
I use custom "after layer change" g-code, in Superslicer, to sweep a range of frequencies:
{if layer_num < 25}M593 P"none"
{else}M593 P"MZV" F{15+(layer_num-25)*1.5}
{endif}
This will use no IS below layer 25. Then after that will use type:MZV (choose your type), starting with 15 Hz. By changing that 1.5 multiplier (depending on your print height) you can end at a specific frequency.
@Komet said in Ultimaker Evolved:
@CCS86 I was also looking in ways to shorten the bowden tube and also came up with the idea of hanging the extruder on top of the printer. But your design also looks very interesting! Do you mind sharing the stl files for the extruder mount?
No problem.
BearingStepperMount.rar.txt
(just remove the .txt extension and extract)
I played with hanging the extruder, from the ceiling to start, and then from a frame mounted tripod. I found it hard to control the extruder drive from flopping around during certain print motions, and filament changes were a pain. This solution is much more liveable for me. I only run a 2.5mm retraction, which I think is pretty good for a bowden setup.
