E3D V6 and custom thermistor curves

[Jozer99]

I'm getting fed up with the stock hot end, and am considering an E3D V6 swap. For the stock firmware, there are GCODE commands for reprogramming the thermistor curves to get proper temperature control. Does something like this exist for your firmware?

[aegean-odyssey]

No, the feature to select or somehow alter the thermistor curves is not part of the firmware. I've done some preliminary planning to include such a feature, but I'm afraid it's a long way off -- limited program space (flash) is the main constraint.

In the interim, here are some thoughts:

• It is not too difficult to set up a fork of the firmware and build (automatically) with Travis-CI. You can then edit (directly online) the thermistor selections in Configuration.h and build the firmware. The configuration change is the only change that should be required.

• Flash space is limited. The standard Marlin thermistor curves vary in size and more steps (attempting more "accuracy") may not be a better choice of a smaller size table. Also, compromising and choosing one curve for both bed and hotend can reduce the space requirements, as well.

Please post any progress you have, particularly the choice of thermistors, deficiencies of the firmware, etc. -- the things that would be good to keep in mind when planning future changes to the firmware. It will help steer the firmware development in a useful direction.

[Jozer99]

I'm not sure about the work required to implement it, but what about putting an optional thermistor curve on the SD card? For instance, if TCURVE.TXT is found, use it, otherwise use the default profile. If you want to store more in the firmware space, what about getting rid of the wifi functionality entirely.

In the mean time, a replacement stock thermistor isn't expensive, I can just use one of those in the V6 to avoid the issue.

[PurpleHullPeas]

The stock block/thermistor/heater will work with a V6 heatsink+throat.

However, I suspect the bigger culprit is the stock 12V 30W heater cartridge. Mine just died after some overly-aggressive testing at higher temperatures. I have some 12V 40W replacements on the way. Should be able to just redo PID tuning since I'm keeping the stock thermistor.

[aegean-odyssey]

@Jozer99, using the SD card's not a bad idea, especially as a place to store a library of thermistors profiles. But the limited program space makes it difficult to squeeze in even the code to read or update tables in such a scheme. (Currently WIFI is disabled, using up no space.)

Here's what I've been mulling over:

• The controller's 128k of flash is organized (more importantly, erased) in 2k blocks. The boot loader consumers 8k of flash and the firmware uses 2k of flash (1 block) to store settings as there is no eeprom.
• Though the settings do not fill the entire 2k block, if I put program there, then the printer's settings will always be erased during firmware updates. A better use for this free space in the settings area is for something that we don't want to erase with each firmware update -- like two thermistor curves, one for the bed and one for the hotend.
• The upside is that there is no additional overhead to directly use tables located in the settings area. The complications come with the overhead to restore a factory default, to make sure the table data is valid, and to write or install a particular thermistor table. Marlin avoids these issues by compiling the thermistor table(s) into the program.
• I think it would be possible to add a G-code that would implement a low-level read/write command for the area reserved for thermistors tables, and use some other tool to convert a thermistor table into a series of "write" commands using this new G-code. So, if there's program space to add such a G-code, then the ability to create a custom thermistor table can be realized.
• The issue of how to handle a "factory restore", I think, requires a separate mechanism to actually restore the thermistor tables to factory values, so an M502 (factory reset) would not by default erase a custom thermistor curve -- perhaps the added G-code above would include the ability to restore the thermistor tables to a known factory default.
• Checking for a valid table and what to do in the event of a (detected) bad table is additional functionality that will require more code space.

Truthfully, none of the things are all that difficult to implement -- until there's no more room for the program, then it's a mess. Currently there are a few hundred bytes of unused program space as I've been able to reclaim some space along the way by optimizing a bit of the original Marlin code. There may be some more optimizing with the thermistor tables, so that adding a custom thermistor table feature can be close to a "space neutral" proposition -- it will need to be in order to be successful.

[aegean-odyssey]

@Jozer99, you know, another possibility is to rework Marlin's thermistor table implementation so that the tables are a fixed size and located at a fixed address in the firmware image. It would then be possible to create a tool to "patch" the firmware.bin file with custom thermistor curves prior to installing it on the printer. This strategy eliminates the complications mentioned in my previous comment. We just need to be able to fit two thermistor tables in the program space.

