search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.2k forks source link

Max6675 SPI conflicts #1227

Closed Grogyan closed 9 years ago

Grogyan commented 9 years ago

The code for the Max6675 to communicate over the SPI bus assumes that no other devices are on the same bus, and so there is a conflict of communication. A sanity check to ensure that the SPI bus is free before establishing communication is needed. Max6675 SS is on pin 66 RAMPS 1.4 RepRap discount full graphic display

boelle commented 9 years ago

related to https://github.com/MarlinFirmware/Marlin/issues/1226

boelle commented 9 years ago

one way to solve this one is to use the chip select pin.... if master do not use SPI it will not pull the chip select lines high... one line is needed for each device...

when master wants a temp reading it will pull high the chip select line a and talk to the thermocouple... when done it puts the line low...

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface-bus

Grogyan commented 9 years ago

https://www.sparkfun.com/datasheets/IC/MAX6675.pdf MAX6675 http://datasheets.maximintegrated.com/en/ds/MAX31855.pdf MAX31855

Both require CS to be pulled low (which they are) in order to communicate to

Grogyan commented 9 years ago

Just pasting this here from an earlier discussion we had on IRC The MAX6675 uses a bang bang method to simulate basic SPI comms, and is not compatible at all with the SPI comms used in the current implementation of the SD card.

I also took a look at the Repetier code regarding this, they also do Bang Bang for MAX6675 and MAX31855 SPI emulation on the hardware SPI port.

thinkyhead commented 9 years ago

More pasting on the subject (from this forum) to back up the issue…

The datasheet for the MAX6675 says that it implements a "Simple SPI-Compatible Serial
Interface", which to me suggests that it's a partial implementation of SPI but not a
full one. For example, it doesn't use MOSI at all, only MISO, so communications with
the MAX6675 are read-only. Basically, you enable the chip using the CS (Chip Select)
line and it just starts spitting data at you. It *looks* like the intention is that it
can share a bus with real SPI devices, so I assume that if you de-assert CS it'll shut
up and leave the bus for other devices to communicate.

Speculation there on possible solutions, but no resolution.

thinkyhead commented 9 years ago

We have a suggestion from David Braam to move the MAX6675 code into the main thread (updateTemperaturesFromRawValues) using this commit from his Ultimaker fork.

https://github.com/Ultimaker/Ultimaker2Marlin/commit/91c64e356348decee934b816269a25e7c42e8071

thinkyhead commented 9 years ago

1402 should have resolved this. We don't have a more comprehensive solution at this time, AFAIK. The best authority on this issue is probably @daid .

boelle commented 9 years ago

on phone but i remember that spi stuff needs one digital line for each device besides the data line... mcu pulls the line high when it wants to talk to a device

Den fredag den 6. marts 2015 skrev Scott Lahteine <notifications@github.com

:

1402 https://github.com/MarlinFirmware/Marlin/pull/1402 should have

resolved this. We don't have a more comprehensive solution at this time, AFAIK. The best authority on this issue is probably @daid https://github.com/daid .

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77615033 .

boelle commented 9 years ago

with one device it does not matter but with 2 or more it does... so even with one we should do it

Den fredag den 6. marts 2015 skrev Bo Herrmannsen <bo.herrmannsen@gmail.com

:

on phone but i remember that spi stuff needs one digital line for each device besides the data line... mcu pulls the line high when it wants to talk to a device

Den fredag den 6. marts 2015 skrev Scott Lahteine < notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');>:

1402 https://github.com/MarlinFirmware/Marlin/pull/1402 should have

resolved this. We don't have a more comprehensive solution at this time, AFAIK. The best authority on this issue is probably @daid https://github.com/daid .

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77615033 .

daid commented 9 years ago

Actually https://github.com/marwijn contributed the patch to me. I know little more then that.

thinkyhead commented 9 years ago

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

boelle commented 9 years ago

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427 .

scotty1024 commented 9 years ago

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947

On Mar 7, 2015, at 2:20 AM, Bo Herrmannsen notifications@github.com wrote:

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427 .

— Reply to this email directly or view it on GitHub.

boelle commented 9 years ago

and the purpose of the link? nothing new info in there that i have not allready told

2015-03-07 18:38 GMT+01:00 scotty1024 notifications@github.com:

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947

