Extruder temperature woes

I've spent a lot of time recently trying to get good temperature readings from my extruder, and so far the results haven't been that good. I think I'm starting to understand enough about it to ask intelligent questions.

I'm using a 10K thermistor with a calculated beta = 3881, Rz = 32113. The calculator on the wiki suggested a 19nF capactor so I'm using a 22nF. I'm using Adrian's new firmware & host code.

It works great in the lower temperature ranges -- it's usually within a degree or two of my thermocouple, and that could easily be accounted for by the way I have them mounted. When it climbs above 90 degrees C, though, the readings become increasingly useless. The readings become further and further apart, and they become less and less accurate. When the actual temperature was climbing up into the upper 130s, the calculated values were just changing from 104 to 111. Since I'm planning to extrude HDPE, I think I'll need better precision in that range. Right now, I think I get three readings nearby: a well-under-130 reading (shows up as 104), a reading that could be anywhere between 120 and 140 (shows up as 111), and another that goes from the upper 130s to where smoke starts coming out (shows up as 116).

I started digging into the code and it seems like this is the expected behavior -- readings in the 400-600 ohm range with a 22nF capacitor are going to be too fast to get high resolution. Can I actually get good enough performance with these readings? Would I do significantly better with a different thermistor? Anything I can do to improve this other than use a bigger capacitor?

LOL! Time for a PIC chip that has a proper 10 bit A/D circuit on it.

Yeah... a better PIC would be wonderful. More memory. More PWM channels. More speed. Serial bootloading. A compiler that works. Interrupt priority levels. A/D would be nice too, or a 16-bit capture would do just fine... The '628 is what we have, though, and I'm trying to play by the rules.

did somebody say Arduino...

You can make the exponential response of the thermistor nearly linear in the range 20 to 200C just by putting 470R in parallel. You would have to make the capacitor bigger and change the maths in the host code though. Details in my blog [hydraraptor.blogspot.com] using an ADC but you could calculate the resistance with a time constant. I actually used 1K but 470R works better.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
> You can make the exponential response of the
> thermistor nearly linear in the range 20 to 200C
> just by putting 470R in parallel.

Thanks... I might do this if there's no "standard" solution. I had actually been thinking of swapping out the 10K calibration resistor for a 1K that I could switch on in parallel with the thermistor when it was in the colder part of the temperature range, but I hadn't thought that through fully. Your solution sounds simpler anyway.

ZachHoeken Wrote:
> did somebody say Arduino...

Heh... I like the ATMegas, not so sure about the rest of it though.

Yes I think this should become the standard way of doing it. Simple mod to the board and the only change required to the host s/w is to do the parallel resistor calculation before applying the thermistor equation. It may also get rid of the need for timer scale changes.

Edited 1 time(s). Last edit at 09/25/2007 05:29PM by nophead.

---

[www.hydraraptor.blogspot.com]

hi emf,

could you try my firmware-version, which I have posted in the thread "messageExtruder _code_update?" (zip-file with sources and hex-files). beside the serial-communication I have also changed the temp-measurement. I am interested how are the results of my changes. I don't have a possiblity to measure the actual temperature, so my only reference is when the hdpe is melting, and thats not so far from 140. i am now using a 30K resistor and a 0,1uF capacitor.

nevertheless, i think it's a good idea to use a parallel resistor.

best
andreas

Yeah, I played around with a spreadsheet for a while last night and I couldn't see any down-side to the parallel resistor, so I modified the host software to account for the for it and I replaced the capacitor on the extruder board with a socket so I can swap those as needed. It didn't work the first time around, but it was getting late so I was probably doing something bone-headed.

If I can undo whatever I messed up, I'll try to testing out your firmware tonight.

I think the only downside to the parallel resistor is slightly less resolution at the low temperature end to give you more at the high end. Since all extrusion is going to be 100C+ I think it's a good trade off.

---

[www.hydraraptor.blogspot.com]

