Posts made by KP0005

The different banding in the top and bottom half of each tower segment is (I think) because the move direction flips midway.

That's all I got so far. @oliof

And now: Klipper MZV:

That's the harshest lighting I could manage. It's just perfect somehow.

MZV, no besh bed:

EI3, no mesh bed: it made shorter segments worse than baseline

All shapers except EI3. Reduced speed, so the bands are closer together. 38 Hz, 0.1 dampening factor.

Interestingly, the results do differ for small segments:

Photos! They're here!

MZV, frequency sweep from 36 to 56 Hz, jerk 300.

I did in the end notice some weird corner artifacts, I didn't pay much attention to this area before.

Another thing I forgot to mention. Disabling pressure advance also didn't help.

@oliof I know the Duet version has high jerk and mesh bed enabled. I have disabled those manually while printing. Haven't seen a improvement.

(I am trying to tune the printer to use Prusa MK3.9 profiles, since it shares most of the mechanics with it. My printer is a heavily modified MK2 with a homebrew version of the Bondtech MK3 extruder)

@oliof
Sliced for Duet: ringing_tower_0.4n_0.2mm_PLA_MK3.9_9m.gcode
Sliced for Klipper: ringing_tower_0.4n_0.2mm_PLA_MK3.9_7m.gcode

@oliof
RRF 3.5 RC3+ (last week, DC42's hotfix of the network issues from here https://forum.duet3d.com/post/332835)

I have tried MZV at both 40 and 50 Hz in RRF to basically no improvement over no shaping.

I haven't encountered layer shifting or blobbing in RRF, but some of the shapers caused sharp corners to print much worse. No such issue with Klipper.

config-override.g bed.g config.g

Some accelerometer samples attached:
1-T0-Y10-100-0-none.csv
2-T0-Y10-100-0-zvdd-39Hz-0.1.csv
3-T0-Y10-100-0-zvddd-39Hz-0.1.csv
8-T0-Y10-100-0-ei3-39Hz-0.1.csv
11-T0-Y10-100-0-ei3-50Hz-0.csv
16-T0-Y10-100-0-mzv-45Hz-0.csv
20-T0-Y10-100-0-zvd-42Hz-0.1.csv
23-T0-Y10-100-0-ei3-38Hz-0.csv

I have now spent about a week trying to get input shaping to work on my maestro. I tried:

• all the shapers
• different frequencies spanning from 36 to 56 Hz in steps of 2 Hz
• connecting a lis3dh to both bed and extruder and measuring frequencies, without any shaper and with different shapers and frequencies
• reducing jerk to 10mm/min
• completely disabling mesh bed compensation

All to pretty much no change. Data captured with the IS pluggin showed an improvement, but prints did not. The ringing tower, printed at 170mm/s (4000 acceleration) showed consistent humps around 4.4 mm apart (around 40 Hz), and that's on both axes. EI2 and EI3 managed to make the ringing worse on small segments, MZV made it slightly better on small segments, but that's it.

I almost gave up, thinking it might be an issue with my mechanics. Then I got the idea to try out the famous Klipper input shaper. Set it to MZV, 50mm/s Y, 40mm/s X and saw the ringing almost completely disappear! All with the same hardware, same accelerations and speeds, same motor settings...

Is it possible that the Maestro is just too slow to apply shaping at the right timing? Or what could be the difference in shaper implementations that causes such a massive difference in prints?

Notes:

• when using EI3 with a dampening ratio of 0, the printer started audibly vibrating in some moves. From the sound, it was around 300-500 Hz.
• EI3, ZVDDD with a dampening ratio of 0 showed a reduction around 40 Hz but a sizable increase around 80-100 Hz.

I will add photos of the test prints once I get home in the evening.

@dc42 I confirm that the new binary does fix the issue for me, thank you!

@droftarts
My testing has also been done with one pc, one browser tab at a time.

Are you using Windows? If yes, our results would be consistent. I don't know how the operating system would make a difference, since both were running chromium, but that is what I've seen...

Can you try connecting to it from something like an ubuntu virtual machine? Or a smartphone

DWC RC2 + RRF RC2: works
DWC RC3 + RRF RC2: works (but gives incompatibility warning)
DWC RC3 + RRF RC3: does not work
DWC RC2 + RRF RC3: does not work

so could it possibly be an RRF bug instead? @dc42

@KP0005 reverting DWC but NOT RRF does not fix the issue

Update:

reverting BOTH DWC and RRF to RC2 fixes the issue

Current theories are either a software issue, a hardware issue (I have accidentally shorted the mainboard for a few miliseconds with a fallen screw several years ago, long before this started happening) or some interaction with my network setup.

Due to being unable to run ethernet cables to this floor, I use an old wifi router with DD-WRT as a bridge. I have used it as such for several years now, and DWC did work.