On Mar 7, 2015, at 2:20 AM, Bo Herrmannsen notifications@github.com wrote:

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77700055 .

Grogyan commented 9 years ago

There is another device that uses the 1 wire protocol, which can easily be used to daisy chain multiple thermocouples.

Alas I don't have one, nor have I got time to test the current development branch to see if the fix that was put in about a month ago has solved the SPI issue. On 8 Mar 2015 07:02, "Bo Herrmannsen" notifications@github.com wrote:

and the purpose of the link? nothing new info in there that i have not allready told

2015-03-07 18:38 GMT+01:00 scotty1024 notifications@github.com:

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947

On Mar 7, 2015, at 2:20 AM, Bo Herrmannsen notifications@github.com wrote:

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77700055

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77701232 .

scotty1024 commented 9 years ago

I think that document's diagrams more clearly demonstrate that so long as you chain SPI devices properly there is no conflict: AVR -> Thermocouple -> Viki LCD.

On Mar 7, 2015, at 10:02 AM, Bo Herrmannsen notifications@github.com wrote:

and the purpose of the link? nothing new info in there that i have not allready told

2015-03-07 18:38 GMT+01:00 scotty1024 notifications@github.com:

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947

On Mar 7, 2015, at 2:20 AM, Bo Herrmannsen notifications@github.com wrote:

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77700055 .

— Reply to this email directly or view it on GitHub.

boelle commented 9 years ago

yep... might get one of those thermocouple boards (got the thermocouple) so that we can test... are those full graph displays for ramps also spi?

2015-03-07 20:00 GMT+01:00 scotty1024 notifications@github.com:

I think that document's diagrams more clearly demonstrate that so long as you chain SPI devices properly there is no conflict: AVR -> Thermocouple -> Viki LCD.

On Mar 7, 2015, at 10:02 AM, Bo Herrmannsen notifications@github.com wrote:

and the purpose of the link? nothing new info in there that i have not allready told

2015-03-07 18:38 GMT+01:00 scotty1024 notifications@github.com:

http://www.maximintegrated.com/en/app-notes/index.mvp/id/3947

On Mar 7, 2015, at 2:20 AM, Bo Herrmannsen <notifications@github.com

wrote:

http://upload.wikimedia.org/wikipedia/commons/f/fc/SPI_three_slaves.svg

SPI can be daisy chained but then a shift register is needed and i very much doubt that any 3d printer stuff that uses SPI will have that implemented...

So our first Q to ourselves is: Does spi stuff use a slave select line for each device?

if not we need to implement that so that we know what device we are doings comms with... or else we will get conflicts... an SPI display and a SPI thermocouple is an example... they will clash pretty fast :-D

2015-03-07 0:11 GMT+01:00 Scott Lahteine notifications@github.com:

Eek! Well, I have heard some interesting things about the new SPI libraries that come with Arduino 1.6. Worth looking into, perhaps.

— Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77653427

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77700055

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77704100 .

Grogyan commented 9 years ago

I don't think the MAX31855 board is supported yet in Marlin. Which thermocouple board(s) will you be getting?

boelle commented 9 years ago

one that is know to cause issues so we can get it solved...

2015-03-08 22:33 GMT+01:00 Grogyan notifications@github.com:

I don't think the MAX31855 board is supported yet in Marlin. Which thermocouple board(s) will you be getting?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-77775736 .

AnHardt commented 9 years ago

@boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

Grogyan commented 9 years ago

Tried compiling today's version of the development repo I get this error with Arduino IDE 1.52, and 1.60 I thought it was related to my outdated IDE so have completely replaced it with the official 1.60 Arduino IDE

temperature.cpp: In function 'void manage_heater()':
temperature.cpp:529:59: error: 'max_temp_error' was not declared in this scope
     if (ct > min(HEATER_0_MAXTEMP, 1023)) max_temp_error(0);
                                                           ^
temperature.cpp:530:59: error: 'min_temp_error' was not declared in this scope
     if (ct < max(HEATER_0_MINTEMP, 0.01)) min_temp_error(0);
                                                           ^
Error compiling.
AnHardt commented 9 years ago

@boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

I revert my statement from yesterday. The FULL graphic Displays (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) uses a kind of software SPI but on entirely different pins (ultralcd_st7920_u8glib_rrd.h). A hardware conflict with the normal SPI buss (SD-card, MAX6675) isn't possible.

