I'm using TeaCup (downloaded from GIT on 5/14) with RepSnapper. Temperature sensing for the hot end is done by 100k thermistor, hooked up to a SEEDUINO Mega which is Arduino Mega compatible.

Declaration of Temp Sensor:

DEFINE_TEMP_SENSOR(extruder,	TT_THERMISTOR,	AIO6_PIN,	THERMISTOR_EXTRUDER)

What is killing me is that I can set a temperature and the hot end holds it. The controller is reacting to changes in the temperature by adjusting output to the FET. So obviously the sensor and everything else work. But when I send a M105 (which RepSnapper is sending automatically), the value reported back seems pretty much random. Some times it returns sensible codes for a minute or two, but then just reads wrong values. Oddly enough they often seem to fluctuate around 195 degrees. Any ideas?

Here's the thermistor table:

// default thermistor lookup table

// How many thermistor tables we have
#define NUMTABLES 1

#define THERMISTOR_EXTRUDER	0
// #define THERMISTOR_BED		1

// Thermistor lookup table, generated with --num-temps=50 and trimmed in lower temperature ranges.
// You may be able to improve the accuracy of this table in various ways.
//   1. Measure the actual resistance of the resistor. It's "nominally" 4.7K, but that's ± 5%.
//   2. Measure the actual beta of your thermistor:[reprap.org]
//   3. Generate more table entries than you need, then trim down the ones in uninteresting ranges. (done)
// In either case you'll have to regenerate this table, which requires python, which is difficult to install on windows.
// Since you'll have to do some testing to determine the correct temperature for your application anyway, you
// may decide that the effort isn't worth it. Who cares if it's reporting the "right" temperature as long as it's
// keeping the temperature steady enough to print, right?
// ./createTemperatureLookup.py --r0=100000 --t0=25 --r1=0 --r2=4700 --beta=4066 --max-adc=1023
// r0: 100000
// t0: 25
// r1: 0
// r2: 4700
// beta: 4066
// max adc: 1023
#define NUMTEMPS 20
// {ADC, temp*4 }, // temp
uint16_t temptable[NUMTABLES][NUMTEMPS][2] PROGMEM = {
{
   {1, 3364}, // 841.027617469 C
   {21, 1329}, // 332.486789769 C
   {41, 1104}, // 276.102666373 C
   {61, 987}, // 246.756060004 C
   {81, 909}, // 227.268080588 C
   {101, 851}, // 212.78847342 C
   {121, 805}, // 201.30176775 C
   {141, 767}, // 191.787692666 C
   {161, 734}, // 183.662212795 C
   {181, 706}, // 176.561442671 C
   {201, 680}, // 170.244089549 C
   {221, 658}, // 164.542298163 C
   {241, 637}, // 159.33475843 C
   {321, 567}, // 141.921298995 C
   {381, 524}, // 131.166509425 C
   {581, 406}, // 101.561865389 C
   {781, 291}, // 72.9710018071 C
   {881, 219}, // 54.8051659223 C
   {981, 93}, // 23.4825243529 C
   {1010, 1} // 0.498606463441 C
}
};

my readings fluctuate wildly until I added a 10uF capacitor across the sense port. With the impedances as high as they are, not only do we pick up a ton of noise, but the ADC's own sample and hold circuit affects the reading. Do you have this capacitor? Most premade electronics should have it onboard already.

The interesting thing about the noise is that it should still center around the actual temperature. I've seen a number of projects that deliberately add ~0.5LSB of noise then add lots of readings together to hugely increase the precision of the ADC. It would be interesting to add some code that adds 16 or so readings together then divides by 16 to see if the noise really does center around the real temp or if there's some offset or other error.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Thanks - I will try that tomorrow. I made the electronics myself and just installed a cap I had lying around (100nF I believe). I'll post if it helps.

ST

stefanst Wrote:
-------------------------------------------------------
> I made the electronics myself

me too

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> stefanst Wrote:
> --------------------------------------------------
> -----
> > I made the electronics myself
>
> me too

That's the only way. Spend hours upon hours building something you could have bought for $20 more than what you spent on material anyway. Otherwise what would we learn?

stefanst Wrote:
-------------------------------------------------------
> That's the only way. Spend hours upon hours
> building something you could have bought for $20
> more than what you spent on material anyway.
> Otherwise what would we learn?

