How to use M915 T parameter
-
@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.
-
@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
-
@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.
-
@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. -
@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.
-
@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!
-
@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
-
@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.
-
@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.
-
@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.