boelle commented 9 years ago

just trying to figure whats causing the errors

ie.. no need to keep this one open if its an hardware thing

Den tirsdag den 10. marts 2015 skrev AnHardt notifications@github.com:

@boelle https://github.com/boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

I revert my statement from yesterday. The FULL graphic Displays (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) uses a kind of software SPI but on entirely different pins (ultralcd_st7920_u8glib_rrd.h). A hardware conflict with the normal SPI buss (SD-card, MAX6675) isn't possible.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78025422 .

Grogyan commented 9 years ago

Once the compilation errors have been debugged then I can test it out.

There is an SPI conflict as there is no sanity check done to ensure that the bus is free to communicate on. On 10 Mar 2015 23:36, "Bo Herrmannsen" notifications@github.com wrote:

just trying to figure whats causing the errors

ie.. no need to keep this one open if its an hardware thing

Den tirsdag den 10. marts 2015 skrev AnHardt notifications@github.com:

@boelle https://github.com/boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

I revert my statement from yesterday. The FULL graphic Displays (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) uses a kind of software SPI but on entirely different pins (ultralcd_st7920_u8glib_rrd.h). A hardware conflict with the normal SPI buss (SD-card, MAX6675) isn't possible.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78025422

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78029530 .

boelle commented 9 years ago

hehe...

it's nice when this one is cleared.... i think it's one of the oldest verified issues we have on the list

2015-03-10 16:32 GMT+01:00 Grogyan notifications@github.com:

Once the compilation errors have been debugged then I can test it out.

There is an SPI conflict as there is no sanity check done to ensure that the bus is free to communicate on. On 10 Mar 2015 23:36, "Bo Herrmannsen" notifications@github.com wrote:

just trying to figure whats causing the errors

ie.. no need to keep this one open if its an hardware thing

Den tirsdag den 10. marts 2015 skrev AnHardt notifications@github.com:

@boelle https://github.com/boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

I revert my statement from yesterday. The FULL graphic Displays (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) uses a kind of software SPI but on entirely different pins (ultralcd_st7920_u8glib_rrd.h). A hardware conflict with the normal SPI buss (SD-card, MAX6675) isn't possible.

— Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78025422

.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78029530

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78078627 .

Grogyan commented 9 years ago

It's an odd one, and I hadn't really delved into the code a year ago to try and understand why sometimes it works and other times it wouldn't. Right now I just want to get both the thermocouple and SD card to behave and begin to run my machines at their optimum performance and reliability. On 11 Mar 2015 04:34, "Bo Herrmannsen" notifications@github.com wrote:

hehe...

it's nice when this one is cleared.... i think it's one of the oldest verified issues we have on the list

2015-03-10 16:32 GMT+01:00 Grogyan notifications@github.com:

Once the compilation errors have been debugged then I can test it out.

There is an SPI conflict as there is no sanity check done to ensure that the bus is free to communicate on. On 10 Mar 2015 23:36, "Bo Herrmannsen" notifications@github.com wrote:

just trying to figure whats causing the errors

ie.. no need to keep this one open if its an hardware thing

Den tirsdag den 10. marts 2015 skrev AnHardt <notifications@github.com :

@boelle https://github.com/boelle

... are those full graph displays for ramps also spi?

Usually not the displays - but the sd-card-slot on them.

I revert my statement from yesterday. The FULL graphic Displays (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) uses a kind of software SPI but on entirely different pins (ultralcd_st7920_u8glib_rrd.h). A hardware conflict with the normal SPI buss (SD-card, MAX6675) isn't possible.

— Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78025422

.

— Reply to this email directly or view it on GitHub <

https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78029530

.

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78078627

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-78079130 .

boelle commented 9 years ago

@thinkyhead any idea when you have time to nail this one?

AnHardt commented 9 years ago

Dear @boelle . As far i understand this we are waiting for tests. SD-Card ant MAX6675 both use hadware SPI. The MAX6675 used to run in an interrupt. So SD-Card and MAX used to conflict. Now MAX code runs in the normal loop and we hope SD-code and MAX code will interleave nicely. This has to be tested. @Grogyan tried to test, but cold not, because the code then did not compile. The errors are fixed now. So we are waiting for tests again.

Grogyan commented 9 years ago

