On the March branch enabling Input shaping makes steppers noisy

[oloendithas]

On the March branch enabling Input shaping makes steppers noisy

Steps to reproduce the behavior:

1. Copy Configuration Pro.h and Configuration_adv Pro.h from /configurations/Voxelab Aquila/UBL to /Marlin and rename properly
2. Uncomment Input Shaping X/Y options
3. Build/Flash (had to disable GCode preview and toolbar options to fit 227kB)
4. Move X/Y axis on higher feedrate (e.g. G0 X70 F16000)
5. Hear the noise, as if pulley teethes are skipping the belt.

Version (please complete the following information):
Running Aquila S2 N32 (3D Touch)

Probe works fine.
February branch build with the same options doesn't suffer from this issue.

commit.patch

[classicrocker883]

hm I will look into what differences may have caused this. otherwise just input shaping enabled? have you tried changing the values associated with input shaping?

I may make a new branch with changes, TBA

[classicrocker883]

I just made a branch IS-steppers-noisy, you will see I edited only one file module/stepper. h. please try this as I suspect that the ISR values for the steppers have been changed since last update. so I reverted back to the Feb branch with only this file.

@oloendithas let me know if you still experience this issue, or any differences. or if you have any ideas what may need to be changed. I'll continue to look into this.

[oloendithas]

Hi, Andrew! Can't build this, seems this header doesn't suite for current .cpp.

[oloendithas]

Also, want to ask, are these _RSENSE params related to sense resistors at the motor drivers? Because my N32 board has 150R resistors rather than 110R on that places.

[classicrocker883]

I since updated the March branch to the current Marlin, see if that has helped. if you can post your config files or changes made ill see if I can duplicate and find what the issue is. if you like you can upload your workspace to a repository to make it easier to look it over.

as for the RSENSE that isn't something available for these boards. the drivers are TMC2208_STANDALONE. If it were just TMC2208 or TMC2209 like on the skr mini e3 then you would be able to edit those TMC_CONFIG values.

so you had no issue with the steppers using the Feb branch? ill compare the file changes related to them and post them in that new IS-steppers-noisy branch. if you can upload or attach your config files and any other changes ill try to get this fixed.

[classicrocker883]

ok i uploaded the changes to the IS-stepper-noisy branch, it compiles fine. let me know how it goes if that helps with the steppers. also, search " oloendithas " i made comments in the files where some values can be changed if you have an issue.

[classicrocker883]

check out the new 2023-March_ branch. So i tried it out and haven't had any issues. I have yet to try input shaping enabled so I cant comment yet, but I have noticed something. I recently got myself an aftermarket stepper motor, upon plugging it in it started making a weird grinding noise. all the other steppers work fine. I swapped the two inside wires of the connector and it started working like normal. then when i plugged the old stepper in that one started making a grinding noise.

it appears some steppers are made differently than others. this may be a cause of issue. otherwise if it does continue and is software related, my only guess is could do with timing.

[classicrocker883]

from this open Issue in MarlinFirmware/Marlin

The simplest thing to do to get at the root of stepper code issues is to find the newest version of Marlin where the problem does not exist, and then go through all the stepper changes between that older version and today to pinpoint the breaking change(s). Of course, if you can pick through the history of bugfix-2.1.x using bisection to narrow down the exact date/commit where the problem was introduced, that will bring us to the threshold of a solution. I don't want to roll back all the movement optimizations if we don't have to, but I am certainly willing to roll back as far as we must to get back to reliable motion, even if it is not as optimized.

The strategy in "bisect" is to find a commit from some point in the "distant" past where the feature works. Then you would test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact date/commit where it broke.

The cool thing about this method is that if you started from a point –say– 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

Mr. Marlin himself @thinkyhead posted this great reply as to finding a fix for this kind of issue.

if anyone needs experiences the issue and needs help with what to do next please let us know and make your replies here.

[oloendithas]

Hi,
Sorry for not responding for a long time.

ok i uploaded the changes to the IS-stepper-noisy branch, it compiles fine. let me know how it goes if that helps with the steppers. also, search " oloendithas " i made comments in the files where some values can be changed if you have an issue.

Tried it now and yes? I was able to build and run it. Now the stepper's noise is gone. But I wasn't able to connect OctoPrint on 250K as usually.

check out the new 2023-March_ branch. So i tried it out and haven't had any issues.

Tried to build this one and found out that the N32F103RET6 section is gone from the stm32f1-maple.ini. Added it manually and built. Though, this time could not connect OctoPrint on any baud rate.
Also the encoder direction has reversed for some reason)
And even more: left the printer on white trying to figure out, what happened with serial connection, and after several minutes an alarm sound hit in! The bed was heated up to 120C, while the documented max is 110C! Looks like something has went wrong with support for S2(
Will try to investigate further.

to find the newest version of Marlin where the problem does not exist

Yeap, rolling back commits one by one - is a good idea for debugging this)

