Temperature singleton

[thinkyhead]

Following #3631 – Adding in a singleton called "Temperature". Let's see how Travis likes it.

[ghost]

Is void Stepper::digitalPotWrite(int address, int value) { right? (same comment in PR #3631)

[thinkyhead]

@jbrazio What do you think? Should I leave the temperature singleton named "temperature", use the capital "T" name, or choose something else (thermal)? The word temperature just doesn't sound like a "thing" so I don't "love" it, semantically-speaking.

[Blue-Marlin]

For me it looks as if we are (or should be) dealing with a 'Heater' and its properties.

[thinkyhead]

Well, in geekspeak this class is a "manager" of heaters and sensors. It does not model a heater.

And I actually don't want to go down the road of turning every entity (for example, individual heaters) into classes at this time. But in future…

[Blue-Marlin]

Well said. We already are on dangerous train with this and some other PRs of the last days - for an RC.

[jbrazio]

@thinkyhead If this is and will be the responsible for all temperatures on Marlin then I would suggest ThermalManager or ThermalManagement which ever sounds better to a native speaker. In the future we model the heaters and coolers objects who will be managed by this one.

I not keen to use "short cryptic names" (despite "T" being rather a standard convection).

@Blue-Marlin so far Scott has been doing refactoring by changing function names and encapsulating which does not changes behavior.

[thinkyhead]

which does not change behavior

True, though I can understand the concern with the way the Arduino compiler has acted up in the past, and of course how easy it is to miss a subtle typo. I made a point to avoid trying to be "clever" and rewrite any code. I think if you look through this PR (and I hope everyone has scanned it for stupid errors) you will find it is especially cautious.

What I wanted for this PR was to corral the variable names into their own namespaces and make it more obvious what belongs to what, but without changing anything else. It makes the code a bit more readable, the ownership of properties more clear, and (I hope) leads to clearer thinking about the relationships between these code units. The main errors that I found with Travis were symbols that didn't get the prefix added.

I've been running this code on my own machine and it seems to be working well. I haven't compared the print results from 1.0.2-1 to RCBugFix, so if there are any subtle printing issues (with corners, for example) indicating behavior changes, I cannot say. My prints have come out very good.

[Blue-Marlin]

@jbrazio
Count the follow-ups of #3631 to see what I mean.

[thinkyhead]

Count the follow-ups of #3631 to see what I mean.

I expected some followups to catch missed symbols. Considering the scope of the change, it's not too bad. I will take the time to do a full search on all the method and symbol names to see that nothing else was missed. Regular expression searches help this a lot. To find a symbol missing a dot prefix (or underscore) simply use regex [^\._a-zA-Z]symbol_name and ignore those within the class itself.

Thanks to those of you (@esenapaj) who actually took the time to "science the shit out of this thing," examine at the code and see if it was good, bad, or otherwise. I realize it seems cold and scary when seen from a great height, but when you really get to know it, it's actually quite warm and fuzzy.

[thinkyhead]

Ok, so I went through the same process as @esenapaj did with Stepper/Planner, searching all the symbols in the Temperature class to make sure they're properly prefixed. This is totally patched up now!

If anyone would like to prove that assertion wrong, I challenge you to find a bug in this. If you do, I give you one paragraph to tell me off, but no more. Time is short.

I'm trying the name heatManager on for size. How does that look and feel to the other code-heads? I resist using tempManager because temp tends to imply "temporary". But here are some other names that might be just as good or better… or worse…

• tempControl …… as in tempControl.autotempShutdown()
• heatingMgr …… as in heatingMgr.degBed()
• thermal …… as in thermal.setTargetHotend(180, 0)
• thermals …… as in thermals.setTargetBed(70) (of course, "thermals" are long underwear)

[jbrazio]

@thinkyhead I vote for:

thermalManager.autoShutdown();
thermalManager.getBedTemperature();
thermalManager.setBedTemperature();
thermalManager.setHotendTemperature();
thermalManager.getHotendTemperature();

of course, "thermals" are long underwear

The things a non native English speaker learns on a coding website. :-P

[thinkyhead]

s/temperature\.([a-zA-Z_]{4,})/thermalManager.$1/ it is, then.

[thinkyhead]

May The Force be with this PR. ⚡