This module reads temperature reading sensors ( thermistors ) and uses heater and cooler elements to maintain a set temperature.
This is used for example for extruder hotends, or heated beds.
In Smoothie you do not get just one TemperatureControl module. You can actually create as many as you want, simply by adding them to the configuration file.
It goes something like this :
temperature_control.hotend.enable true temperature_control.hotend.thermistor_pin 0.23 etc ... temperature_control.bed.enable true temperature_control.bed.thermistor_pin 0.24 etc ...
This will create and configure two separate TemperatureControl modules that will act completely independently from each other.
The line that effectively "creates" the module is the enable option. If set to true, a module is created and further configuration is read. If set to false, further configuration for this module is ignored as no module is created.
In the Configuration section bellow, the first two parts ( temperature_control.module_name ) of the configuration are sometimes omitted for conciseness, but have to be added in your actual configuration file ( see example ).
All configuration options
Here are all the possible configuration options for your TemperatureControl modules
|temperature_control.module_name.enable||true||Whether to activate this temperaturecontrol module. You can create as many temperaturecontrol modules as you want, simply by giving a new module a name, and setting it's enable option to true|
|temperature_control.module_name.thermistor_pin||0.23||Pin for the thermistor to read. ADC ports TH1 to TH4 are pins 0.23 to 0.26.|
|temperature_control.module_name.readings_per_second||20||How many times per second to read temperature from the sensor.|
|temperature_control.module_name.pwm_frequency||2000||How many times per second to switch the heating element on or off. Set to a low value ( 20 ) if using a Solid State Relay.|
|temperature_control.module_name.heater_pin||2.7||Pin that controls the heater. This can be used to control a Mosfet on board or an external Solid State Relay. Set to nc if a readonly thermistor is being defined|
|temperature_control.module_name.thermistor||EPCOS100K||Set the thermistor model for this module. Several different common models are pre-defined, see here for a list|
|temperature_control.module_name.beta||4066||Manually set the beta value for your thermistor. This is useful if your thermistor is not in the common pre-defined models.|
|temperature_control.module_name.r0||100000||Manually set the r0 resistance value for your thermistor. This is useful if your thermistor is not in the common pre-defined models. Besides beta and r0 which are properties of your thermistor, you can also set the r1, r2 and t0 values, but those are properties of your board so they usually never have to be changed.|
|temperature_control.module_name.get_m_code||105||Calling this M-code will return the current temperature.|
|temperature_control.module_name.set_m_code||104||This is the M-code for simply setting the temperature. For example here, the value is 104 so you use M104 S50 to set this module's heater's temperature to 50.|
|temperature_control.module_name.set_and_wait_m_code||109||This is the M-code for setting the temperature then waiting for that temperature to be reached before doing anything. For example here, the value is 109 so you use M109 S50 to set this module's heater's temperature to 50 and then wait.|
|temperature_control.module_name.designator||T||The letter this module's temperature will be identified as in the M105 command's answer. For example here the value is T, so M105 will answer ok T:23.4 /0.0 @0|
|temperature_control.module_name.p_factor||13.7||P factor for PID temperature regulation|
|temperature_control.module_name.i_factor||0.097||I factor for PID temperature regulation|
|temperature_control.module_name.d_factor||24||D factor for PID temperature regulation|
|temperature_control.module_name.max_pwm||64||Maximum PWM value for the heating element. This can be from 0 to 255 . 64 is a good value if driving a 12v resistor with 24v. 255 is the default and the normal value if you are using the right voltage for your heating element.|
|temperature_control.module_name.bang_bang||false||Set to true to use bang bang control rather than PID|
|temperature_control.module_name.hysteresis||2.0||Set to the temperature in degrees C to use as hysteresis for bang bang control|
|temperature_control.module_name.i_max||64||Maximum value for the I variable in the PID control. This should usually be set to about the same value as max_pwm ( as a rule of thumb, it is not actually a pwm setting ). This helps with preventing overshoot when initially heating up. If you get a strong ( >10°C ) overshoot on startup, try setting this to a value lower than max_pwm|
|temperature_control.module_name.sensor||thermistor||Set the type of sensor used to read temperature. Values can be thermistor for the usual thermistor reading via ADC method, or max31855 to read values from a thermocouple over SPI. See Reading a thermocouple|
|temperature_control.module_name.chip_select_pin||0.16||If the sensor is set to max31855, sets the chip select pin for the SPI port. This allows you to have multiple sensors sharing the same SPI port, as long as they each get a chip select ( CS ) pin.|
|temperature_control.module_name.spi_channel||0||If the sensor is set to max31855, SPI channel using which to talk to the thermocouple chip.|
|temperature_control.module_name.max_temp||100||If set, no temperature above this will be accepted and if the temperature exceeds this value the system will be forced into a HALT state.|
|temperature_control.module_name.runaway_heating_timeout||120||If we take longer than this many seconds to heatup, the system will be forced into a HALT state. Set to 0 to disable it. default is 900 seconds|
|temperature_control.module_name.runaway_range||20||If set to non-zero, and the target temperature is reached, and temperature diverges from the target temperature by more than this, the system will be forced into a HALT state.|
A given controller board only has a given number of ADCs ( analog ( temperature ) to digital ( Smoothie ) converter ) capable pins.
On the smoothieboard for example, there are 4 thermistor inputs, labelled from T0 to T3, and corresponding in the same order to the pins 0.23 to 0.26. T0 is usually used for the hotend, and T1 for the bed.
Thermistor inputs are not polarized, the direction you connect them in on your board is not important.
|Smoothieboard thermistor input name||T0||T1||T2||T3|
|Pin for configuration||0.23||0.24||0.25||0.26|
Choosing the right thermistor
There are different models of thermistors. Each hotend or heated bed has one, and it's a specific given type. Different thermistor models translate a given temperature into different resistances. This means you must tell Smoothie which exact thermistor model you have, to be sure Smoothie can read it correctly.
This is done using the thermistor option in the configuration file. You pass it the name of your thermistor, and it will configure the math correctly accordingly.
Smoothie does not know the name of all the thermistors in existence. At the moment these are the ones it knows about:
|Name||Beta for 0-80°C||Beta for 185-230°C||I for Steinhart Hart||J for Steinhart Hart||K for Steinhart Hart||Part number|
In case you have a thermistor that is not known to Smoothie you can simply define the parameters in config. There are two methods, using the beta value ( good but not perfect ), and using the Steinhart Hart algorythm ( perfect ).
Using beta values :
Set the beta value in the configuration file :
temperature_control.hotend.beta 4066 # set beta for thermistor
About beta values
The betas published by most manufacturers, are for the 0-80°C range.
For the 185-230°C this results in readings being about 7-10°C too high.
This means beta values are usually good for a heated bed, but not for a hotend.
If the thermistor is 100K ohms at 25°C then this is usually enough.
You can also set r0,t0,r1,r2 but this is not usually needed as the defaults are sufficient.
If you do not know what thermistor model you have, contact the designer or seller of your 3D printer, hotend or heated bed and get the spec which will tell you what the beta value is for the thermistor.
Using the Steinhart Hart algorythm :
This is the recommended method. Set the parameters in the configuration file :
To find what the Steinhart Hart coefficients for a given thermistor are, please read the SteinhartHart page.
If you have the temperature curve for your thermistor, you can also define three points on that curve, and let Smoothie calculate everything :
Note PT100 is not supported in current edge, a Pull request exists for it which needs testing
Thermocouple via SPI
Thermocouples are currently supported by connecting a MAX31855 chip to one of the SPI channels. Thermocouples give a stable measurement over a wide temperature range, and can typically withstand higher temperatures than thermistors.
Note: Connecting a thermocouple and an LCD panel to the same SPI bus does not work.
Here is an example of how to connect the Adafruit Thermocouple Amplifier MAX31855 breakout board to the smoothieboard.
|0.18 MOSI||Not used|
To configure smoothie to use the thermocouple connected like this, replace the thermistor and thermistor_pin parameters with the following:
The SPI channel and chip select pin can be changed using the following parameters:
temperature_control.hotend.chip_select_pin 0.16 temperature_control.hotend.spi_channel 0 # SPI channel 0 or 1
Thermocouple via Amplifier
Smoothie supports reading thermocouples via an ADC ( the same kind used to read thermistors ) if the analog value is converted by the AD8495 thermocouple amplifier.
This allows you to read values from a thermocouple without having to use a SPI port.
To use the AD8495, you need to set the right sensor type :
And then configure the pin you'll be using to read the sensor :
And the offset :
Heating things up.
To reach the desired temperature, you need a means of changing the temperature. This is usually done by letting current through :
- Heater cartridges
- PCB, kapton or silicone heater plates
This is for example how hotends or heated beds are heated to their target temperature.
This is controlled from the board running Smoothie using a GPIO pin.
In the case of mosfets, on a [[Smoothieboard]], a given pin is connected to a given mosfet, and you have to use that specific pin to control that specific mosfet.
See this schematic bellow or on the Smoothieboard page to see what mosfet corresponds to what pin.
Read more about the mosfets here
To set a pin to a given heater, do for example :
Note on pins :
A "pin" is an input or output on the Smoothieboard.
In a lot of cases ( step/direction for external stepper motors, button inputs ), you can use any pin for any use.
If other cases, a given pin is tied to a given peripheral on the board.
See Pinout to learn about which pins are where.
You can have a pin's output inverted by adding a "!" after this pin's number in the config line, example :
There are other modifiers for pins :
|o||set pin to open drain|
|^||set pin to pull up|
|v||set pin to pull down|
|-||to set no pullup|
|@||to set repeater mode|
Controlling with G-codes
By default, Smoothie will not heat anything. That could be a dangerous thing to do unwatched.
You have to send G-codes to turn your heater on and off, set a given temperature etc.
There is a set of widely used G-codes corresponding to different usual actions ( for example setting the hotend temperature is M104 in the Reprap world ).
But as you are defining your own custom temperature controller, you have to choose what gcode will be used to control it, Smoothie doesn't know what exactly it's controlling.
So for example if this is a hotend, it will look something like this for the "standard" gcodes :
temperature_control.hotend.set_m_code 104 temperature_control.hotend.set_and_wait_m_code 109
set_m_code is used to set a given temperature, and continue running Smoothie immediately. set_and_wait_m_code is used to set a given temperature, and then pause Smoothie until that temperature is reached.
Reading with G-code
There is a single g-code used to read temperature for all the temperature_control modules at the same time : M105
But it has to have a way to tell you what temperature corresponds to what specific module.
There is a standard format for this which was used before Smoothie and still is today :
ok T:22.1 /0.0 @0 B:22.5 /75.0 @210
Here T is the hotend, and B is the bed. This is a convention. But in your configuration, we have to specify which is which :
The simplest form of heat control is called bang bang this simply turns the heater on or off depending on whether it is under or over the target temperature (plus some hysteresis).
This is best used for high amp beds using a relay to turn it on and off.
to enable this form of control in the config define the following…
temperature_control.bed.bang_bang true # set to true to use bang bang control rather than PID temperature_control.bed.hysteresis 2.0 # set to the temperature in degrees C to use as hysteresis when
Example : If you set your temperature to 50 degrees, and your hysterisis is 2 degrees, then the heaters will turn on if the temperature is bellow 48 degrees, and off if the temperature is above 52 degrees.
The default form of heater control is PID.
PID is important. Without PID, a simple way to control temperature would be :
- If temperature too cold, turn heater on
- If temperature too hot, turn heater off
But there is a big problem with that method. Due to temperature not travelling instantly in what you heat from the heater to the thermistor, when the thermistor reads a given temperature, the heater is already hotter than what the thermistor reads. And that overshooting is something we do not want. It means reaching temperatures that could be undesirable, and it means you will not be able to correctly stabilize the temperature.
The solution to this is PID. It uses some math, allowing us to correct those problems by turning the heater on and off in a smarter sequence.
The P, I and D factors are configured as follows :
temperature_control.hotend.p_factor 100 temperature_control.hotend.i_factor 0.1 temperature_control.hotend.d_factor 100
But the really tricky thing is to find the right values for these 3 factors : the default ones are most probably wrong for your setup. So unless you have been given those values with your hardware, or you are a PID grand-master, you will need some help :
Do not try to use PID settings from Marlin as they are not compatible.
Using a process described here http://brettbeauregard.com/blog/2012/01/arduino-pid-autotune-library/, Smoothie can automatically tune ( find ) your P, I and D factors.
Here is an example of the G-code command used to launch PID autotune :
M303 E0 S190
- E0 is the number of the temperaturecontrol module, in the order they have been configured. Here it would be 0 for the hotend, and 1 for the bed.
- S190 is the temperature to autotune for. Use the temperature you will be using your heater at in real life. For a hotend here we use 190c
When you run the command, tuning begins :
Target: 190.0 Start PID tune, command is M303 E0 S190 T: Starting PID Autotune, M304 aborts ok T: 21.3/190.0 @80 1 0/8 T: 22.0/190.0 @80 1 0/8 T: 22.3/190.0 @80 1 0/8 T: 22.1/190.0 @80 1 0/8 Etc ...
It continues for 3 to 8 cycles, heating up, cooling down. Then :
Cycle 4: max: 246.189, min: 227.627, avg separation: 0.418274 Ku: 34.9838, Pu: 39.85 Trying: Kp: 21.0 Ki: 1.053 Kd: 105 PID Autotune Complete! The settings above have been loaded into memory, but not written to your config file.
Now edit your configuration to use those three values ( Kp is p_factor, Ki is i_factor, Kd is d_factor ), reset, and temperature control should work much better. (Also M301 can be used to set the PID values and saved with M500)
Alternatively, you can also enter the following G-code :
Which will save the configuration values automatically in a configuration override file.
Learn more about configuration overrides here : Configuring Smoothie
Do not send M303 over the web interface, use Telnet, Pronterface or any other serial terminal. If sent over the web, the answers will accumulate in Smoothie's RAM and may crash it.
If you are using a 12v heater on a 24v system
you need to set max_pwm to 64
temperature_control.hotend.max_pwm 64 #
If you are getting 10°C or more initial overshoot of temperature
oyou can set i_max to a lower value (default is max_pwm)
128 seems to be a good value, but it can be tuned with M303 S0 Xnnn where nnn is a number <= max_pwm
temperature_control.hotend.i_max 128 #
To avoid accidental setting of too high a temperature
you can set max_temp to the maximum temp that is safe for the target heater.
This will ignore any setting of temperatures that are higher than this and instead set the temp to max_temp.
It will also shutdown if this temperature is exceeded.
temperature_control.hotend.max_temp 230 #
This module controls temperature by actuating heating elements. Heat, if left unchecked, causes fire.
Fires are painful, expensive, and can even cause death.
You definitely should set up as many safety features as you can, even those that are disabled by default. This section explains how to do so.
This can happen to you
It has already been known to happen to Reprap/CNC enthusiasts. For an example see here.
This chapter covers all of the safety features, and how to set them up if needed.
If a thermistor is disconnected from it's thermistor input ( cable gets cut, connector falls ), Smoothie can detect the problem by itself, as this causes a recognizably different input.
When this happens, Smoothie will detect the problem, turn off all heaters, and enter the HALT state. It will also show you the following message :
Temperature reading is unreliable on T, HALT asserted - reset or M999 required
You need to solve the issue, and then either reset the board or issue the M999 command.
You do not need to do anything to activate this safety check.
The watchdog is a peripheral inside the microcontroller. Smoothie must tell it « Hey, I'm alive and I have not crashed » on a regular basis.
If Smoothie stops doing that, the watchdog knows Smoothie has crashed, and resets the board, which turns all heaters off.
This ensures that if the firmware crashes, your board's heaters turn off, and everything is safe.
You do not need to do anything to activate this, it is on by default.
Maximum temperature detection
You activate this safety check ( and you should ) by adding the following to your configuration :
Once this is set, it will be impossible to set temperatures higher than the max_temp value.
Also, if the temperature reaches this max_temp temperature, Smoothie will turn off all heaters, go into HALT state, and print out the following message :
Error: MINTEMP or MAXTEMP triggered on T. Check your temperature sensors! HALT asserted - reset or M999 required
You need to solve the issue, and then either reset the board or issue the M999 command.
The most likely cause for this problem, is that a heater mosfet is stuck being always active. If this is the case, Smoothie can not control that heater anymore, and nothing the firmware can do can solve the issue, and you are on your way to a fire.
This is why you need to give Smoothie a second way to cut power : either by having a signal that allows you to turn the power supply off, or a solid state relay capable of cutting all power to all mosfets. See documentation bellow for how to achieve this.
We call "temperature runaway" a phenomenon where Smoothie tries to control temperature, but for some reason the temperature increases out of control.
There are several ways this can happen :
- The thermistor is disconnected from the heater block, so the thermistor is reading room temperature, and keeps heating to try to reach it's target.
- The mosfet or solid state relay controlling the heater is stuck always letting power pass through, this causes temperature to increase even when smoothie does not ask for temperature to increase.
NOTE This is now enabled by default in newer versions of edge, the timeout is set pretty high (900 seconds), it can be disabled by setting the values below to 0.
Initial heat-up runaway detection
To detect if the thermistor is disconnected during the initial heat-up ( temperature increasing until it reaches it's target ), we need to define how long it should take for temperature to increase to the target. And if the temperature takes too long to reach this target, we know something is wrong ( likely the thermistor is detached from the heating element ).
To configure this value, we first need to ask the machine to heat-up, and use a timer to know how long it takes. For example, a given hotend could take 100 seconds to heat up.
Then, we add a margin to this, for example 20%, and we say that if the hotend takes more than 120 seconds to heat up, something is wrong.
Now that you have a reasonable safety value, add the runaway_heating_timeout option to your configuration file :
temperature_control.module_name.runaway_heating_timeout 120 # max is 2040 seconds #temperature_control.module_name.runaway_cooling_timeout 0 # max timeout for cooling down to a lower temperature default is disabled
Now, if heating ever takes longer than 120 seconds, Smoothie will know there is a problem, enter HALT state, turn off heaters, and show the following message :
Error : Temperature too long to be reached on T, HALT asserted, TURN POWER OFF IMMEDIATELY - reset or M999 required
You can disable this by setting it to 0.
NOTE If you set runaway_cooling_timeout then understand that if you set a bed temp when the bed is already hotter than the setting it will need to cool down within the time period you set. If the bed has a lot of thermal mass then this may take a long time or actually never happen, and a timeout will occur eventually. This is why it is disabled by default.
Out of range runaway detection
This safety feature allows to detect if the current temperature is getting too far away from what it should be, either too low, or too high.
This can happen if the heater is "stuck" in the active state ( in which case the temperature will read as too high ), or if the thermistor is disconnected from the heating block ( in which case the temperature will read as too low ).
This check starts being active once the target temperature is reached, and triggers if the temperature gets out of a given "range".
You configure it by adding the runaway_range configuration option :
temperature_control.module_name.runaway_range 20 # Max setting is 63°C
Where the value is how much bellow or above the target temperature we can be without triggering the alert.
Now, if temperature gets out of the specified range, Smoothie will know there is a problem, enter HALT state, turn off heaters, and show the following message :
Error : Temperature runaway on T, HALT asserted, TURN POWER OFF IMMEDIATELY - reset or M999 required
Please note that if your PID settings are not correctly tuned, this can get activated by accident because of the "swings" un-tuned temperature curves can have. Please tune your PID settings before activating this feature.
If the Smoothieboard is being a bit too strict with detecting the temperatures, you can add runaway_error_range as a parameter ( optional ), it is 1° by default meaning acceptable temperature detected can be +/- 1° of the set temp. If your printer tends to not stick close enough to the right temperature, increase this value.
If you set all of these safety parameters correctly, your Smoothieboard should now be able to detect any problem that occurs. However, it does not mean the Smoothieboard can solve the problem.
For example, if your problem is that a heating controller ( Mosfet, Solid state relay ) is stuck on the active position, even if Smoothie tells it to shut down, it will stay active and continue heating things up.
This means that you need to have a second way of cutting power.
If you have two ways of cutting the power, connected in series with the heating element, then both need to be active at the same time for electricity to flow, and even if one is stuck in the active state, as long as the other is de-activated, power will stop flowing and no heating problem will occur.
As you have seen, in each case the Smoothieboard detects a problem with heating, it enters the HALT state :
These are the different ways of stopping Smoothie :
|abort||M26||Stops an SDCARD print immediately||Not affected||Aborts||Position maintained, but file must be restarted||Player||Stops the execution of a file being played from SDCARD, it will complete the current gcode, but stop immediately after that, the rest of the queued commands are discarded. It attempts to maintain the correct position after the abort.|
|suspend||M600||Stops once queue is empty||Turned off if option enabled (default)||Paused, can be resumed||Yes, with resume or M601, position maintained||Player||Suspends the execution of a file being played from SDCARD or being streamed from a host (upstream support required currently pronterface and octoprint support it, otherwise host needs to be manually paused), all state is saved and jogging and extruding is allowed. Mainly used for mid print filament change, or filament out detection. M601 resumes the print or the resume command|
|No command, but there is a configurable «kill» button||M112||Stops instantly if kill button pressed, if issued from host has to wait for the receive buffer to have room.||Turned off||aborted||No, position is lost, home will be required||supported-g-codes||Instantly stops all operations, printer fully halts until M999 is sent. Position is lost.|
|Sending Control-X to smoothie over the serial port or USB serial port||should work at any time even when streaming, does the same as the kill button||Turned off||aborted||No, position is lost, home will be required||Instantly stops all operations, printer fully halts until M999 is sent (or $X). Position is lost.|
If the kill button is pressed (or there is a temperature fault, M112 is issued, a limit switch is hit or other error) the system enters the Halt state, in this state the play led flashes, and the state can be cleared by issuing M999 or holding the flashing kill button for 2 seconds (it can also be cleared from the LCD panel). While in the Halt state any command issued from the host will get a !! response (with a few exceptions). The PSU may be turned off when Halt is entered if there is a psu Switch defined.
All commands can be triggered by a button or a sensor if a Switch module is configured to do so.
Once in the halt state, Smoothie instructs all temperature control modules to stop heating, stops moving, and stops responding to normal commands.
However, we need to tell Smoothie to also turn the power off, which it can not do without a special hardware/power-supply/wiring setup.
There are two ways to do this : either have a power supply which you can instruct to shut down ( most computer ATX power supplies support this, some larger 48V supplies do too ), or have a solid state relay control the power.
Power supply controlled safety cutoff
First thing we need to do is configure a switch module to be able to control the power supply :
Here is how to control an ATX power supply's ON/OFF signal from a bare pin connected to the PS_ON signal, so that your board can tell it to turn off when needed
switch.psu.enable true # turn atx on/off switch.psu.input_on_command M80 # switch.psu.input_off_command M81 # switch.psu.output_pin 0.25o! # open drain, inverted switch.psu.output_type digital # on/off only switch.psu.fail_safe_set_to 1 # so the ATX turns off on a system crash #switch.psu.ignore_on_halt true # so the ATX does not turn off on a HALT condition (like limit trigger) # However leave commented or set to false if you want the ATX to turn off for an over heat fault condition
Note : this uses the PSON pin on the power supply, which should be open-drain, thus the o in 0.25o!
Here is how to control an ATX power supply's ON/OFF signal from a small mosfet connected to the PS_ON signal, or to an SSR which powers the non ATX PSU
switch.psu.enable true # turn atx on/off switch.psu.input_on_command M80 # switch.psu.input_off_command M81 # switch.psu.output_pin 2.4 # small mosfet (NB not inverted) switch.psu.output_type digital # on/off only #switch.psu.ignore_on_halt true # so the PSU does not turn off on a HALT condition (like limit trigger) # However leave commented or set to false if you want the PSU to turn off for an over heat fault condition
You need to make sure that ignore_on_halt is not set to true ( or that it is commented, which is the case here ) or it defeats the whole purpose of the exercise.
Now that this is setup, the power supply will be automatically turned off whenever a temperature error is detected.
Solid state relay controlled safety cutoff
If your power supply does not have a signal input that allows you to turn it off, you can also simply cut the power from going from the power supply, to your Smoothieboard, by using a Solid state relay ( SSR ).
The basic configuration is the same :
switch.psu.enable true # turn atx on/off switch.psu.input_on_command M80 # switch.psu.input_off_command M81 # switch.psu.output_pin 1.30 # small mosfet (NB not inverted) switch.psu.output_type digital # on/off only #switch.psu.ignore_on_halt true # so the PSU does not turn off on a HALT condition (like limit trigger) # However leave commented or set to false if you want the PSU to turn off for an over heat fault condition
Now connect the 1.30 GPIO pin ( for example ) to the positive signal input on the SSR, and Ground ( from anywhere on the board ) to the negative signal input on the SSR.
And connect the SSR's switching terminals in series with the main heater power input.
And it should now turn power off whenever there is a temperature control problem.
Here is an example of how to wire such a solid state relay :
Double thermistor setup
Hot-ends have a heating element (controlled by a MOSFET) and a thermistor to read its temperature.
When the thermistor is read, the Smoothie calculates the temperature, and then turns the heater on or off depending on whether heat is needed or not.
A few bad things can happen :
- The thermistor can get disconnected from the board, in this case, Smoothie detects it and turns everything off.
- The thermistor can fall off the heater, in which case Smoothie will think the hot-end is cold, and heat it too much.
- The MOSFET can fail, and be always on, resulting in the hot-end being over-heated.
One way to prevent the last two bad things, is to add a second thermistor to the hot-end. The second thermistor also reads the temperature on the hot-end, and if something goes bad, Smoothie turns the PSU off, preventing damage.
To implement this, you need three things:
- A switch module that turns the PSU on and OFF. (See the Switch documentation.)
- A temperaturecontrol module that doesn't control any MOSFET, but reads just the safety thermistor.
- A temperatureswitch module that turns a switch off if a temperaturecontrol module goes above a given temperature.
Here is an example configuration :
temperatureswitch.psu.enable true # temperatureswitch.psu.switch psuswitch # temperatureswitch.psu.designator F # temperatureswitch.psu.threshold_temp 45 # Turn the PSU OFF above this temperature, and ON below this temperature. In °C. switch.psuswitch.enable true # turn PSU on/off switch.psuswitch.input_on_command M80 # switch.psuswitch.input_off_command M81 # switch.psuswitch.output_pin 1.22! # 3rd small FET, or pin on header switch.psuswitch.output_type digital # on/off only # define a readonly temperaturecontrol for a PSU cutoff temperature_control.psu.enable true # Whether to activate this module at all. All configuration is ignored if false. temperature_control.psu.thermistor_pin 0.25 # Pin for the thermistor to read temperature_control.psu.heater_pin nc # set to nc to make it a read-only temperature control temperature_control.psu.thermistor Semitec # thermistor name temperature_control.psu.designator F # Failsafe designator
A few notes :
- If you have a voltage regulator as your only 5V source on Smoothieboard, this will not work, as turning the PSU off will also turn the 5V off.
- If you use an ATX PSU, you can wire the 5VSB supply to the 5V input on the Smoothieboard, in which case the Smoothieboard will still get its 5V even if the PSU is shut down by the switch module. Wire the ATX PS_ON to the ground of a small MOSFET. This will allow it to turn on/off with M80/M81, and will also shut off in case of crash.
Using a fuse for protection
A Fuse is a device which sacrifices itself ( gets destroyed and stops letting electricity through ) if the current passing through it is higher than a certain value.
As such, adding a fuse between your power supply and a power input on your Smoothieboard protects you against short circuits, overloading, mismatched loads, or any kind of device failure.
You need to choose a fuse with a value higher than your "mormal" current for a given circuit. For example if your heated bed consumes 10A, you want to have a 15A fuse protecting it, that way if everything is fine the fuse does not burn, but in case of a short circuit, it does.
Here is an example of a fuse protecting the mosfet power input :
- M105 : Configurable, Get the current temperature
- M104 : Configurable, Set the temperature target for this module. 104 is usually used for hotends, the S parameter is the temperature in °C, for example : M104 S150
- M109 : Configurable, Set the temperature target for this module then wait for it to be reached. 109 is usually used for hotends, the S parameter is the temperature in °C, for example : M109 S150
- M140 : Configurable, Set the temperature target for this module. 140 is usually used for heated beds, the S parameter is the temperature in °C, for example : M140 S50
- M143 : Configurable, Set the max temperature target for this module. The S parameter is the hotend to set and P is the temperature in °C, for example : M143 S0 P300
- M190 : Configurable, Set the temperature target for this module then wait for it to be reached. 190 is usually used for heated beds, the S parameter is the temperature in °C, for example : M190 S50
- M301 : Edit temperature control PID parameters, for example : M301 S0 P30 I10 D10, where S is the number of the temperaturecontrol module to change the parameters for
- M305 : Set parameters for the thermistor, where B is beta, R is r0 and X is t0.
- M500 : Save volatile settings to an override file
- M503 : Display overridden settings if any
Note : the lines above that say configurable mean that this is the usual command format, but that you can change the number in the configuration file.