[oloendithas]

I've spent almost a whole day trying to manually flash a firmware bypassing the bootloader.
Tried an SL-Link/V2 SWD and builtin to STs UART bootloader, hoping than Nation has cloned ST's controller into exact copy. But sadly nothing worked. ST-Link does not recognize this controller and UART methon is seems not supported also(

[classicrocker883]

the N32F103RET6 section is gone from the stm32f1-maple.ini.
yes because these chips aren't actually RET6 (512k), they are RCT6 (256k), unless yours is not? I'm certain all the voxelab boards are 256k versions, but yours is the S2? maybe you have an RET6, if you can confirm what it says right on the chip ill add it back on to the .ini.

as for the encoder being reversed that may be my fault having different configuration.h files of different boards I was testing.
its as easy as enabling #define REVERSE_ENCODER_DIRECTION line ~2664

that is good to hear the stepper noise is gone away, however im not sure at the moment which exact parameter change caused it, ill look into it.

what had happened to me was I installed an aftermarket stepper motor, and immediately got noisy. it did not sound good at all and did not work at all, just grinding noise. so I swapped the inner two pins on the 6pin connector (only 4 are used) and the motor started working normal again. this led me to believe was Marlin software designed for specific stepper motors to be wired that way? or was it just this specific brand of motor which had the 2 wires backwards and not the fault of the firmware?

it seems as though the noisy motors happens sometimes and not for every board because I haven't had this issue using the creality 4.2.7. and for my G32 I test with, i haven't always been able to reproduce.

as for your ST-Link, what are you trying to do? are you not able to flash firmware on the board through the SD card slot?

I have one of those the STLINK v2, and was able to connect my board using the 4 pinout by the display port connector on the board. to upload, in the .ini file look for debug_tool and upload_protocol and have that changed to stlink and you should be able to upload firmware that way with PlatformIO: Upload, instead of Build

or what is it you are trying to do?

[oloendithas]

what had happened to me was I installed an aftermarket stepper motor, and immediately got noisy. it did not sound good at all and did not work at all, just grinding noise.

Yes, if you swap polarity, the motor will just shake and scream) I guess, this is between the motor's and the driver's pins correlation. The noise I've faced was much like the one I had when first attached the 3D Touch sensor and was trying to make it work: the noise comes from all three motors, but they able to move. It's some kind of vibration.

as for your ST-Link, what are you trying to do? are you not able to flash firmware on the board through the SD card slot?

No-no, flashing from SD card is just fine. I just wanted to override that 228KB limit.

I have one of those the STLINK v2, and was able to connect my board using the 4 pinout by the display port connector on the board. to upload, in the .ini file look for debug_tool and upload_protocol and have that changed to stlink and you should be able to upload firmware that way with PlatformIO: Upload, instead of Build

Oh! Didn't know that. Will definitely try. Thanks for the clue! Should I walk through some boot switching procedure or just unplug the power cable, connect that SWD and use that PlatformIO Upolad?

[classicrocker883]

Should I walk through some boot switching procedure or just unplug the power cable, connect that SWD and use that PlatformIO Upolad?

im not so sure if that would be such a good idea, technically i think you would connect the pins and either VCC or GND can be left unplugged, im not sure the exact details, however I would stick with the normal SD card way of flashing. because yeah the mainboard chips are limited 256k, and you could technically bypass the bootloader and flash directly with stlink or whatever, I would really advise you do not and just flash using the normal micro SD and .bin file.

I uploaded some prerelease if you wanted to check it out here

its updated to the most recent Marlin and should work fine. this is the 2023-April branch. let me know if u use it and if the steppers are still an issue. otherwise what worked fine before? Alex's firmware on his repo? i might take some of those values of parameters and use them with the newer build.

[oloendithas]

mainboard chips are limited 256k

Isn't STM32F103RET and it's clone N32G452 have 512k of flash?

its updated to the most recent Marlin and should work fine. this is the 2023-April branch.

