Does M906 set RMS or peak current?

wilriker

@dc42 said in Does M906 set RMS or peak current?:

PS - the default chopper configuration register value is:

// Chopper control register defaults

// 0x901B4 as per datasheet example

// CHM bit not set, so uses spread cycle mode

const uint32_t defaultChopConfReg =
TMC_REG_CHOPCONF
| TMC_CHOPCONF_TBL(2) // blanking time 36 clocks which is about 2.4us typical (should maybe use 16 or 24 instead?)
| TMC_CHOPCONF_HDEC(0) // no hysteresis decrement
| TMC_CHOPCONF_HEND(3) // HEND = 0
| TMC_CHOPCONF_HSTRT(3) // HSTRT = 4
| TMC_CHOPCONF_TOFF(4); // TOFF = 9.2us

Do the drivers use their internal clock at 15Mhz or is an external clock used as recommended in section 13 of the datasheet for TMC2660? And if the latter is the case what frequency does it have?

dc42

The drivers use the internal clock. We were originally going to use an external clock, however the drivers would be likely to blow up if the clock failed for any reason (e.g. because you flashed bad firmware to the Duet); so we reverted to internal clock.

wilriker

@dc42 Yeah, I just read the big fat warning about external clocking being turned off (out of whatever reason) without taking the necessary precautions... They say on the one hand, if you need the most precise chopper, using external clock - but that makes it prone to blow up also...

wilriker

@dc42 Section 2.2 of the Parameterization of spreadCycle document says

Use highest possible microstep resolution for your tests.

Should I use native 256 microstepping or would this also work with 16+interpolation?

dc42

@wilriker said in Does M906 set RMS or peak current?:

@dc42 Section 2.2 of the Parameterization of spreadCycle document says

Use highest possible microstep resolution for your tests.

Should I use native 256 microstepping or would this also work with 16+interpolation?

I suggest you work with x16 with interpolation, because that is what most people use.

The particular issue that some users have is that the drives are noisy at standstill. Section 2.4 of the app note suggests reducing TOFF in this situation.

wilriker

@dc42 OK, I will further read the document and will test over the next couple of days and then report my findings.

The particular issue that some users have is that the drives are noisy at standstill.

Should I set the standstill current via M917 to a specific value for this?

An interesting note in Table 1 says that current in standby could even be reduced to 0 depending on the setup. I saw that M906 allows a range of 0..100 for the I parameter. Will using 0 really set idle current to 0mA? That would be basically the same as using M18/M84 just without requirement to rehome (given enough trust in the positions not having changed out of any reason).

dc42

Setting standstill current with M917 doesn't yet work on the Duet 2. But you might want to temporarily increase the idle current to 100% in M906 so that the motor current doesn't get reduced after 230 seconds of inactivity, making the standstill noise easier to hear.

Setting M906 I parameter to zero will reduce the current to 100mA.

wilriker

@dc42 said in Does M906 set RMS or peak current?:

Setting standstill current with M917 doesn't yet work on the Duet 2. But you might want to temporarily increase the idle current to 100% in M906 so that the motor current doesn't get reduced after 230 seconds of inactivity, making the standstill noise easier to hear.

I have my timeout even reduced to 15s. Which reminds me of another question that came to my mind: is idle current reduction also applied while printing (from SD card)? I ask because that might mean that with this rather short timeout I have set it would reduce the Z motors to idle current for any layer above 10mm height (mesh level taper) that takes longer then my timeout.

Setting M906 I parameter to zero will reduce the current to 100mA.

OK, I will add this to GCode description so it will be known when reading documentation about M906

dc42

@wilriker, the idle timeout only takes effect when all enabled motors are idle for 30 seconds, or whatever you have the timeout period set to. So the only time it should happen during an SD card print is while heating up.

wilriker

@dc42 I just wrote a little tool in Go to create me the integer required for M569 Cnnnn based on a more human-friendly input. I used the macros in TMC2660.cpp as a basis but decided to allow only exactly the values as specified in Trinamic's documentation, e.g. 16, 24, 36 and 54 for TBL which should make it a little less brain-twisting when working with their guide.

I have to check an issue with motor stall detection on low Y positions first that my today's print spit out a lot but after that I can start looking into CHOPCONF register.

EDIT: can this value be set live or do I need to set them in config.g and restart?

dc42

You can set the value live.

wilriker

@dc42 OK, my results so far: we are already at the more or less best values.

Test Setup

Motor: 42SHDC3025-24B

Axis: X
Step Angle: 1.8°
Rated current: 900mA
Resistance: 4.4Ohm
Inductance: unknown - estimated to 8-10mH
Rated torque: 40Ncm

Motor current set to 400mA with idle current reduction disabled (by setting it to I100)