andreas - can you double-check the files you posted? I couldn't get the files from the v3 tarball to work. I loaded up your extruder_0_.hex and the status light doesn't come on at power-on and I don't get any communication. 'poke' just gives me NAKs. I recompiled the hex from your sources and it matched. Since the source file only contained stuff from the firmware directory, I assume no changes to the host software are needed?

An update on my other problem: if I was doing something bone-headed last night because of lack of sleep, I'm doing the same thing today because I'm just naturally bone-headed. When I use my original setup (22nF cap, no parallel resistor), things work as well as they always did. If I toss in a parallel resistor (1K or 470R), it still mostly works, but the readings are way off because it was never accurate in that range. If I swap up to a 33nF cap to get a little more accuracy, it goes crazy.

So let's simplify this. I remove the thermistor, just leaving a 1K resistor connected, so it should report 1K resistance and tell me it's pretty hot, and I should get the same reading every time. When I start up the host software, it auto-ranges up to vref of 14, then gives me a reading of 1.2K (which is good, my readings are usually a few hundred high, probably because there are a dozen instructions between when the comparator goes high and when we read the timer). Then it re-ranges to vref=15, then 14, then 15, oscillating back and forth. Usually after a dozen or so oscillations, it settles long enough to take a reading. About half of the time this reading is 1.2K (correct), the other half it's in the 3K range. Then it goes back to re-ranging for a while.

My first thought is with the 33nF, I'm getting interrupts during the measurement so it returns 255, which causes the re-ranging. But with the 22nF cap, it could (mostly) read the reference resistor correctly, and 10K & 22nF should take a lot longer than 1K & 33nF.

That MAX6675 daughter board is looking better and better...

I still scratch my head when I see all the trouble people go to to put a thermostat on that darned extruder barrel heater. I just set mine at a reasonable pseudo amperage via PWM and let it rip. I just did a table of flow rates versus amperage versus polymer pump setting and use that to decide which settings to use. Works like a bomb, to use an old expression.

Forrest,
Without a thermostat mine reaches thermal equilibrium asymtotically in about 12 minutes and drops 30C when extruding. With the themostat it gets to temperature in 1.5 minutes and stays within a couple of degrees when extruding. I think that is a worthwhile benefit for the addition of a thermistor, two resistors, one pin on the micro, about five lines of firmware and 20 lines of host s/w. Anything that goes to improving the consistency of the extrusion process must improve the quality of the finished item.

What is crazy is the way RepRap does it, it's way too complicated. 10 years ago I designed a system that measures a resistance using an RC time constant but nowadays, if want an ADC, I use a micro with an ADC. In fact it is hard to get a modern one without an ADC.

Your scheme is probably more stable because you have a big heatsink at the top of your barrel giving a constant heat drain which makes the cooling effect of the filament less significant. Still, it must have a long warm up time. It's basically the same as the difference between an open loop soldering iron and a thermostatically controlled one. You can get by with the former, but the latter is way better.

---

[www.hydraraptor.blogspot.com]

emf,
If it was working well at the low temp end with 10K and 22nF the shouldn't you be using about 470nf with 470R?

---

[www.hydraraptor.blogspot.com]

hi emf,

I am wondering that it doesn't work, at least the status-led should light. although, if poke returns NAK, then the serial-communication is working (not as expected, but it does something). have you connected only the extruder-board or also the stepper-boards?

the only explanation I have now, is that I have removed my debugging information from the code and didn't test again before making the tgz file, but that affected mainly the stepmotor files, only some changes in the extruder and serial files. but I had the experiance, that changing one simple thing (which shouldn't change anything in the behaviour) could lead to strange results because of the buggy sdcc-compiler.

I am not at home now, so I have to wait until saturday, before I can check it. If you have time you could try the previous version v2, where I have left over the debugging infos.

and, yes no changes to the host-software are needed.