[Jozer99]

What about implementing a best fit function for restoring the default thermistor tables? Thermistor curves should fit a 4th order polynomial where 1/T = f(log(R)). This would reduce the table down to four polynomial coefficients, plus whatever code you need to regenerate the standard table upon a reset to defaults. Given the variability between individual thermistors, the fit function probably wouldn’t be any less accurate than the default table.

[aegean-odyssey]

@Jozer99, yes, good point. Converting forward and back, is about 80 bytes worth of coefficients for two thermistors, plus whatever extra code is needed to implement the calculation. Could work.

The current table contains 64 entries (256 bytes!) and is shared by both the hotend and the bed. I think splitting it into two tables with 32 entries each should be more than adequate for tables if one takes some care when approximating the thermistor curve.

I guess the first step is the come up with tables and give it a try.

[aegean-odyssey]

Also, I think this discourse is a good candidate for Github's "discusion" feature. Please bear with me as I try to move it under the "Discussions" tab.

[aegean-odyssey]

@Jozer99, your comment about the accuracy of the tables and storing only coefficients, etc. got me thinking seriously about trying to optimize Marlin's temperature control stuff. I did a little work to see if creating a smaller table (by smartly reducing the number of line segments) is feasible -- I think it is and there's a good chance that it will be more "true" than the existing implementation, in the sense that the curve fit is accurate and that lookup calculations keep more significant digits in the measuring and calculating process. The worksheet and resulting table "include" file are attached.

thermistor.wxmx.pdf
thermistortable_1.h.txt

If tables can be produced by reading a few numbers from a datasheet or by making a few temperature measurements with the printer, then I think it's worthwhile to restructure the Marlin code to always use a custom table (say, 998) for the hotend and a custom table (say, 999) for the bed -- initially filling both tables with a standard table. It's not the complete solution yet, but moving in this direction sets the stage to actually be able to use custom thermistor tables.

Also, looking at the equations, it is tempting to think about merely storing coefficients. Only one log() computation is needed, log(1/(1-x)), and a handful of coefficients. But besides maybe a speed issue, I don't think the single precision floating point math would perform well in this approach. The lookup table in this case may actually be faster and more accurate.

I think I'll try to incorporate these ideas into the next firmware release.

[BackwardEcho]

Hope you don't mind me becoming a necromancer and reviving this dead thread, I was just wondering if being able to change the thermister settings has been implemented yet as I didn't see mention in the change logs.

[BackwardEcho]

And if I can throw my 2 cents into this, I read earlier that there was a dilemma with choosing which table to save to eeprom between factory resets: keep the stock table but maybe have a custom gcode parameter, like the cold pull or the probe compensation, that instead either has the firmware read a temperature table text file or allows the user to manually add values like how a bed level mesh is saved. I'm thinking it might be better to have it read from a file that overwrites the what's compiled in the firmware for the sake of space in the program.

edit: oh, after rereading i see it was mentioned already. tired brain, sorry.

[Jozer99]

Just in case anyone was curious, I ended up avoiding this issue entirely by finding a thermistor with identical properties to the stock EPCOS 100K one, but in a cartridge form factor used in the V6 hot end. Its probably not quite as high quality as the 104NT ones used by E3D, but it works well enough, and it greatly simplified the hot end swap.

I recommend doing a swap of all the hot end parts, either a v6 or something else. The quality of the stock hot end is absolutely abysmal, and the hot end is really where quality matters, when it comes to reliable operation and quality extrusion. If I were to redo the swap today I would consider something more compact, such as one of the high quality aftermarket Creality style extruders. The V6 is large and difficult to mount in the space available in the MPMD.

[BackwardEcho]

Where did you find the new thermistor? (do you have a url?) I have no idea what the exact specs are of the stock hotend so I was thinking of getting some thermal paste to flood the hole for the thermistor to jank the hell out of the "form factor". I have a cloned v6 that was mistakenly sent to me, but I have no clue what the thermistor that came with it even is regarding specs.

I would consider the E3D Revo, specifically the Voron version for its rigid mounting, if I wanted to toss a LOT of money on a single part.