Converting old TAZ 4 extruder to flexystruder

All I can tell you is the heating resistor in the hexagon hot end has both leads on one side where the heating resistor on the budaschnozzle has one lead on each side. I’m not sure if it would be sturdy enough to put the new resistor in old hot end.

I wish I knew what is so different. When I find myself curious of the differences it is when I don’t have the time to dig into the code/configuration. I think all we need to do is compare the configuration.h files in the two Marlin packages. I know the PID settings will be different, but I don’t know what else.

According to the two arduino sketches…

Dualie and flexi both use type 7 thermisters. The Hex uses a type 5.
// 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)
// 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup)

I also get different Kp, Ki and Kd:
// Buda 2.0 on 24V
#define DEFAULT_Kp 14.09
#define DEFAULT_Ki 0.75
#define DEFAULT_Kd 66.00

// AO-Hexagon (24V)
#define DEFAULT_Kp 34.26
#define DEFAULT_Ki 2.83
#define DEFAULT_Kd 103.84

Nice! I was sure there had to be something like this. Completely explains why my resistor fried when I used the wrong firmware. Would be nice to add this to the menu… To be able to choose between multiple profiles (number and types of extruders, PID configs, etc). They like to use preprocessor directives everywhere though, so it really isn’t designed to allow switching configurations like this :frowning:

That could be another weekend project… I wonder if the space savings are required to fit everything in the Arduino board. Or maybe its a question of speed since it is a realtime system. Either way it is worth spending some time trying to understand better.

FYI, the hexagon hot end uses a heater cartridge, not a heater resistor. In my opinion this is a major improvement (it should be a little more reliable). This might be why the firmware is so different.

Ok. Good info!

Then I guess it’s just going with three different firmwares (hexa, buda and dual) until all the budas have become hexes… :slight_smile: I wonder if we could get a package deal on three Hexagons? :slight_smile:

would it be possible to create a firmware that would handle a dually setup with a budaschnozzle 2.0 and a hexagon? I already have the buda, but want to get a dual printing setup going without missing out on the high temp stuff or having to buy two hotends.

I had hoped so. But, without rewriting a lot of code, no. The code references defined values rather than variables. And there is no provision for denoting values for one extruder from another as far as resistor/element type. From outward appearances, it seems that the code was written with only a single extruder in mind. Then later patched for multiple extruders.

Like you, I wanted to combine them. Without nearly a complete rewrite of the marlin software, its simply not going to happen.

What I would like it to have been done like… Store the heater types, the PID values, etc in EPROM. Then allow them to be defined per extruder and stored as a “Tool Head” setting. Lets say you drop in a hex single extruder. You set up Tool Head 1 with the proper heater type and PID values. Store that. Then say you get a flexi-dualie. So you set up Tool Head 2 with the proper heater types with PIDs for dual buddas. Then when you put your hex single back on, you recall tool head 1 and go. Thats the way it should work. Unfortunately we are well away from that.

I do not consider myself a programming expert. But I have been doing it since the late 70’s so I got a pretty good experience level to base things on. Some experience on Arduino’s. Some on Pi’s. And a hell of a lot in desktop programming going back to 8080’s, 6502’s and Z80’s as low level as hand coding machine code (no compiler). Now, whether I can re-code Marlin to do these things I want (and apparently many others), I don’t know. I have to look at memory available to store the values as well as code memory to run them.

I thought the only difference between the codes were the thermister types… Wonder if would it be possible to replace the buda thermister with a spare from the hex? Then you should be able to keep the hex firmware… just make sure you don’t overheat the buda.

But as usual… I could be making it sound too simple. :slight_smile:

I believe the difference is the heater type. When I powered up my flexystruder after the conversion, the thermistor seemed to be registering correctly. The resistor however was glowing red hot and eventually failed.

that sounds like an amazing solution, I really want to try that now. I would love to hear if any of the staff have an opinion on this.

ok so the amazing people (, , , and ) over on freenode say it can be done in marlin inside of configuration.h look for #define TEMP_SENSOR_1 0 and set values for each hot end differently… I will try it.

That is correct. The defines are static values. They don’t change unless you recompile the firmware and upload it to the Taz. THAT is the problem. If you change your tool head, you have to push a different firmware too.

Here is the section:

//===========================================================================
//=============================Thermal Settings  ============================
//===========================================================================
//
//--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table
//
//// Temperature sensor settings:
// -2 is thermocouple with MAX6675 (only for sensor 0)
// -1 is thermocouple with AD595
// 0 is not used
// 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup)
// 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup)
// 3 is mendel-parts thermistor (4.7k pullup)
// 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !!
// 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)
// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)
// 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup)
// 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup)
// 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup)
// 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup)
// 10 is 100k RS thermistor 198-961 (4.7k pullup)
// 60 is 100k Maker's Tool Works Kapton Bed Thermister
//
//    1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k
//                          (but gives greater accuracy and more stable PID)
// 51 is 100k thermistor - EPCOS (1k pullup)
// 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup)
// 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup)

