Teacup Firmware Double Thermistor Table

Hi,

I have been successfully using Teacup for a while now. I have both heated bed and extruder thermistors but they are identical so I have just used a single thermistor table and all is well.

I am about to move to using a different hot end that has a different thermistor so I need to have two thermistor tables now - one for the new hot end and one for the original heated bed.

In preparation I decided to convert my current setup to use two tables but with both containing the same data before converting it to completely separate tables.

So I took the Teacup ThermistorTable.double.h and renamed it. I then modified the NUMTEMPS to 39 (the same NUMTEMPS as my old table) and pasted in my old table twice as appropriate. I also changed config.h so that the heated bed now uses the THERMISTOR_BED table.

The code compiled but after loading it into the hardware and starting Pronterface it reports wildly incorrect temperature (~241 degC on each) where before I was reading ~25.

To be sure I had not done something wrong I reverted back to my original one thermistor table and everything was fine. I also reverted to the original double table file since the numbers were very close to my original table but it still showed ~250 DegC.

I can only think that there is something wrong with the double table provided or its implementation, but searching the forums nobody else seems to have this problem so I'm not really sure.

Has anybody else experienced this issue?

Thanks

Andy

Could you please provide us your new table and your new config.h as an attachment here? As the provided ThermistorTable.double.h doesn't work, it's more likely a config.h issue.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

See attached.

Thanks

Andy

Such funny combinations:

#define	STEPS_PER_M_E				505288
#define	MAXIMUM_FEEDRATE_E			10000000

easily produce integer overflows. If you want E feedrate unlimited, a value reflecting 100'000 steps/second is totally sufficient. In this case, it's 100'000 * 60 / 505 = 12000. Teacup's acceleration code will collapse long before reaching a 100 kHz step rate anyways and your stepper motor won't do 10'000 RPM either.

I can't find something wrong regarding your thermistor table, though. The only thing I see is, according to a comment in there you have a 10k thermistor instead of the more common 100k one. As you say, the numbers are pretty close to the ones needed for a 100k one. So you might be using a 100k table on a 10k thermistor, which approxximately matches the 10 times too high readout.

I hope this gives you enough hints to find the showstopper.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for the suggestion - I think that was a hangover from early testing where my E stepper was not moving properly so I set it really high, not knowing what the units were and assuming the IDE would warn me about an overflow.

Not sure if you are suggesting my E-Steps per m is also very high, but that is what it needs to be to draw in a metre of filament.

It is a 10k, but I think you misunderstood - my hardware has not changed yet, I am still using 10k thermistors but in preparation I have changed from using one 10k table (that I know works because I am printing with it!) to two identical 10k tables (one for extruder and one for the bed). There is no reason that this should not give identical results to the single table variant since the content of the tables has not changed. Therefore I think there must be a bug somewhere.

I don't think the 10k/100k table similarity is of significance since it depends on the biasing resistor I have used in my circuit being the same as the one used to develop the 100k table, which it probably isn't. Plus the fact that my tables have not changed, just copied twice and as mentioned above the code SHOULD be using the same table and therefore give the same result no matter how many tables I use, but it isn't.

I think I will have to delve into the code a bit more to figure out what number it pulls up when looking at the two table version. I will post results when I figure it out.

Cheers

Andy

OK,

So I think it was all my fault! Having looked through the code I remembered that for some reason (not sure why!) I modified temp.c by removing the [table_num] dimension of the temp_table array which obviously results in the code looking in an incorrect memory location and reading the wrong number.

Have not tried it yet but I'm certain that is the problem. Sorry for the confusion!

Andy