Standstill noise is clearly audible and a high pitched sound.

Results invalid, see post(s) below.

Results

Moves

HSTRT/HEND
I could get a little bit quieter moves on some circumstances and listening angles/distances when setting HSTRT=5 and HEND=0 (for clarification these are the values that will be put into the macros of the C++ code). But the difference is very faint.

Standstill

TOFF
Regarding standstill noise, I could not find any combination that was quieter. TOFF starting from 8 or 9 up to 15 gets worse with every step but below that they are all about the same, so reducing this from 4 to 2 does not make any audible difference.

rndtf
I also tried enabling rndtf but that makes it very minimally worse or equal at best but definitely not better.

TBL
Also tried all values of tbl but the current value of 2 already gives best results regarding noise level.

Any idea what else to test?

wilriker

@dc42 I only now realized that my X motor nearly does not give off any standstill noise. It were my Z motors I was hearing all the time because I did not disable them while testing. I will need to retest and come back with new results.

wilriker

So, this was a rather quick one because currently I have some mechanical squeaking on my Z axis, so I cannot really test movement noises.

TOFF
For standstill noise setting TOFF=3 makes a noticable difference towards being more silent and a less annoying frequency. All other values are either equal to a value of 4 or are definitely worse.

TBL
TBL=2 is already the best value.

rndtf
Enabling rndtf this time makes it noticeably worse.

Conclusion

Reducing TOFF to a value of 3 will definitely go into my configuration for Z axis.

wilriker

I now also tested all other axes.

Best values for TOFF per axis:

X: 6 (makes it inaudible in standstill)
Y: 3 (large improvement)
Z: 3 (large improvement)
E0: 4 (current default) even though 9 also gives a quite good result

So it might be interesting to provide a dedicated parameter for TOFF to either M569 or M906 (or maybe M917?) so everyone could work out the perfect values for themselves without having to fiddle around with bitmasks.

I will have to retest values fo HSTRT/HEND for all axes again tomorrow.

wilriker

I just precalculated all (valid) combinations of HSTRT+HEND for all axes and uploaded 400 macros to the Duet via a remote connection - the UI was clearly never meant to do that.

wilriker

Another step done:

`HSTRT, HEND` and Standstill Noise

I played around with HSTRT and HEND. Main regard here as well was standstill noise.

Generally I can confirm my findings above that MSTRT=5, MEND=0 gives best or at least equal noise level except for extruder. For the extruder MSTRT=4, MEND=4 was the best value I could find.

General rules found while testing:

MSTRT >= MEND gives least noise
MEND >=8 is usually very noisy and annoying

`HSTRT, HEND` and Movement Noise

I only tested X and Z so far regarding movement noise and vibration and also my initial findings for Z stand that MSTRT=5, MEND=0 is equal to very slightly less noisy compared to current default of 3 and 3.

For X though I could not find a value that gives less noise on very slow movements than 3 and 3.

Basically these settings mainly influence noise level of very slow movements. I usually test them with G1 ... F1 - which is rather unusual for printing except maybe really with Z when Mesh Bed Compensation is active.

dc42

Thanks for your excellent work! I've added a TOFF parameter for M569 to the work list for firmware 2.01.

wilriker

@dc42 You're welcome! Was fun to experiment with that a little bit.

Having a separate parameter will definitely make the config.g file (or more precisely the M569 commands) a lot more understandable without a comment.

wilriker

For Reference

@dc42 said in Motor Whine/Loud Movement:

Could you provide chopper configuration values for various TOFF values, so that users who only need to change TOFF can try them?

Of course:

TOFF=0 -> M569 C65968 (this means motors are off!)
TOFF=1 -> M569 C65969
TOFF=2 -> M569 C65970
TOFF=3 -> M569 C65971
TOFF=4 -> M569 C65972
TOFF=5 -> M569 C65973
TOFF=6 -> M569 C65974
TOFF=7 -> M569 C65975
TOFF=8 -> M569 C65976
TOFF=9 -> M569 C65977
TOFF=10 -> M569 C65978
TOFF=11 -> M569 C65979
TOFF=12 -> M569 C65980
TOFF=13 -> M569 C65981
TOFF=14 -> M569 C65982
TOFF=15 -> M569 C65983

You'll have to add at least the Pnnn parameter to specify the motor.

I have written a small tool to create the values for the Cnnn parameter that takes into account all possible sub-values:
The source code as well as three precompiled binaries for Windows/Linux/Mac AMD64 have been uploaded to https://github.com/wilriker/chopconf-generator (binaries can be found at https://github.com/wilriker/chopconf-generator/releases).

There is also some very short usage description.

There is now a page at the wiki Reducing Stand-Still Noise.