Resonance calibration when the printer frame is not a static reference

Basic Information:

Printer Model: Qidi Q1 Pro

Related configuration:

[resonance_tester]
accel_per_hz: 150
max_smoothing:0.5

[printer]
kinematics:corexy
max_velocity: 600
max_accel: 20000
max_accel_to_decel: 10000
max_z_velocity: 10
max_z_accel: 500
square_corner_velocity: 8

Due to space constraints I had to place the Q1 Pro (18 kg with filament) on top of my previous DIY printer, which is a 3030 frame 500x500x1500 cm all included. The frame is stiffened in various places, but inevitably it wobbles a lot when the printer performs certain movements with high acceleration 180° changes of direction, like infill. Easily 1-2 cm oscillations of the whole printer.

The resonance calibration implemented in klipper uses only one accelerometer on the print head so it assumes that the printer frame is a static reference, that is doesn’t move.

Often this is the case, but in mine it’s not (and also when people install HULA feet, which allow the printer to translate).

My feeling is that the measurement is not accurate anymore, at least in the low-end frequencies, and the choice of the resonance frequency and IS algorithm will be affected, resulting in sub-optimal settings: the Q1 Pro is really stiff, so the motion experienced and measured during calibration won’t be there in real prints, since bed and toolhead will move together.

In my case, due to the combined weight of the printer and of the lower frame the frequencies affected will be below 10 Hz (rough guess), but people with HULA feet, having just the mass of the printer, will easily have the resonance spectrum affected up to 20 Hz.

This might explain also why people with HULA feet experience a reduction in print quality when the calibration takes places with the HULA feet on.

My use case is uncommon, so no code change is expected, but I somehow subtract the oscillations of the printer as a whole from the measured spectrum?

I could prepare an Arduino with a second ADXL on the base, outputting via serial to my computer acceleration data. Or I could record it using an Android app (which one? I need to set the sampling rate, which few apps do). But from them, how to proceed further?

I’ll report the results once I perform the measurement, it might be of interest for people using HULA feet.

As for my understaging, accelerometers like the ADXL345 measure in reference to earth’s gravity.

So, if you have a printer frame that has a tight connection to the earth, than you can say you measure in reference to the frame.

If your printer is on a train, or in a plane, the accelerometer also measures the vehicles movement changes.

So it is the same on a wobbly surface.

You may can provide another accelerometer to the frame of the printer and take that measurement as the reference. But I don’t know if that will help in the end, because the wobbly surface where the printer stands on will effect the print too.

I don’t think so, since both bed and toolhead move at the same time. They are stiff. But both move together in relation to the Earth reference system so that the calibration is performed with wrong assumptions (bed = printer = Earth).

I did not speak of the bed.

The surface I spoke of is the surface the printer stands on.

I have a different understanding:

  • You do not measure the resonances of your printer but you measure the resonances at the location of the accelerometer
  • Movements that do not hit a natural frequency of this location should not matter too much, at least not in terms of the resonance compensation
  • Absolute movement of the entire printer equally not

and yet people with HULA feet (which allows translation of the printer as a whole) seem to experience worse print resonance artifacts when the calibration is performed with the feet, while just fine results when the calibration is performed on a steady surface (as the algorithms expects) and then the printer is moved to wobbly feet for actual prints.

To me it seems to indicate that the assumption that the printer frame is static and therefore the measured resonances of the toolhead are relative to the bed/translate in print defects may be wrong in certain cases.

It would be interesting if anyone with a deeper knowledge of resonance compensation and measurement investigated the effect of wobbly feet.

This evening I’ll measure the resonance spectrum of the printer as a whole.
Has anyone a recommendation concerning an app able to set the accelerometer of my Android phone in high speed and to log data?

I think that, once I obtain the resonance of the system printer+base, I could use the setting “min_freq” to measure above that frequency.

No need to subtract the data measured with the second accelerometer if the frequency is low enough, which in my case should be (not so much for HULA users, having less than half the moving mass).

I also notice the setting “hz_per_sec” which means I need no special resolution in the Android app, any will be able to capture a sweep ramping at 1 Hz/s.

These are the results from the resonance compensation and from my phone taped (not double-side, just 4 corners) to the TOP of the printer during calibration. Maybe I should have taped it to the surface on which the printer sits on.

For info: the DFT from time-acceleration data was performed with chatgpt, since I found no other way to do it on large number of points (around 110k) without having to code, but the shape matches the amplitude of the raw acceleration data so I trust it.

My numbers are in units of g, not in m/s^2. If the values provided by the resonance compensation in Klipper are in m/s^2, the numbers I measured should be multiplied by 10.

I guess the noise in the phone acceleration above 60 Hz comes from wiggling due to the non optimal taping, but it’s possible to clearly see the motion of the printer.

The output from the resonance compensation:

Is the vertical scale comparable between the two? I have no idea.
If it is, the printer motion would be negligible (magnitude of 6k vs 200k-250k, assuming m/s^2 for both).

I can say that the previous resonance compensation performed by the printer, when I remember I held the frame steady as much as I could, gave me about half Hz higher resonance frequency.

Raw data available upon request, it’s 20 MB XLSX.

@dmbutyugin what do you think?

To be honest, I do not know what to think of your measurements. As it is, they do not indicate any problem that the resonance test picks up on your printer, wouldn’t you say?

I haven’t seen anyone publishing the actual resonance testing results, so I cannot say what may be going wrong there. So I don’t know if the test measures the wrong resonance frequencies (though that would be surprising) or if it picks up spurious resonance frequencies of the whole system and tries to compensate for them as well, while it is actually not needed and hinders the performance of the input shaper on the frequencies that actually matter. If you or anyone has such data (that is, resonance test results of the printer on the steady surface and on the HULA feet), I’d be curious to take a look.

FWIW, in principle it is possible to use two accelerometers in the test (say, one on the toolhead, one on the bed) and subtract the results of a one from another one, but there are a few caveats: (a) you need to be able to calibrate the scale of accelerometer axes fairly accurately (right now we just take the scale from the datasheet, which gives generic value(s) the manufacturer gives), (b) calibrate the orientation of the accelerometers (at least, relative to one another), and (c) interpolate and align the measurements from two accelerometers that happen at different, not aligned points in time (and even with slightly different frequencies). Otherwise, the subtraction will not produce the expected results.

In the meantime I replotted the acceleration measurements from my printer, scaled to m/s^2.

It looks like the amplitude of the resonances is 3% of the amplitude of the resonances measured at the toolhead, even if the actual translation of the frame on which I placed the printer is many many times larger.

I can only conclude that the shaking of the frame is not relevant for the compensation of the toolhead motion.

I did not expect it.

I’ll perform however the test you asked: resonance compensation on the floor and on the frame I’m currently using, while recording frame acceleration properly (so accelerometer on the top of the frame, not on the top of the printer). I’ll try to perform a difference in the two and see how it combined with the other ones.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.