How to use M915 T parameter

NeoDue

@gloomyandy Wait a second... you are right. M915 just covers the lowest 16 bits of the COOLCONF register which is indeed CoolStep current reduction and nothing else, and with the Duet having much better cooling than the original controller (and additionally monitoring what little information the TMC steppers tell about their temperature) I won't need that at all.

And the upper bits (which might be interesting to detect a stall) are set with M915 S and F.

In that case M915 T is not relevant for me, apart from academical curiosity. Thanks for pointing that out!

NeoDue

@gloomyandy Okay, I just started a print with the M915 command removed but StealthChop enabled - and now I remember why I had set M915 T1 initially: it helps quite a bit in silencing the printer (Stealthchop silences motions, M915 T1 silences acceleration at the beginning and the end of a move), even if I had not understood before what it actually does.

That means I need to take another look at that - and would it be possible to get the described procedure above confirmed, including the suspected bit direction of the binary number?

Additionally, one more question: since rc2 and rc1 on the 6HC are said to be affected by the bug that M915 was written to the stall sensitivity register, I wonder why setting M915 T1 actually did something on my printer - and why it still does the same on the RC2+ version @dc42 posted in the "input shaping causes layer shifts" thread...? Could you point me to someone who knows more about this or to the Github change behind that?

gloomyandy

@NeoDue The github change was only very recent and I'm pretty sure the fix is only in rc3. The commit is here: https://github.com/Duet3D/RepRapFirmware/commit/cabb0d6a99ae532a914d6c3f24977b5269439a8d

I'm not convinced that with the old code that the call you were making was doing just what you think it was. It may have had a side effect of changing the noise, but it was basically changing the value of TCOOLTHRS which is not the stall detect threshold (it plays a part in this, but it is not the stall detect threshold that is set by the sgt bits in the COOLCONF register). If you look at what TCOOLTHRS actually does it controls both stall detection, CoolStep and also impacts the PWM control of the voltage to the stepper (which is part of StealthChop). It also interacts with various other settings. Given that some of these are changed by RRF in various situations I'd be careful of messing with these values without very careful reading of the datasheet and the RRF code.
<img src="blob:chrome-untrusted://media-app/120a7962-8254-4453-9ae7-5c8c32116da0" alt="Screenshot 2024-01-27 13.50.20.png"/>

0

dc42 committed to Duet3D/RepRapFirmware

Fixed M915 T parameter on TMC2160/5160

NeoDue

@gloomyandy thanks! That means I a) need to check what the old code does with reading the data with M569.2 and b) set whatever it does to reduce noise again since there is no other way to set tcoolthrs (assuming the old code actually had set that...) with that change being implemented.

NeoDue

@gloomyandy okay, M915 with a T1 does not seem to affect register 0x14 which should contain tcoolthrs on the 5160 - an M569.2 P0.3 R{0x14) gives a zero both before and after sending an M915 P0.3 T1 command.

I guess I need to read out all the registers to find out what I did... but that will happen tomorrow

By the way, while checking if I understood M569.2 correctly, I might have found another small documentation issue - the M569 Y parameter does not seem to take the offset of hend and hstrt into account.

Edit: fixed typo

gloomyandy

@NeoDue Which version of RRF are you using to test this? If you are using rc2 I would have expected you to see a change to register 0x14.

@NeoDue said in How to use M915 T parameter:

M915 with a T1 does not seem to affect register 0x14 which should contain tcoolthrs on the 5160 - an M569.2 P0:3 R{0x14) gives a zero both before and after sending an M915 P0:3 T1 command.

NeoDue

@gloomyandy Well, I expected that as well,
For now, my printer is still running the rc2+ version dc42 had provided I guess I will keep that one until I am told to install something else in the input shaping issue thread.

gloomyandy

@NeoDue Unfortunately the TCOOLTHRS register at address 0x14 is a write only register (see the table above), and so will always return a value of 0 if you attempt to read it.

NeoDue

@gloomyandy Write-only?? Indeed... I was not aware that such registers even exist, anything I had in my hands up to now and wanted to read was either locked, read-only or read/write.

Thanks a lot for that hint, you saved me quite some fruitless work!

NeoDue

@gloomyandy Okay, retried, this time with comparing the resulting effect of the M915 P0.3 T1 command with the one of an M569.2 P0.3 R{0x14} V1 command (also tried V{0x00000001} in case a hexadecimal value might be needed).

Whatever M915 T1 does on the older firmware, it is not the same as writing the same value with the M569.2 command into the TCOOLTHRS register

Are there any calculations made with the T1 value of M915 before it is written?

Edit: fixed typo

NeoDue

@gloomyandy ... and yet another update: the M569.2 command works after all - but it depends on where you enter it:

if you use the console of a PanelDue, it does nothing. This is what I tried first. (Edit - found the reason: it definitely helps to type in the command correctly )
if you use the console of DWC, setting the value to 1 works. ~~Setting it back to its default 0 however does not.~~ But whatever the default value is, it is not 0.

gloomyandy

@NeoDue What makes you think the default value is 0? 0 is and was the default value for COOLCONF, but the "default" value (i.e. the value that RRF will set when it boots) for TCOOLTHRS. The value set by RRF is equivalent to setting a M915 H value of 200 (which ends up being the hex value 0xea).

As I mentioned above I'm not sure that it is a good idea adjusting these values unless you understand exactly what the consequences are. This is particularly true given that you are seeing layer shifts. I think you did test for layer shifts with the M915 settings removed, but if not it would probably be a good idea to do so.

NeoDue

@gloomyandy said in How to use M915 T parameter:

@NeoDue What makes you think the default value is 0? 0 is and was the default value for COOLCONF, but the "default" value (i.e. the value that RRF will set when it boots) for TCOOLTHRS. The value set by RRF is equivalent to setting a M915 H value of 200 (which ends up being the hex value 0xea).

You are right, I had your post https://forum.duet3d.com/post/332054 in mind, but that one is about COOLCONF.

As I mentioned above I'm not sure that it is a good idea adjusting these values unless you understand exactly what the consequences are. This is particularly true given that you are seeing layer shifts. I think you did test for layer shifts with the M915 settings removed, but if not it would probably be a good idea to do so.

Yes, I fully understand that, and as I had noted in the layer shift thread, I did testing without these as you had asked me in this post. (Apart from that, this value does only affect StealthChop behaviour, therefore it should be ignored as soon as I switch to Spreadcycle)

Technically, I see this setting as follows...
The datasheet says:

TCOOLTHRS ≥ TSTEP ≥ THIGH:
- CoolStep is enabled, if configured
- StealthChop voltage PWM mode is disabled
TCOOLTHRS ≥ TSTEP
- Stall output signal (DIAG0/1) is enabled, if configured

CoolStep and Stall output is not configured on my printer, therefore these two settings are not of interest.
But since thigh is set to 5 on my printer to ensure TSTEP ≤ THIGH does not happen (again, I had disabled this for the input shaping test when you asked me to), I need to set tcoolthrs to a value below 5 to ensure the case "StealthChop voltage PWM mode is disabled" never happens. This seems to be the same behaviour as the TMC2209 of the original controller board works (edit for clarification: but there, without having to set tcoolthrs) - tcoolthrs works different there if I trust the datasheet.