#define TEMP_SENSOR_0 5
#define TEMP_SENSOR_1 5
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_BED 7

Those 4 defines outline the 3 possible extruder temp sensors and the bed sensor.

That, however, is not the damaging data… this is:

#define PIDTEMP
#define BANG_MAX 220 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX 225 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
#ifdef PIDTEMP
  //#define PID_DEBUG // Sends debug data to the serial port.
  //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX
  #define PID_FUNCTIONAL_RANGE 16 // If the temperature difference between the target temperature and the actual temperature
                                  // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.
  #define PID_INTEGRAL_DRIVE_MAX 220  //limit for the integral term
  #define K1 0.96 //smoothing factor within the PID
  #define PID_dT ((OVERSAMPLENR * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine

The BANG_MAX, PID_MAX and PID_INTEGRAL_DRIVE_MAX are what killed dutchhome’s heater.

For the Taz4 (budda):

#define PIDTEMP
#define BANG_MAX 70 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX 74 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
#ifdef PIDTEMP
  //#define PID_DEBUG // Sends debug data to the serial port.
  //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX
  #define PID_FUNCTIONAL_RANGE 16 // If the temperature difference between the target temperature and the actual temperature
                                  // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.
  #define PID_INTEGRAL_DRIVE_MAX 70  //limit for the integral term
  #define K1 0.96 //smoothing factor within the PID
  #define PID_dT ((OVERSAMPLENR * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine

So as you can see the drive for the Budda should be in the 70’s. This limits the current supplied to the resistor in the hot end. For the Hex, its in the 250’s, more than 3x what the Budda can handle.

Note that these are #defines. That means they can not be changed by code.

#define is a useful C component that allows the programmer to give a name to a constant value before the program is compiled. Defined constants in arduino don’t take up any program memory space on the chip. The compiler will replace references to these constants with the defined value at compile time.

The only way to change them is to edit the source, recompile it and then upload it to the Taz. The advantage of this method is there is no memory usage for them. They consume no storage. It also, unfortunately, prevents any change in them through software.

That is what I was referring to as a code rewrite. The code would have to be rewritten to accept stored variables (ie from EPROM) instead of these hard coded values. That change would consume additional code memory, temporary (scratch) storage, as well as Eprom storage. It would involve coding the display functions to allow us to store and reacall them. I don’t know what’s left in any of them, I haven’t really dug into the resources remainig. It wouldn’t surprise me if AO chose the smallest (usually cheapest) possible ATMega chip that would do the job. That, likely, severely limits what can be done here.

Another downfall in Marlin is, the best I can figure, there is only one set of Kp Ki and Kd values stored for extruders. This means the same values are used for both extruders. The result of this is that both extruders would have to be the same class or type. So no mixing budda and hex on a dualie. You might get away with an E3D and Hex as they use similar heater cartridges and thermistors.

well that was a really nice and well explained reply that no doubt kept me from frying my thermistor… I just wish there was a way to define separate PID values for separate hot ends.

thank you for taking the time to explain that too.

Not fry the thermistor, fry the heater :slight_smile: The thermistor is what reads the temperature. The heater element or resistor is what makes the heat for it to measure.

The reason it needs to know what the thermistor type is, is to be able to convert its reading to accurate degrees C via an analog to digital converter. For, example one type of thermistor at 70k ohms means 200c, but a different brand/model thermistor at 70k means 185c (hypothetical values there), it has to realize the difference to accurately report the temperature. That is what the TEMP_SENSOR_0, 1, 2, Bed are for.

The power settings (PID_MAX, etc) control how much power is supplied to the heat resistor or heat element as well as how much it can actually take. The Rambo is capable of supplying more power than the heaters can take, so the firmware tells it how much it SHOULD deliver of what it CAN deliver as expressed in 0 to 255 equating to 0% to 100%. For example, imagine you have a 100w stereo. If you hook up speakers that can take 100w, all is good, crank it up. But if you attach speakers that can only take 50w, you better not turn the power up past half or you toast the speakers. Thats what the settings in the config file do. They tell the rambo not to crank it up for the budda but the Hex is “rock on!”

I finally got my Flexystruder put together and working. I’m very happy with it so far, about 4 prints with semi-flex. The full flex stuff arrives tomorrow. I did notice one minor problem though. The stepper motor was a little bit loose with all three 3mm X 12mm bolts that were recycled from the Budaschnozzle. I replaced them with 3mm X 10mm bolts and all is well. The Flexy body I printed is a little thinner than the stock body and the 12mm screws were bottoming out on the stepper motor.

YMMV

TiM