Oh, yeap, already tried that from b19c0cb Update 4/15 - config files and got steppers noise. But this time it was different: noise only on acceleration/deceleration and as if the pulley gears are skipping teethes.
I even tried to tinker with those Stepper::ticks_nominal values in stepper.cpp, but no change.
I thought I record a video, but something has went wrong and I did not(( So just forgotten to report that.
I can see , you've made a bunch of new commits. Will certainly try again)

[classicrocker883]

Isn't STM32F103RET and it's clone N32G452 have 512k of flash?

yes technically those should be 512k. I thought myself for the longest time my GD32F103RCT6 was "RE", and tried flashing as 512k and the file was larger than 256k and well it would start to flash but would not boot. when I by chance did a smaller file size, and it worked, I looked closer and sure enough the chip was indeed "RC". I asked around at another Aquila community and they confirmed the G and N and H 32 chips all 256k. but some do have STM32 chips which should be "RE" 512k, thats why it is always import to check the type of chip and the rest of its model characters.

your chip is N32 right? a "N32G452" or G455 are very similar and I think they are 256k like the GD32
while theyre supposed to be clones of the STM32F1, they are not exactly. the N32 and GD32 have different flash MHz speeds, everything else is about the same.

but if yours says RE instead then perhaps not every Aquila is 256k. u can test this if a firmware file larger than 89.1% of 256k doesn't boot after flashing.

[classicrocker883]

update : I uploaded the IS-steppers-noisy with the latest Marlin and I changed the module/stepper.h file with ISR cycle values from Alex's code. I'm hoping that should solve the motor noise issue, let me know if you do try it out.

[oloendithas]

Hi, Andrew. Thanks for not giving up on me!
Tried the updated IS-steppers-noisy and obviously something has changed, but not for good. Now it's grinding not only on acceleration/deceleration, but along the whole movement, as motor is spinning too fast and skipping almost all belt's teethes.
Tested with command: G1 X200 F15000

[classicrocker883]

OK thank you for trying. I made one change which I believe should work. you will see I set MAX_STEP_ISR_FREQUENCY_1X back to the current Marlin code. the only other changes are just the ISR cycle values, which I left as they were in Alex's file.

[oloendithas]

I made one change which I believe should work. you will see I set MAX_STEP_ISR_FREQUENCY_1X back to the current Marlin code. the only other changes are just the ISR cycle values, which I left as they were in Alex's file.

Hi/ Just got my hands to try this and sadly it's still the same issue. Really want to update and get all the latest goodies. Is there any thing I can do to help you to debug this? Maybe you can provide me some list of options/changes/patches to try in combinations?

[classicrocker883]

hey, I uploaded a recent release with the newest Marlin updates. I tested it for myself and can't seem to recreate any issue with the stepper motors.

have you tried the most recent firmware release? the most updated branch is 2023-May. everything is working fine on my end, that is with GD32 board and Creality 427.

I haven't heard back of any issues, perhaps this can be N32 specific? the main difference for N32 is in this file Marlin/src/HAL/STM32F1/HAL.cpp

the ini file enables DVOXELAB_N32 and the following code after line 392. it could be that because of the updates to Marlin and the rest of the HAL, that this portion needs to be updated as well? I'm not sure where this source code is, I copied it from Alex's since this is the only thing different when compiling for N32.

if you're compiling your own what you can try doing, is delete the downloaded library folders. in Windows, if that's what you're using, I think they are in C:/Users/<User_Name>/.platformio/packages/
they will be re-downloaded once you build the firmware.

before u do that have you tried the firmware I compiled and released? https://github.com/classicrocker883/MriscocProUI/releases/tag/2.1.3c1

[oloendithas]

the most updated branch is 2023-May

Forgot to mention, yes, I tried that one also and it also gives me that issue.

the main difference for N32 is in this file Marlin/src/HAL/STM32F1/HAL.cpp

I remember that huge block of custom code. Maybe you could give me a clue, what word pay attention to?

Finally managed to record a video of the noise.
https://youtube.com/shorts/BN8xXIXVB8k?feature=share
The moves are:
F15000
home
F10000
home
F7000
F6000 (no noticeable noise here)

before u do that have you tried the firmware I compiled and released?

Yeap, tried N32_UBL-7x7-NoPro-IS-MPC.bin. No luck.

[classicrocker883]

I'll try to help you out my friend, but I really don't think this has to be an issue with the firmware. Im asking someone who had N32 to look at the video if they also have that.

what I'm thinking is a couple things... first is the acceleration. have you changed the Max default acceleration in the settings? ti's in the Control/Motion menu. I believe you can enter a command, and M503 will view all the settings.

second, is the belt fine? that can also cause a noise - which you can turn it around incase the gears strip the belt. or is the motor all good? have you tried swapping? because this is only with the X axis? or also Y or Z?

so I would increase the acceleration in the settings and see if that works, because if the settings are low and you're moving it faster, maybe it's not keeping up and that's why it makes the noise.

I think I mentioned this before, but I had a similar issue with the same kind of noise when I swapped my motor for aftermarket, swapping the two inner pins fixed that. but it would always make the sound no matter what, it's because it was wired differently.

I'll look back though the code anyway and see if there is updates, but I'll let u know if other N32 printers have this.

[oloendithas]

Do those people use Input Shaping? This issue appears only with it enabled.
Of-course I'm not blaming firmware) Obviously, it's some kind of compatibility issue. But if those people can use the latest builds on N32 with IS on, that brings me hope.

Acceleration? Yes, I set it to 1500. But I'm using it on the February build with IS and it running fine. But I'll try to play with acceleration and maybe jerk on the new build.

second, is the belt fine? that can also cause a noise - which you can turn it around incase the gears strip the belt. or is the motor all good? have you tried swapping? because this is only with the X axis? or also Y or Z?

Belts and motors completely are fine with your February branch with IS on. I doubt, this could be a pure mechanical issue. On your February branch I can go really high speeds and was running acceleration 3000 for some time, but not happy with the quality.

so I would increase the acceleration in the settings and see if that works, because if the settings are low and you're moving it faster, maybe it's not keeping up and that's why it makes the noise.

Yes, I remember you mentioned that, but when I have messed with pins once, the motor just blocked and produced some shaking noise, not like the pulley spinning of the belt. Actually, it looks like on acceleration/deceleration motor spins faster than no movement, and because of that skipping teethes.

[classicrocker883]

the skipping of teeth had me thinking that was cause the motor noise. so I asked the other person with N32 they said it is silent, but I forgot to mention the Input Shaping, I don't think they have IS enabled. so I'll try to recreate the same code with mine even though it's not N32. and I wonder why the Feb branch is silent but it gives less quality?

I do know input shaping is relativity new and there are always updates to the code. for now I want to say if anyone wants to use it with this firmware, there may be a limit.

So just to make sure I understand, to print at faster speeds, acceleration and jerk have to be increased. but when those increase, ringing can occur in the parts printed. Input shaping helps counter the frequency of the shaking of the printer at the speeds.

for you, the noise it makes happens at these higher speeds. what would benefit everyone is if you are able to find the point where this happens so I can then pass that information on like in a README or something. most of us don't usually print at high speeds anyway, so I'm wondering what mm/s are you printing at? and say you print at slow speeds but have high acceleration, does the sound happen? or vice versa, if u try to print at high speed with low acceleration, does the sound happen?

I know it may be a lot to do, but if you are around doing testing this is good information to record. or if there are any other things to test?

I also wonder - does having different frequencies in settings have an effect? I'm not all that familiar with input shaping, I'd like to try it out when I figure out how and what I may need to get it working.

but say I dont try any of that, would I be able to recreate the sound issue if I do a fresh install with IS enabled? or is the calibration required?

[classicrocker883]

on more thing I just realized.. your voltage reference, vref. have you adjusted that or increased it?

[oloendithas]

So I've made some investigations and results are surprising and sad.
I tested on your latest June branch with IS on:

• Speed (print/travel) 80-500
• acceleration 50-3000
• jerk 5-20
  Teeth skipping may be more aggressive or more lazy but it persists with any config.
  https://drive.google.com/file/d/1zUXM91f-zgjkvNp9xZUJaX4b4Tvc_3NL/view?usp=drive_link

Even more (and even worse), I decided to give up on IS in a benefit of all new goodies and build a version without IS.
Tested all the same travel moves, and they wet completely smooth. Then decided to print the Ringing Tower test to see, how much I loose without IS and got a teeth skipping noise and picture. It looks to be bounded to corners, but linear walls are also went out bad. Print speeds are 90 and 180 here. On both the issue persists.
https://drive.google.com/file/d/1i5cz_1bT3Iy1lNcQkBGSfiPuYSkzPVxI/view?usp=drive_link
https://drive.google.com/file/d/1Pxh-9A8W2eWFf2PuNOhH0QOKxIJQm-_q/view?usp=drive_link

So the conclusion is that the issue is more pronounced with IS on, but it's still here even without the IS.
Recently I've replaced Y/Z motors to MOONS'. X motor was already MOONS', but the others were some noname from Creality, very noisy. Also removed filament holder from the frame, installed 4 rigidity rods, remounted Z motors from the vertical frame to the bottom and with vibration dampers. So I have much less ringing now, and IS calibration shown a frequency change. Thus, mechanics are changed significantly, but that had zero effect on the issue(

on more thing I just realized.. your voltage reference, vref. have you adjusted that or increased it?

Yes, I have changed the Amps in the configuration-adv according to motors' specs, and tuned vref (and retuned again now) to find points of leas vibration.
(Also a concrete plate on top of a foam plate are a magic vibration damper. Seriously, I can hear only fan noise now)

[classicrocker883]

I uploaded https://github.com/classicrocker883/Marlin/tree/bugfix-2.1.x-N32

which is Marlin bugfix with N32 support. I haven't touched anything else. you can use DWIN_LCD_PROUI or JyersUI and see if you still experience the issue. if you do at all then its to do with the Marlin firmware itself.

let me know how it goes, you should be able to copy paste your configurations, just beaware the backlight_timeout_mins in _adv.h should be disabled.

im not sure if these iterations of ProUI or JyersUI have inputshaping menu, but you can enter it in the command terminal.

[oloendithas]

if you do at all then its to do with the Marlin firmware itself.

Tried this one and yeap, this performs even worse(

Finally got my hands to rollback commits from the March branch and found out that issue is first introduced by this commit:
7e644de

While "172 changed files with 21,633 additions and 1,495 deletions" looks terrifying, I'm planning to investigate further.

[classicrocker883]

I posted the issue on Marlin to see what they say. it's suggested to lower MULTISTEPPING_LIMIT to 8. I'm not actually sure the differences are. I mean if it's fixed with OLD_ADAPTIVE_MULTISTEPPING, great.

but if you don't mind one more test, to disable OLD_ADAPTIVE_MULTISTEPPING and set MULTISTEPPING_LIMIT to 8 and see if that actually fixes as well.

[classicrocker883]

Multistepping feature attempts to combine multiple step requests into a single ISR to squeeze more performance out of CPU's (you get back overhead spent switching to ISR routine). Both old and new code computes how many steps to do in 1 ISR. Old is based on hard coded compile time knowledge of worst case timing and new code is based on runtime computed values. The new way should be more accurate since it's based on actual measurements.

In both old and new, it's pretty easy to get a bit aggressive on combining steps into single ISR; especially on underpowered hardware. Turning on optional features such as INPUT_SHAPING+ADAPTIVE_STEP_SMOOTHING+S_SCURVE_ACCEL make it that much more aggressive at combining. Side effects of combining are losing steps and strange stepper noises. MULTISTEP_LIMIT is new config item and can put an upper limit to prevent being aggressive with 8 being a good choice on underpowered hardware regardless of new vs old.

But then again, its very dependent on your config... If you disable INPUT_SHAPING then 16 might actually be best value... you want the highest but stablest value possible for your config.

Is old or new logic better to use? New way is very new but I assume the best choice... but thats why old way was left around so people could try both.

This is the reply I got. so basically what I'm guessing is with all these new things the Aquila board doesn't seem to like it all at once. so if you use input shaping, it's best to dial back the MULTISTEPPING_LIMIT, or perhaps disable LIN_ADVANCE?

[oloendithas]

Oh, this looks promising. Had no chance to get my hands on it today (but brewed a batch of Pale Ale 🍺😎)
Will try to play with this multistepping tomorrow.
But what is "underpowered hardware"? Is it a slow CPU or low Amps steppers?

[oloendithas]

check out Disabling Bundled Components in this platformio document. perhaps it's possible to disable some unneeded things. I know if you say compiled for STM32F103RE_creality (without _maple) it loads about 10 libraries. vs with _maple, 27.

Tried to add
board_build.ststm32.disable_embedded_libs = yes lib_ldf_mode = chain
to [env:N32F103RC_voxelab_maple] section, but no change to file size. Maybe these options are already enabled somewhere else. Or I added them wrong. Not much trouble for now.

Played with MULTISTEPPING_LIMIT 8,4,2,1, but doesn't help. 1 changes the sound, but doesn't resolve the issue completely.
Tried disabling LIN_ADVANCE and that doesn't change anything either.

have you looked into this in config_adv file?

Huh. This FT_MOTION looks promising but seems not ready to every day usage?
Had some complications to fit it into 228kB. Disabled input shaping, linear advance and UBL to fit it. It feels still buggy: in some modes some axis's are just won't move. Still it changes the noise "behavior" but does not remove it.

Regarding the investigetion of stepper.cpp:
There is a var 'time_spent_out_isr' and when it =0, then no noise at all. If it's not 0, then more or less noise occurs.
The only place it's set to non-zero is here

I've been trying to add something like if (time_spent_out_isr < 0) time_spent_out_isr = 0;
or if (time_spent_out_isr > 0) time_spent_out_isr = 0;
or even
if (time_spent_out_isr < 0) time_spent_out_isr = 0; if (time_spent_out_isr > 0) time_spent_out_isr = 0;

but none of these conditions seems to fire.
If I set directly
else { // Track the time spent voluntarily outside the ISR time_spent_out_isr += next_isr_ticks; time_spent_out_isr -= time_spent; time_spent_out_isr = 0; }
Then I get no noise, but it's the same as to comment out those previous two lines.
I've no idea, how to get it actual values or why those conditions I try don't work. I guess the lack of my C++ skills comes into play.

Thus, it's something about time_spent_out_isr, but I don't know how to debug it further.
If you have any ideas, hhow it causes the issue or at least how to log it's values, I'd be a bit more happy.

[classicrocker883]

"underpowered hardware"

I think this means if you had a stepper motor that were different - made for the specific application, there could be less issue or noise. these motors are limited by their hardware - maybe a bigger motor you will have better success? (less noise).

there are quite a few motors you can choose from. - list of them here

I wonder if having a bigger motor, or even the same motor so close in specs, but different by one or two things, like torque and inductance has an effect.

its possible that however they test the firmware for updating the code may not be universal for every motor. whoever is testing and writing the code must have it work for them, but since their testing hardware may not be the exact same, then the code may not work for a different motor.

I'll look into time_spent_out_isr. so setting it manually to =0 has no noise, but would this have any effect on printing models?

what about adaptive smoothing? I've been trying to see if how it makes a difference, but haven't noticed any. if I can make the time_spent_out_isr change in the menu that should help you set it. like I did with the encoder rate - have you noticed in the advanced settings menu?

that may be one thing I could use a 2nd opinion on; how does the encoder knob feel? you can change those values. I want to ask if they are good as they are, or should be a different value.

[classicrocker883]

After some looking through the code, I have a thought that BABYSTEPPING may be part of the issue causing noise.

have you tried the different sub-defines?

 //#define INTEGRATED_BABYSTEPPING         // Integration of babystepping into the Stepper ISR
 //#define BABYSTEP_XY                     // Also enable X/Y Babystepping.
---                         ---                          ---
 #define BABYSTEP_MULTIPLICATOR_XY 1       // (steps or mm) Steps or millimeter distance for each XY babystep

also BABYSTEP_MULTIPLICATOR_Z 1 (not sure if these values are what they should be because it was defined as 40 by Mriscoc but I found it defined to 1 somewhere else - i think right from Marlin's configs.

[classicrocker883]

@oloendithas without having looked through this whole thing, but it appears IS - input shaping issue has been fixed?

MarlinFirmware/Marlin#25719

after a quick read, it seems like someone else had similar experience, not sure if the most recent commit related to this PR actually fixes the issue that was described, but im working on fixing the little bugs with the current build and ill implement the newer marlin code of this.

[oloendithas]

I wonder if having a bigger motor, or even the same motor so close in specs, but different by one or two things, like torque and inductance has an effect.

I have 34mm X motor and 40mm Y motor and still they both suffer from stuttering. Also, the X one was MOONS' but the Y was a no-name from Creality. Recently I replaced Y and dual-Z on MOONS', as they give less vibrations, but that didn't change anything regarding the issue. So not sure if this is motor related. But also have no idea, what else. Controller of driver? On N32 related code?

so setting it manually to =0 has no noise, but would this have any effect on printing models?

Yes, in works and even able to print fine. I suppose, that makes it much alike that OLD_ADAPTIVE... if not the same.

what about adaptive smoothing?

I tried to untick Motion - Steps smoothing (if that refers to the adaptive smoothing) and that didn't changed anything.

I want to ask if they are good as they are, or should be a different value.

Yes, I recall, at some point the encoder acceleration was too high, but recent values are pretty much perfect as they are. I have tinkered with them and returned to the your values)

so setting it manually to =0 has no noise, but would this have any effect on printing models?
It seems that anything different from 0 gives the stuttering. So not sure if real-time tuning will help.

also BABYSTEP_MULTIPLICATOR_Z 1 (not sure if these values are what they should be because it was defined as 40 by Mriscoc but I found it defined to 1 somewhere else - i think right from Marlin's configs.

Hmm... Gonna try this today.

without having looked through this whole thing, but it appears IS - input shaping issue has been fixed?

I'm not sure if I understand, what they say, but would be nice to try, yes.

[classicrocker883]

I could do the same tests with my creality 4.2.7 board, however I dont have stock motors except for Z and E. im not sure the difference between Input Shaping and FT_Motion (fixed-time motion) or how they are related.

I wasn't sure what I read exactly in that pull request link @ MarlinFirmware, it seemed like they fixed an issue with the frequency. is there a difference between Input Shaping and FT_Motion (fixed-time motion) or how they are related? and is one better?

but I think since input shaping is still new to Marlin it will take some time to get it perfect.

heres some other links for reference incase you need it.

https://marlinfw.org/docs/gcode/M593.html
https://marlinfw.org/docs/gcode/M493.html
https://www.th3dstudio.com/marlin-input-shaping-calculator/

so should I close this issue out? im not sure what else we could do but either not use Input Shaping for now, or becareful using it a specific way.

[oloendithas]

As far as I understand, FT_Motion is an alternative approach for IS, Lin advance, baby stepping(?) - all the motion control stuff.
I tried to test it recently and it happened to be really buggy. I suppose, it's far from production yet. So I'm not using it now.
For the issue I experience here IS is not an obligated condition, it's just makes it more obvious.
So those frequency fixes might be related/helpful.

Regarding that PR MarlinFirmware/Marlin#25719, it looks to be entirely related to FT_Motion, which none of us is using yet. So, I don't think this could help right now. Maybe, when it get more stable, it could change lots... something.

[oloendithas]

Yeap, let's just close this. For now OLD_ADAPTIVE does the job. I'll be trying turning it off in new releases to see, if the issue went away.
Huuuge thanks to you for your patience and great work!)

[classicrocker883]

hey I just uploaded a new July branch, it has the newest Marlin updates. I dont recall there being anything stepper related changes, but I just like to let you know i switched it to the default branch from June. I know I have yet to test it myself before creating the new branch, but thats okay everything so far compiles successfully.

[thinkyhead]

I'm glad that we included the OLD_ADAPTIVE_MULTISTEPPING define so that we could isolate any issues related to the new adaptive multi-stepping code, which is different enough to warrant caution.

I'm not sure what the exact differences might be that would lead to noisy steppers, but I have one hypothesis. It could be that switching to a different level of multi-stepping makes the ISR take longer, which leads to a calculation that it should change to a lower level of multi-stepping, and then under the new conditions it calculates that it can change to a higher level of multi-stepping … and so on … leading to a continuous oscillation between different levels of multi-stepping, and therefore more irregular stepping.

I believe we did look at that and determined that it shouldn't occur, but we may want to revisit that under a wider variety of conditions.

CC: @tombrazier

[tombrazier]

Yes, @thinkyhead, I think this is exactly what is happening. And we did talk about it and I thought there was enough hysteresis to prevent continuous switching. However, I have seen someone else with this problem somewhere. (Can't remember where - I suspect an issue request where I responded saying "try X" and heard no more.)

It would be easy enough to verify whether this is the cause. Change the code at the start of function Stepper::block_phase_isr() so that reducing multistepping is less responsive. Do this by playing with the condition time_spent_out_isr >= time_spent_in_isr + time_spent. e.g. something like:

  #if DISABLED(OLD_ADAPTIVE_MULTISTEPPING)
    // If the ISR uses < 50% of MPU time, halve multi-stepping
    const hal_timer_t time_spent = HAL_timer_get_count(MF_TIMER_STEP);
    #if MULTISTEPPING_LIMIT > 1
      if (steps_per_isr > 1 && time_spent_out_isr >= 2 * (time_spent_in_isr + time_spent)) {
        steps_per_isr >>= 1;
        // ticks_nominal will need to be recalculated if we are in cruise phase
        ticks_nominal = 0;
      }
    #endif
    time_spent_in_isr = -time_spent;    // unsigned but guaranteed to be +ve when needed
    time_spent_out_isr = 0;
  #endif

[classicrocker883]

@tombrazier would this be the comment you are referring to? Originally posted by @tombrazier in MarlinFirmware/Marlin#25912 (comment)

I would be able to test anything out, just on the bench though, but I haven't been able to recreate the issue myself. as these issues seem to only be with certain mainboards such as Voxelab Aquila GD32 or N32. or it could be just the _Maple environment.

I know others have mentioned it a problem. but if it's anything I can do just name it.

[oloendithas]

Oh, I will gladly test this next week and report here, how it goes.

[tombrazier]

would this be the comment you are referring to?

Oh, yes, that will be it. So I take it your Marlin issue request is in response to this issue request.

The behaviour will be very dependent on mainboard and will also only happen at certain speeds. I look forward to seeing what @oloendithas finds.

[thinkyhead]

The behaviour will be very dependent on mainboard and will also only happen at certain speeds. I look forward to seeing what @oloendithas finds.

I notice that in both the old and new adaptive code we always use doubling and halving. I wonder if we could get more fluid behavior by incrementing and decrementing instead. This would add more complexity, and with 1x and 2x it would still amount to doubling and halving, but as the step rate starts to increase to 3x, 4x, and up it could start to make a difference.

There's also a hanging question about the way the regular stepper pulse phase is separated from the ZV shaper phase, such that it can generate up to double the amount of pulse delay time applied in a single call to the ISR. This tends to have more of an effect on time allocated to the main loop, but it might also be leading to irregular timing of ISR invocations. If we could combine both the regular and the shaping pulse phases in a single block that might help to optimize the amount of time spent in any single ISR invocation, and it should also lead to more accurate timing of shaping pulses. That would mean moving the shaping_isr code inside of the do loop in pulse_phase_isr and interleaving shaping steps with every multi-step.

Outside of that more disruptive change, one minor optimization we could make would be to track the last pulse start time for each axis in a global structure, and then we could avoid adding unnecessary delays to any stepper in all procedures that use stepping. A straightforward way to do that would be to make a stateful AxisStepper class to represent all the stepper motors on a single axis, then refactor all code to use AxisStepper objects instead of going directly to the STEP/DIR/ENA pins. We could then produce an optimal model for each type of stepper driver and only apply the minimum delay required for each individual stepping event. If the added complexity is paid for with less time spent in the ISR it might be worth the extra calculations. … Something to contemplate for the next revision.

[classicrocker883]

I just came across in Configuration_adv.h

// Microstep settings (Requires a board with pins named X_MS1, X_MS2, etc.)
#define MICROSTEP_MODES { 16, 16, 16, 16, 16, 16 } // [1,2,4,8,16]

is this something that needs to be defined? I havent noticed the pins for Creality_V4 boards mention X_MS# so is this parameter necessary?

[oloendithas]

It would be easy enough to verify whether this is the cause. Change the code at the start of function Stepper::block_phase_isr() so that reducing multistepping is less responsive. Do this by playing with the condition time_spent_out_isr >= time_spent_in_isr + time_spent. e.g. something like:

So I've played with it. Tried:

if (steps_per_isr > 1 && time_spent_out_isr >= (time_spent_in_isr + time_spent) * **2**) {
if (steps_per_isr > 1 && time_spent_out_isr >= (time_spent_in_isr + time_spent) * **4**) {
if (steps_per_isr > 1 && time_spent_out_isr >= (time_spent_in_isr + time_spent) * **8**) {

That didn't changed anything.

Then I tried to play with this part:

    const hal_timer_t time_spent = HAL_timer_get_count(MF_TIMER_STEP);
    time_spent_in_isr += time_spent;

    if (next_isr_ticks < min_ticks) {
      next_isr_ticks = min_ticks;

      // When forced out of the ISR, increase multi-stepping
      #if MULTISTEPPING_LIMIT > 1
        if (steps_per_isr < MULTISTEPPING_LIMIT) {
          steps_per_isr <<= 1;
          // ticks_nominal will need to be recalculated if we are in cruise phase
          ticks_nominal = 0;
        }
      #endif
    }
    else {
      // Track the time spent voluntarily outside the ISR
      time_spent_out_isr += next_isr_ticks;
      time_spent_out_isr -= time_spent;
    }

Tried to set if (next_isr_ticks < min_ticks / 1.5) and this does change something: head moved slow with micro stuttering.
I have no idea, what conclusions can I make out of this. Hope this all means some thing to you.

[tombrazier]

@oloendithas I have another idea about this. I observed last week that just multistepping by iteself can make motors sound really noisy. May be the issue is not that the printner has been flipping between multistepping levels. Maybe it is just that it is going to a level that is noisy for your printer.

Could you try disabling the logic that reduces multistepping, i.e. comment out steps_per_isr >>= 1; in

  #if DISABLED(OLD_ADAPTIVE_MULTISTEPPING)
    // If the ISR uses < 50% of MPU time, halve multi-stepping
    const hal_timer_t time_spent = HAL_timer_get_count(MF_TIMER_STEP);
    #if MULTISTEPPING_LIMIT > 1
      if (steps_per_isr > 1 && time_spent_out_isr >= 2 * (time_spent_in_isr + time_spent)) {
        steps_per_isr >>= 1;
        // ticks_nominal will need to be recalculated if we are in cruise phase
        ticks_nominal = 0;
      }
    #endif
    time_spent_in_isr = -time_spent;    // unsigned but guaranteed to be +ve when needed
    time_spent_out_isr = 0;
  #endif

And then try different values for MULTISTEPPING_LIMIT to see whether there is some value that causes the noise.

[GenXEngineer]

Had noticed the increase in motor noise as well - it was nearly like going back to pre silent driver days. Even the probe on my CR touch was rattling just making the move to probe at 100mm/s. Tried all the fixes above but none made anything better. Made sure belts weren't too tight. They can certainly cause nasty vibrations when too tight. The vibrations were actually strong enough to show on the outer skin of prints. Bummer.

I'm using SKR mini e3v3 on upgraded Creality enders. I noticed that in the TMC driver submenu that motor driver step mode and max current can be adjusted. Played around with those. Made sure stealth chop was enabled. Creality motors max amp ratings are shown in the clip below. The nightly bug fix BTT config go by has all the motors set to 580ma. I played around with those numbers for each axis and found that (naturally) they have a dramatic effect on motor noise - especially when set too low. Anyhoo in the end I chose 780ma for all motors as that was FAR and away the quietest. Now everything is running silent again.

Please let me know if I did anything stupid! :) Motors are all running cool. Oh and on edit - I did set Multistep to 8 (tried all the way down to 1) but couldn't really tell a difference.

@tombrazier

[classicrocker883]

• I'll be posting supported firmware files for the BTT SKR Mini E3 for the ProUI (4.3" stock Aquila/Ender-3V2 color LCD) very soon.
• Configuration files for the SKR Mini E3 are posted in the source code as well.

I think that is the right idea. Increasing current is like (with Stock Aquila/Creality boards) changing the Voltage Reference. the downside with too little voltage/current is skipped steps - and from the sound of it - more motor noise.
the downside from too much voltage/current is running too hot, burn out the motor.

I really think the 42-34 stepper motors are much too undersized even for these printers. maybe not for the Z (with dual Z is fine), but especially for the Y axis... because this is the axis that moves the most Mass around. so naturally that calls for a larger motor.

I maybe said this before but I highly suggest anyone with these printers to upgrade their motors. stepperonline has a great deal - 3 motors for ~$20 bucks, Model:
3-17HS15-1504S-X1 42-40 motors like that of the Extruder. (technically they are 42-39).

anyway, say you want to upgrade to a direct drive... having a bigger motor will help the hotend having more weight, so you can use the same extruder motor and not worry with added weight. plus the shafts are a bit longer so you can add those nema 17 vibration dampers

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.