I'm pretty busy this weekend, so I hope to test this on Monday afternoon. On 15 Mar 2015 05:51, "AnHardt" notifications@github.com wrote:

Dear @boelle https://github.com/boelle . As far i understand this we are waiting for tests. SD-Card ant MAX6675 both use hadware SPI. The MAX6675 used to run in an interrupt. So SD-Card and MAX used to conflict. Now MAX code runs in the normal loop and we hope SD-code and MAX code will interleave nicely. This has to be tested. @Grogyan https://github.com/Grogyan tried to test, but cold not, because the code then did not compile. The errors are fixed now. So we are waiting for tests again.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-80577049 .

thinkyhead commented 9 years ago

Testing is the best thing. For me to do any real coding on this I would need a thermocouple. For the moment I'm limited to testing thermistors.

boelle commented 9 years ago

maybe one of those that has thermocouple could setup a pc or something with teamview so that you could have access to both the pc and printer and do testing that way?

not ideal but could be a way to get it tested proberly?

AnHardt commented 9 years ago

@boelle The test is relatively easy done. Just print a file from sd-card while MAX6675 is reading the temperatures. Ether it works. or not. Ether we get corrupted temperatures or corrupted input g-code.

When the code does not mesh proper we could try to use s semaphore ( bool harwareSPIinUse ) and block the other device until SPI is free again. But than we risk not reading temperatures for a while or drying out the g-code buffer.

boelle commented 9 years ago

hehee.... it was just a wild thought...

Grogyan commented 9 years ago

Well my initial tests went; Do I get a temp reading from the MAX6675? Yes Are those temps Stable? Yes Can I upload a gcode file? No What went wrong? Repetier for Windows 1.06 Error message; 20:27:17.704 : N93 M28 cookie.gcode 99 20:27:17.767 : echo:Now fresh file: cookie.gcode 20:27:17.798 : N94 M29 5 20:27:17.798 : open failed, File: cookie.gcode .

Appears to be an extra space and full stop

Where to from here? I am going to have to swap my stepper drivers over to a RAMPS 1.4 to try out drawing a box with serialized gcode loaded directly onto the SD card.

Grogyan commented 9 years ago

Another error, now that it is all hooked up. Err. MINTEMP even with the min temp set to 5 degreesC, storing that into EEPROM and heating up the hot end to 180 degreesC

I still get a MINTEMP warning, therefore none of the axes will move

thinkyhead commented 9 years ago

@Grogyan So does that first problem seem to be that the filename is being mangled? And for the MINTEMP issue, is that SD related, or do you see that every time with the thermocouple now?

Grogyan commented 9 years ago

The SD bug is probably something that Repetier does, or expects.

The MINTEMP is happening all the time with the thermocouple attached. I didn't have time last to double check this against a thermistor setup. On 17 Mar 2015 09:20, "Scott Lahteine" notifications@github.com wrote:

@Grogyan https://github.com/Grogyan So does that first problem seem to be that the filename is being mangled? And for the MINTEMP issue, is that SD related, or do you see that every time with the thermocouple now?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/1227#issuecomment-81916303 .

Grogyan commented 9 years ago

Any ideas guys on what would be causing this MINTEMP? I seem to be getting it even with a thermistor.

thinkyhead commented 9 years ago

@Grogyan I'm looking at temperature.cpp line 1604 and I can't see any obvious problem there. But it may point to the cause....

#if HEATER_0_RAW_LO_TEMP > HEATER_0_RAW_HI_TEMP
  #define MAXTEST <=
  #define MINTEST >=
#else
  #define MAXTEST >=
  #define MINTEST <=
#endif
for (int i=0; i<EXTRUDERS; i++) {
  if (current_temperature_raw[i] MAXTEST maxttemp_raw[i]) max_temp_error(i);
  else if (current_temperature_raw[i] MINTEST minttemp_raw[i]) min_temp_error(i);
}

In order for the error to be thrown, either current_temperature_raw[i] is too low or mintemp_raw[i] is too high. I'm inclined to think it must be related to the current_temperature[0] value because you're seeing it with both thermistor and thermocouple. The thermocouple code just says...

#ifdef HEATER_0_USES_MAX6675
  float ct = current_temperature[0];
  if (ct > min(HEATER_0_MAXTEMP, 1023)) max_temp_error(0);
  if (ct < max(HEATER_0_MINTEMP, 0.01)) min_temp_error(0);
