MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

[BUG] FT_MOTION produces strange sound #27344

Open vovodroid opened 1 month ago

vovodroid commented 1 month ago

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

There is different, strange motion sound with FTM enabled (without IS). See also https://github.com/MarlinFirmware/Marlin/pull/26848#issuecomment-2171996308

Default:

https://github.com/user-attachments/assets/a528021b-1606-408a-b5ac-2508e3c0eff3

FTM:

https://github.com/user-attachments/assets/298ebe31-ec99-4332-a445-c81fecf39f6e

Spectrogram: image

BTT 3.0, TMC 2209

I'll try to take oscillograms later.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

bugfix-2.1.x 2024-08-07

Printer model

No response

Electronics

No response

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

Additional information & file uploads

Marlin.zip

thisiskeithb commented 1 month ago

I'll mark this as confirmed since I was the one who reported the issue in the referenced PR.

cc: @ulendoalex & @narno2202

narno2202 commented 1 month ago

On my side no strange sounds (MKS Monster8 V1.0, TMC2226) when FT_MOTION is enabled and the printer idle. When axes are moving as the timings are different from standard motion, the produced sound is also different : normal behavior.

vovodroid commented 1 month ago

Can we be sure that it doesn't damage drivers?

thisiskeithb commented 1 month ago

When axes are moving as the timings are different from standard motion, the produced sound is also different : normal behavior.

I also run 2209s, 2226s, & 5160s on various machines and the high-pitched whine & crunchy sounds cannot possibly be considered normal. They sound terrible with FT_MOTION.

Motors sound completely fine with standard motion / Input Shaping.

vovodroid commented 1 month ago

Could you record your printer? 

narno2202 commented 1 month ago

I'm currently transcoding the recordings

narno2202 commented 1 month ago

Here are the two files : 100mm X motion via Octoprint. First without FTM, seconf with FTM.

https://github.com/user-attachments/assets/11447154-c3a6-4f44-b1a8-7d13c36d30ae

https://github.com/user-attachments/assets/7b02d4cc-ffa9-4791-a9c6-999b333438a8

vovodroid commented 1 month ago

@narno2202 as for me your FTM sounds is the same as without, I can't distinguish. But besides higher pitch my has strange 350 Hz pulses:

image

Is is supposed to be during movement without IS?

vovodroid commented 1 month ago

@thisiskeithb could you upload your sound recordings?

thisiskeithb commented 1 month ago

could you upload your sound recordings?

My phone doesn’t pick up the differences very well and I don’t have any other kind of recording equipment.

narno2202 commented 1 month ago

Since the beginning the pitch is slightly higher. @ulendoalex says that is the normal sound as timings are different (but they respect stepper specs).

vovodroid commented 1 month ago

that is the normal sound as timings are different

And 300-350 Hz pulsation?

vovodroid commented 1 month ago

Here is Z axis move:

No FTM:

https://github.com/user-attachments/assets/a422549c-d6f0-4ac2-99f3-db48d9bf02ef

FTM:

https://github.com/user-attachments/assets/8405774d-f503-4370-a0ab-576bfba3a56b

Wave form:

image

I don't think such 3 Hz modulated pulsation (for slow Z axis) is good for printing quality. And frequency is about 200 Hz:

image

narno2202 commented 1 month ago

If you change FTM_FS value and FTM_TS accordingly, you'll notice a different sound : the sound is related to the frequency of trajectory generation and to FTM_STEPPER_FS value to.

vovodroid commented 1 month ago

I'm not familiar with meaning of these parameters, but they are 1000 and 20000 Hz, could it produce 3 Hz modulation?

Which values would you recommend?

vovodroid commented 1 month ago

Could it be related to

    // Use this to adjust the time required to consume the command buffer.
    // Try increasing this value if stepper motion is choppy.
    #define FTM_STEPPERCMD_BUFF_SIZE 3000         // Size of the stepper command buffers

?

narno2202 commented 1 month ago

