Fix M914 Sensitivity Input & Misc Fixes

[AbsoluteCatalyst]

The M914 S has some strange/confusing behavior but I can't remember if it's intentional. I also don't remember why I did the -128 check when I helped pull in 2209 support a year ago.

Right now: If we input a value beyond min/max (-64 - 63), we're blocked from changing it again and it's hidden from eeprom until reboot.

I changed it so that: If we input the lowest value sensitivity (0 for 2209, 63 else) it won't do the beforehoming diag pin procedures. Eeprom setting doesn't hide anymore.

Misc:

• Fixed some small inconsistencies in the print reports.
• Added missing [steps/mm] units to tEPRStepsPerMM
• Blocked print reports if unconnected, this would sometimes give us incorrect/weird values.
• GCC hints that init() wasn't being devirtualized. I marked them final since nothing derives these atm.

If there's anything wrong with these let me know I'll revert the change

[repetier]

-128 is the flag that no stallguard is wanted. inline bool hasStallguard() { return stallguardSensitivity != -128; }

So the main error is that M914 allows setting it to -128 on wrong values. That will disable it permanently also it was not intention on compile time. Also since this is if set aim it is consequently hidden in eeprom in that case.

But correct solution would be to not set it in M914 in that case. The other cases are required.

So can you please adjust the code.

[AbsoluteCatalyst]

Okay, reverted and put it back in.

[repetier]

Ok, that should work.

BTW: I had problems with my TMC2130 - they reported overtemperature also they were not enabled, had no main power and were cold. When I added main power the overheating stopped happening. Does not make much sense to me, but this made the current set get reduced to 100mA. So as an intermediate or maybe permanent solution I had added the constrain that driver must be enabled or overtemperature gets ignored.

Do you have an idea why this happens? Did not happen on all drivers but several. Maybe status read is random when not enabled, but that would be a bad idea.

[AbsoluteCatalyst]

I've not had that exact problem, but similar. I saw your enabled commit, I think that might be a good permanent solution. They all seem to have some bad behavior when unpowered.

For me, if I connect this SKR board to USB only, and then main power; all their settings are reverted to stock (microsteps, current) and it's impossible to update them until rebooted again on main power. This is bad on the SKR because the stock current is 1200mA~

Reporting overtemperature is quite odd though. Does it always happen when not main powered?

[repetier]

So enabling main power on skr resets the drivers over some reset pin? Should also not happen.

On my delta it happened always when unpowered but not on all drivers and also with different frequency. x was stable, y had most reports but z and e also did happen from time to time.

Since enable is own function in class anyway, would reinitializing on first enable be a solution? That is the first point we need the drivers. Would also like a method to detect if we have main power but I see no cross board solution here. With that we could do things like home on power or prevent setting temperatures instead of failing due to missing power.

[AbsoluteCatalyst]

That could be the right solution to it.

I have to check, but I remember that the datasheet mentioned something about this. I think enabling the drivers, then disabling them, then re-enabling them again was the way to get them out of this funky state and would allow proper reinitialization. (on - off - on) I might be wrong, I can't find it anymore.

For detecting power, my drivers do report that they're unpowered, but besides that; perhaps monitoring the voltage ADC channel on stm32's for changes? No idea for the due.