my budget for making my printer is very low, so I have to make do with what I have available, or what I can pick up for peanuts.. Already had an arduino and since it had enough I/O I saw no reason to get a set of gen3 which was all that was around at the time... Interestingly, ramps, gen7 and sanguinololu resemble my electronics on an electrical level- significantly simpler one chip solutions

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> my readings fluctuate wildly until I added a 10uF
> capacitor across the sense port. With the
> impedances as high as they are, not only do we
> pick up a ton of noise, but the ADC's own sample
> and hold circuit affects the reading. Do you have
> this capacitor? Most premade electronics should
> have it onboard already.

Sorry- I tried and that didn't help at all. As before I get random numbers. But they are actually never completely random. It's usually 0.25. But then all the sudden it may change to something like 193 and fluctuate there. So that get's me all frisky and thinking it's working, just to disappoint me, because it stays up there even with the heater shut off. Sometimes it just stays at 866 which I think is the max from the table.
What has me buggered is that the control works beautifully. It usually keeps the temp within +/- one to two degrees of target as confirmed with a probe thermometer. The LED that's hooked up to the FET gate starts dimming when the heater approaches target. And still the M105 gives results that have nothing at all to do with reality.

ST

@Stefanst

0.25 is what it reads when the thermistor is disconnected and the 866 could be from a short. So is it possible you have a break in one of your connections?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

that's extremely unusual, as the heater uses the exact same value that M105 returns.

Are you looking at the serial stream, or the interface in your hostware?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> that's extremely unusual, as the heater uses the
> exact same value that M105 returns.
>
> Are you looking at the serial stream, or the
> interface in your hostware?

I was looking using Repsnapper on Windows.7. Now I installed Repsnapper on an old Linux Box and amazingly it gives the right output. Strange, but I'll accept that using Windows for now is not an option. Dang it. That Linux box is where I have Mythtv installed so I can watch TV while working on my Reprap. Now I may have to sing to myself for entertainment.

ST

glad you got it sorted

we have so many problems with crazy hostware :/

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> glad you got it sorted
>
> we have so many problems with crazy hostware :/


Would you like to hear more crazy hostware problems? Seems I got plenty :-/
Which may have o do with my preference for running my reprap off my Windows Laptop for now. But I don't want to keep you from more important development work. What do you recommend to use as a stable, working host software? I'm slicing with SF41 anyway, so a relatively dumb host software should do.

ST

stefanst Wrote:
-------------------------------------------------------
> Would you like to hear more crazy hostware
> problems? Seems I got plenty :-/

heh fire away, most of my 'development work' involves waiting for money to clear and parts to arrive so I can get my own printer working!

> Which may have o do with my preference for running
> my reprap off my Windows Laptop for now.

windows.. always a problem when you're trying to develop software or hardware. I gave it up long ago, and every time I have to use it I'm kicked in the teethreminded why I did that.

> What do you recommend to use as
> a stable, working host software? I'm slicing with
> SF41 anyway, so a relatively dumb host software
> should do.

sf41 is good, you should be able to use a simple commandline sender such as send.py or the mendel_print in func.sh from teacup's repository. Kliment has been working on a host sender called printrun, see [github.com] . There's also Textual Teacup and a few others.

At worst, turn on XONXOFF support and simply

cat yourfile.gcode > /dev/arduino

. This will ONLY work with XON/XOFF enabled in both firmware and on your host using stty or similar. If xon/xoff isn't enabled on both ends, cat will overrun the buffer and ruin the print.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Sounds more like an electronic problem with ground noise than an OS / host problem. The two numbers seem to correspond with the 0 and full scale ADC values. How would the host produce those other than by an amazing coincidence?

Would the Windows PC be a laptop by any chance?

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> Sounds more like an electronic problem with ground
> noise than an OS / host problem. The two numbers
> seem to correspond with the 0 and full scale ADC
> values. How would the host produce those other
> than by an amazing coincidence?
>
> Would the Windows PC be a laptop by any chance?

A fine point you make.. I know my laptop electrocutes me if I touch any metal bits, apparently the power supply's isolation is fairly fail. However this does eliminate ground loop issues, as long as I'm careful to not plug anything in while my laptop is running on AC...

Another thing to check is whether AVCC is properly decoupled and connected as per the datasheet.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