When you increase FTM_STEPPERCMD_BUFF_SIZE, motion is smoother. The values for FTM_STEPPER_FSand FTM_STEPPERCMD_BUFF_SIZE are based on experiments, limitation is the RAM size and the MCU.

vovodroid commented 1 month ago

I doubled these parameters:

  #if DISABLED(COREXY)
    #define FTM_STEPPER_FS          40000         // (Hz) Frequency for stepper I/O update

    // Use this to adjust the time required to consume the command buffer.
    // Try increasing this value if stepper motion is choppy.
    #define FTM_STEPPERCMD_BUFF_SIZE 6000         // Size of the stepper command buffers

Still axis Z 3Hz pulsation I can't consider as normal

image

narno2202 commented 1 month ago

Try to change FTM_FS value and FTM_TS accordingly. On a 0.2mm layer high, what is the consequence?

vovodroid commented 1 month ago

Try to change FTM_FS value

Increase or decrease?

On a 0.2mm layer high,

This 3Hz pulsation is not during printing, but just while moving Z axis up or down.

narno2202 commented 1 month ago

On a 0.2mm layer high, what is the consequence?

On print quality

Try to change FTM_FS value and FTM_TS accordingly

you can try both (increase or decrease)

Have you tried to disable Babystepping? Does the pulse change?

vovodroid commented 4 weeks ago

Have you tried to disable Babystepping?

How does it affect motion? I even didn't home the printer, just moved Z after turning on.

vovodroid commented 4 weeks ago

I've tried

#define FTM_FS                     2500 // default 1000
#define FTM_TS                     (1.f/FTM_FS)

Sounds and looks better, but still not as default planner:

https://github.com/user-attachments/assets/ef6e5acf-6937-452d-a533-cf6eff999035

image

It seems that pulsation frequency is proportional to FTM_FS. Is it "by design" or points to issue?

Homing still is a problem - sensitivity 110 causes false triggering or Marlin error, and 105 causes no triggering grinding to the frame.

narno2202 commented 4 weeks ago

As the pulse frequency is directly related to frequency of trajectory generation (as I said in previous post), it's by design. Have you change the homing speed? (Klipper is a good basis but it's not Marlin)

vovodroid commented 4 weeks ago

Have you change the homing speed?

Not yet. What will be safe speed?

narno2202 commented 4 weeks ago

Let Marlin default's homing speed : 50mm/s and don't set the homing current too low (no less than half axis current).

vovodroid commented 4 weeks ago

Klipper is a good basis but it's not Marlin

But driver is the same driver.

Let Marlin default's homing speed : 50mm/s

This default speed is for switch homing without crashing into frame. 50 vs 20 means 6.25 time more kinetic energy, end more current means more force.

What is the reason for FTM to demand such harsh conditions for censorless homing?

narno2202 commented 4 weeks ago

This is my setting since i've set sensorless homing for the first time (with standard motion system) and homing is smooth and not violent. For testing purpose , I've changed some parameters. Decreasing home speed for X to 40mm/s with same current and sensitivity, produce slight grinding. For Y axis sensorless homing, I have some unreliability with FTM. Keeping the same speed and sensitivity and decreasing motor current, solve this intermittent issue, homing is also fine with standard motion. Sensorless homing is a subtle mix between these 3 variables : speed, current and sensitivity.

vovodroid commented 3 weeks ago

I think about making HOMING_FEEDRATE_MM_M configurable via menu. Will such PR be welcome?

thinkyhead commented 3 weeks ago

I think about making HOMING_FEEDRATE_MM_M configurable via menu. Will such PR be welcome?

@vovodroid — It definitely would. Anything that makes a commonly-adjusted constant into something runtime-configurable is welcome (even if it is only added to MarlinUI at first). And in this case it also fills in a missing piece.

You'll first want to implement the G-code M210 and add a slot in the EEPROM for axis homing feedrates. If you want you can also add an F parameter to G28 to specify an immediate homing feedrate override for XY. The homing bump will still be based on a divider to the given feedrate, but M210 could be extended with extra parameters to set homing bump dividers and distances.