#endif //HEATER_0_USES_MAX6675

So I need to poke around and see if there's someplace where the current_temperature[0] could be getting trounced, possibly by a buffer overrun.... or where it might be getting set to some weird value otherwise.

thinkyhead commented 9 years ago

Probably related to #1654 where they're seeing a MAXTEMP BED error.

Grogyan commented 9 years ago

It's weird, because with both a thermocouple and thermistor, the temperature reading does change with respect power applied to the hot end. And with both the LCD and host interface, Pronterface and Repetier all report MINTEMP

Is this related somehow to the new version of the Arrduino IDE?

thinkyhead commented 9 years ago

@Grogyan It might be something in the new IDE - I can't be sure. I did find a small flaw in the heater code, but it doesn't appear to be related to this issue. At the moment I'm comparing the old code in temperature.cpp to the new code, to make sure that there is true parity.

thinkyhead commented 9 years ago

@Grogyan Try #1660 and see if it helps. It might already be merged into the Development branch by the time you read this.

Grogyan commented 9 years ago

Tried it, still getting the error.

Noticed that it pops up as soon as USB com port is opened

thinkyhead commented 9 years ago

@Grogyan I'd like to see your configuration files, specifically looking for any complex defines that might have calculations in them, but which don't have parentheses around them, just in case there's some code like d = PID_MAX / 2; being expanded, when it should be d = (PID_MAX) / 2; to get the right value. Meanwhile, still comparing the temperature code from 1.0.2 to the current, but nothing has jumped out yet.

AnHardt commented 9 years ago

Got my MAX6675 this morning but will not be able to connect before Monday.

In the meanwhile one could set a jumper on the open (i suppose) analog temperature pins. When the behavior changes (MIN<>MAX) we know that we are somewhere asking the analog ports instead of the MAX6675.

Grogyan commented 9 years ago

Configuration.h http://pastebin.com/MWE81C1V Configuration_adv.h http://pastebin.com/DbDQxWsd

Nothing special being done to the config file. Just setting the thermocouple, and enable the Full Graphic display

thinkyhead commented 9 years ago

Ok, with the MAX6657 this code snippet is questionable…

#ifdef HEATER_0_USES_MAX6675
  ...
  OUT_WRITE(MAX6675_SS,HIGH);

  // The line above replaces this from 1.0.2:
  //pinMode(MAX6675_SS, OUTPUT);
  //digitalWrite(MAX6675_SS,1);

#endif //HEATER_0_USES_MAX6675

Which translates into:

DIOMAX6675_SS |= MASK(DIOMAX6675_SS_PIN);
if (&(DIOMAX6675_SS_RPORT) >= (uint8_t *)0x100) {
  _WRITE_C(MAX6675_SS, 1);
}
else {
  _WRITE_NC(MAX6675_SS, 1);
}

So, perhaps that would be good to revert...? Or was 1.0.2 incorrect?

Grogyan commented 9 years ago

I don't believe the MINTEMP error is actually referring to an error with the Temperature code. But rather, maybe something not getting initialized properly at boot.

This is the output log of Repetier, note that I also get the error even with a thermistor http://pastebin.com/EWVAw7Se

Something getting lost with stuff loaded into EEPROM, even when EEPROM is not enabled? I'm just banging rocks here. Just really eager to test out the fix for the MAX6675.

In my RAMPS setup, I did load factory settings into EEPROM a month or two ago, since then I have not enabled it again till this error is resolved.

AnHardt commented 9 years ago

Partially good news for the SPI-SD-MAX6675-complex.

Connected my new MAX6675 this morning and got good temperature readings but the MINTEMP-error. (Arduino 1.6.1 - current Marlin including merge #1675 - FULL_GRAPHICS_CONTROLLER) Commented out 'temperature.cpp' lines 541 and 542 to get rid of the MINTEMP-errors by brute force. Uploaded a big file to the SD-Card via Pronterface. Compared the new file with the same previously uploaded file without the MAX6675. No corruption! Got some differences where M105-statements are distributed differently. This seems to be a problem with Pronterface what does not stop to ask for temperatures during upload.

I'm confident that the SPI-SD-MAX6675 problem is solved when we have caught the MINTEMP bug.

Going back to MINTEMP problem now.