now to your experiance with the stable and crazy results:
you are right with the interrupts. this leads to the 255 values and also to the jumps between the two values.
the explanation for the stable result is, that there are only some different durations for the interrupt, for the standard PCB-Board (UNIVERSAL_PC its the duration of the timer-tick, the duration of the receiving of an serial-byte and the duration of the transmitting, and every combination of the three. most of the timer its the timer-tick which comes in the old version every 255us, in adrians version much infrequently. if the duration of the measurement correlates with the duration of the interrupts, than you get stable values (maybe interrupted or not), if not ...

I mad the following changes to the measurement:
1. because only the last interrupt before the measurement is finished is a problem, I set the interrupt-flag at the beginning of an interrupt and reset it at the end, if the voltage is not reached.
2. if the flag is set, then I discard the measurment and increment a counter (to have a control when the last correct measurement occured.
3. to get rid of the correlation (which leads to times where a many measurements has to be discarded), I use a random delay in the measurement function.

with this changes I get a temperature which vary some degrees (because of the time cyles between the last if-statement in the interrupt-handler and the return of the interrupt), but for me it looks very stable.


a reason for the re-ranges have been the problems in the serial-communication. sometimes I got a value of 0 for the temp-measurement, which could never result from the measureing.

nophead Wrote:
> If it was working well at the low temp end with
> 10K and 22nF the shouldn't you be using about
> 470nf with 470R?

Yup. That's what I tried initially, but it gave me weird results (I don't remember what exactly). So I started swapping in smaller capacitors trying to get something that behaved reasonably. After a few tries, I went back to 22nF to make sure I hadn't broken anything, then started working up from there. I'm just having a hard time believing that I was lucky enough to start with a capacitor and thermistor that mostly worked when most of the other combinations I've tried have failed.

Well if you change both the cap and the resistor so the time constant is the same I can't see how the PIC can tell the difference unless it does not have enough current drive for 470R i.e. 10ma.

You mentioned a 10K calibration resistor. Presumably you need to make that 470R as well so as not to confuse the s/w.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------

>
> Your scheme is probably more stable because you
> have a big heatsink at the top of your barrel
> giving a constant heat drain which makes the
> cooling effect of the filament less significant.
> Still, it must have a long warm up time.
>

Nope, about a minute is all. I guess my design must have accidentally hit some sort of sweet spot for performance right off the bat. Whatever it is, I'm not inclined to fool with it since it works pretty darned well.

Edited 1 time(s). Last edit at 09/27/2007 11:19AM by Forrest Higgs.

andreas Wrote:
-------------------------------------------------------
> have you
> connected only the extruder-board or also the
> stepper-boards?

Just the extruder. I'll try your v2 tonight. I took a quick look through the source and didn't see any obvious reasons it wouldn't work, so it could be SDCC's doing.

> if the duration of the measurement
> correlates with the duration of the interrupts,
> than you get stable values (maybe interrupted or
> not), if not ...

Thanks for the explanation.

> a reason for the re-ranges have been the problems
> in the serial-communication. sometimes I got a
> value of 0 for the temp-measurement, which could
> never result from the measureing.

I wondered where the zeros were coming from. With some resistor/cap configurations I saw a lot of them.

nophead Wrote:
> Well if you change both the cap and the resistor
> so the time constant is the same I can't see how
> the PIC can tell the difference unless it does not
> have enough current drive for 470R i.e. 10ma.

I don't understand that either. I think PICs are supposed to drive around 20mA, so that should be fine. With the 22nF + 470R it reads correctly around half the time (well, it reads as 600R, close enough for now). When it reads incorrectly I think it's just an interrupt interrupting. I'll try some more experiments tonight 470nF cap, most of my controlled tests were with random smaller ones.

> You mentioned a 10K calibration resistor.
> Presumably you need to make that 470R as well so
> as not to confuse the s/w.

I think the auto-ranging routine ignores the calibration value so the 10K won't do any harm, it just won't give me a useful reading. From what I've seen, the calibration value is almost completely ignored, I just added some debug code to print out its value as a sanity check. Once I get something that works, I'll replace it with an appropriate value.

the calibration value can not be used, because it would need its own auto-ranging values (voltrage-reference and prescaler value), otherwise the value is most of the time 255.

for me its not clear what the original intention for this calibration measurement has been.

best
andreas

Strange things are afoot. I may be having hardware problems, I'm not really sure yet.

I tried andreas' firmware v2, no status light. So I tried v1, no status light there either. With both of those, poke would spit out a string of nineteen 0x00s at me. I tried this with two PICs, when I burn the standard extruder code it lights up, when I burn in any of andreas', it doesn't. Now I had a bit of trouble re-programming the PICs this time around. Often my programmer wouldn't recognize them and I'd have to run the bulk-erase command several times before it would recognize them. After that, I could program and verify correctly. MPLAB always warns me that it's dangerous to use this combination of internal oscillator and MCLR disabled, but I haven't actually had these problems before with the stepper's PICs. So I can't yet rule out the possibility that both my PICs are damaged in similar ways and that's causing all of the weirdness reported in this thread.

In the still-weird-but-promising category: If I take a PIC with andreas' firmware (v1, but I now suspect v2 and v3 would do the same), power up the extruder board without the PIC, then insert the PIC into the socket, sometimes it will work. If it works, it will continue to work until I power it off. I don't have any explanation for this behavior.

When it works, it works pretty well. When I was doing readings on the low end of the time scale (470R or 1K with 22nF), they were very consistent (and maybe 10% low), and no bad readings. I swapped out the capacitor with 470nF, leaving the 470R in place, giving longer readings. These readings seemed to vary a bit. They were always in the right ballpark, but the raw values wandered around from about 109 to as high as 130 (vRef=14 scale). Translated into measured-temperature terms, this would correspond to at least 20 degree C swings, probably more. When I was doing temperature readings with the stock firmware with the same time constant (10K thermistor + 22nF cap) the readings were very stable -- either they were within a degree of the last reading, or they were completely invalid (255). I never saw any 0s or 255s with andreas' firmware, so in that regard it is a great success.

If anyone has any theories, I'm all ears. I've tried two PICs (neither brand new) that both fail to start andreas' firmware but will run the standard extruder firmware. I've tried these chips in another stepper board, but they still fail to light up the status LED. My extruder board used to be a stepper board that I used for a long time without any problems, and it works correctly with the stock firmware, so any problems with the board don't seem to affect its operation.

I think I've still got one new 16F6[24]8 I can throw at it...

[edit] No big news tonight. I didn't find the brand new 628, but I pulled the Z-axis (my least abused) chip into the mix. It behaves the same way -- works with the stock extruder firmware, fails with the andreas firmware, until I mess around with inserting the chip while powered up. I've now tried both v1 and v2, they both work the same way. Also, as soon as I burn any of andreas' firmwares onto the PIC, it becomes very hard to read/verify with the PIC programmer. Once I'm able to erase and re-program the PIC with, say, the standard stepper firmware, it becomes easy to reprogram. I can't come up with any explanation for this either -- I was expecting to find that it was doing something like driving MCLR low in the first lines of code, but nothing like that caught my eye.

Edited 1 time(s). Last edit at 09/28/2007 11:33PM by emf.

hi emf,

it's really strange that your indicator led (on PortA4) isn't switched on. on my extruder-board with the firmware v3 (I have tested again, its working for my configuration (linux-os, ucb-board v1.1, 16f628 pic)), it is always on.

it is also on, when I have no serial-connection (no transmit and receive lines) connected, only the extruder-board with the power-connector and the pic.

could someone else try this firmware version and confirm the behavior of emf's boards?

best
andreas

I did a few more tests today, but I don't appear to be any closer to finding answers.

I dug around and found all the 16F628As I have. All six are from the same batch, rev 0x8. They had all been used previously for different parts of this project, but they were all working. I burned your v1 firmware into each of them, then I set up a breadboard with Vdd, Vss, the status LED, and a decoupling cap. All other pins are left floating. Every one of the PICs failed to light the status LED. When programmed with one of the original stepper firmwares, they all light the LED.

I also found a brand new 16F648A, rev 0x5, and burned your v1 firmware into it (I used the same hex file as I used for the 628A, which I've read works, but I haven't done any tests to verify that yet). It fails to light the LED in the breadboard as well.

I'm running out of ideas here. While I haven't been able to test a completely new 628A, it strikes me as unlikely that they'd all have the same form of hardware damage that only affects a certain firmware. There's no common board they've all been in that could have caused that hardware damage, except for my programmer. We know my programmers are at least able to write almost all of the program to the PIC, because I if I fiddle with plugging the chip while powered up, eventually it will start running and keeps running. I can't remember for certain, but I think I've programmed using both WinPIC+JDM2 and MPLAB+ICD2 combinations with the same results. The majority of my trials were using the ICD2 though.

I've got a few new 628As that should be arriving in a week or two. Until then, I'll probably fall back to the stock firmware and see if I can get some plastic melted.

It sounds like a problem with the configuration bytes which determine clock type etc. I think they appear at the end of the hex file. It might be worth comparing the end of a hex file that works with one that doesn't.

---

[www.hydraraptor.blogspot.com]

hi nophead,

it could be in the initialization, but on my board the led is switched on, on emf's board not. we are using the same hex-file.
as far as I understand the elecronics, PORTA4 and TRISA4 have to be set to 0, for switching on the LED. yes, bit 5 of the OPTION-Reg (TOCS) has to be set to 0.

I have changed the PORTA and TRISA assignments in the timer-method because the old checkTemperature() version saves the value of portaval at the beginning of checkTemperature() and resets it at the end to the saved value. if PORTA has been changed in the meantime (in one of the interrupt-routines), than this change get lost. I have compared the old source-code and my version again, but I have no explanation why PORTA4 or TRISA4 should have a value of 1.

andreas

An additional bit of data: When the PIC is running andreas' firmware and appears to be doing nothing, it will still respond to serial messages (this test was suggested by andreas):

$ echo 0 . w | ./poke -d 8 -t /dev/ttyS0 -v
<54><51><31><08><00><00>[54][53][30][00][08][4c]Got NAK

I haven't tried to understand what goes on in the SNAP code, but since it's sending back data that resembles the input data, I think we can conclude that the oscillator is running at the right speed, the UART is initialized at the right baud rate, and it's handling interrupts. Maybe there's a difference in the PICs we're using where mine doesn't initialize some data that the startup depends on. Sounds a bit far-fetched, but...

It could be an uninitialised variable. They tend to come up with different values in different instances of identical chips.

---

[www.hydraraptor.blogspot.com]

Good news on the firmware bug. Andreas did some great remote debugging and fixed the problem by re-ordering some of the initialization code. From what I've seen it works far better than the stock firmware. I don't think I've encountered a temperature reading that timed out due to interrupts yet. With the stock firmware, I'd get them anywhere from 5% of the time on up, with many capacitor/resistor combinations being totally unusable. So far I've only been testing with the extruder exerciser & calibration programs so it may get worse when there's more traffic zipping around the network, but my initial results have been great.

I had a second problem when I tried to use a 470nF capacitor to read the temperature. Readings were very steady when I used a 22nF capacitor, but when I used a 470nF cap and a correspondingly smaller resistor to maintain the same time constant, my readings were noisy, varying roughly +/- 10%. This turned out to be a result of the capacitor not fully discharging. When we discharge the capacitor between readings, we use the comparator to detect when it has discharged to the lowest detectable level, 0.21V, then wait another 10us to allow for full discharging. With a larger capacitor, the 10us only lets the voltage drop to around 0.18V, so the accuracy of the next reading was dependent on how much code executed between readings. I increased this delay in my firmware to 200us and the readings are now quite stable. We may want to make this delay controlled by the host PC, or at least issue a warning if the user enters a capacitor value that won't sufficiently discharge during the fixed interval.

That gets me down to accuracy. Right now it's reading my 470 ohm resistor as 526 ohms. The stock firmware had a similar offset when I was able to get it working. Looks like the first task for the weekend is to characterize this offset and then see how I can get rid of it. I don't have any way to measure my capacitor to see how accurate it is. I have some vague hopes that if I use the firmware to measure the value of my parallel resistor and the thermistor's beta and Rz, the errors might all cancel out. I haven't checked to see if the equations really work that way.