It is a laptop indeed. In order to quickly verify if ground problems play a role I unplugged it and let it run off the battery. No change, so I think the issue must be sthg. else.
And the fact that I get "good" data using the Linux PC and that the PID is working properly, even when M105 reports false data, indicates that it is indeed a communication issue and not an electronic issue. I'll see what send.py from my Windows laptop will get me, just to make sure it's not hardware related, but protocol/software related.

If you add high frequency noise to the reading it won't affect the temperature control as long as it is random.

I can't see how any comms or host error would happen to pick the temperatures at each end of the table in the firmware. The implication is the value originates in the firmware, so for some reason it is seeing both very high and very low ADC values when connected to the laptop.

---

[www.hydraraptor.blogspot.com]

have you tried changing the analog input used? one time i had a huge swing in values, and i had selected the wrong analog pin. the analog pins just float, and i think they all share the same a/d converter just mux the pin to read and sample.

another possibility : the SEEDUINO Mega is in a smaller forum factor same as arduino but has a 1280 mega, and i don't think there is proper isolation between the trace routes.
here is a picture of it below.




also there is something on arduino form to sleep the cpu during analog sample.


[www.arduino.cc]


good luck!

jamesdanielv Wrote:
-------------------------------------------------------
> also there is something on arduino form to sleep
> the cpu during analog sample.

technically it's a good idea, but we can't afford to shut down the timers or our step rate will get mangled, so that one's out for teacup

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I've been busy printing some new parts for the Mendel, so I have not been able to check into this problem in more detail. But at least my Mendel is working with my home-built electronics running Teacup! The results are OK-ish so far, but I'm sure I can improve.
The only way I was able to print was using send.py. That however seems to be running very stable. I printed an X-Axis motor bracket which took almost 4 hours. No communication problems at all.
But using send.py either on Linux or Win7 I don't get a reply from M105 displayed, so I can't use that to troubleshoot some more.
Next thing to try is to run Linux on my Win7 laptop using Virtualbox. Let's see what kind of feedback that gives me. If it's the same as the Laptop running Win7 we know the problem is hardware (laptop). if it's the same as the Linux box it's software. Right?

ST

stefanst Wrote:
-------------------------------------------------------
> I've been busy printing some new parts for the
> Mendel, so I have not been able to check into this
> problem in more detail. But at least my Mendel is
> working with my home-built electronics running
> Teacup! The results are OK-ish so far, but I'm
> sure I can improve.

congratulations! Always good to achieve such success, especially with homebuilt parts

> The only way I was able to print was using
> send.py. That however seems to be running very
> stable. I printed an X-Axis motor bracket which
> took almost 4 hours. No communication problems at
> all.

yep, heard that umpteen times. Switch to commandline sender and everything suddenly starts working

> But using send.py either on Linux or Win7 I don't
> get a reply from M105 displayed, so I can't use
> that to troubleshoot some more.
> Next thing to try is to run Linux on my Win7
> laptop using Virtualbox. Let's see what kind of
> feedback that gives me. If it's the same as the
> Laptop running Win7 we know the problem is
> hardware (laptop). if it's the same as the Linux
> box it's software. Right?

It's a sound theory- remember to try both passing the usb device into the virtual machine and the serial port, I would not be even slightly surprised if windows' serial port layer was the problem.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Alright - I tried out running Repsnapper on Linux (Ubuntu 11.04) running on VM on my Win7 laptop. And we get perfect temperature readings. This confirms that the M105 problem is caused by software. So either Win7 64bit or the Repsnapper for Windows are somewhat problematic with handling this specific piece of information from the firmware.

Conclusion: Use command line tools when working with Teacup - either send.py or GTK or some such!

I have finished ALL prints started so far and I'm printing pretty much every night. So communication is flawless for me so far.

ST

A Portmon trace of the Serial comms shows that Teacup is returning the correct values, but oddly, RepSnapper M105 response works with Sprinter FW though. I'm not sure I understand why that is.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

jim_blag Wrote:
-------------------------------------------------------
> A Portmon trace of the Serial comms shows that
> Teacup is returning the correct values, but oddly,
> RepSnapper M105 response works with Sprinter FW
> though. I'm not sure I understand why that is.

Would have to dig around in repsnapper source to figure that one out.. maybe they're using some weird version of atof() that chokes on whitespace or extra chars or something?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

It is worth considering enabling the "preserve order" #define/feature just added to the firmware.

I don't think it will completely fix the issue you are having just make the weirdness a little more consistent.

---

Necessity hopefully becomes the absentee parent of successfully invented children.