Negative extruder temp when SD card firmware included

Hi There,

I have been having what I believe are some random stepper skips as a result of activity on my host machine that cause subsequent layers to become offset in random directions (X and Y) after successfully printing the first 6-8mm of height of a 20mm test cube. My Prusa i3 is correctly calibrated for movement in all axes and also for filament extrusion, however when say the screen saver wants to kick in, or some other background takes requires too much CPU, the communication to the printer slows right down and re-transmits go up and steps are missed.

To try and combat this issue I decided to try printing from an SD card, however as soon as I upload the new firmware (only change in configuration.h is for changing '#define SDSUPPORT false' to 'true') when I next connect to the printer, via Repetier Host, it now shows the extruder temperature as -20C as opposed to around +19 or +20C. This is the same regardless of whether or not the SD card unit is actually connected. Disabling the sdsupport setting and uploading firmware once again and everything goes back to normal.

I am using an atmega1284p chip on a sanguinololu board running the latest Repetier firmware (0.91.7), I have made no changes to pins.h or ui.h, and only changes to configiration.h that affect steps/mm, the size of the printer and one for Z acceleration which was causing the Z axis to miss steps.

The pins.h definition of the SDSS pin for a Sanguinololu is D31 (or A0, or physical pin 40), the Extruder thermistor uses A7 (or D24 or physical pin 33), the heated bed thermistor uses A6 (or D25 or physical pin 34) all as per the default wiring for a Sanguinololu board.

I do not believe I have a short on the board as I regularly use the ICSP connections for re-loading firmware and I have had the SD card working on this same board with a much older version of Marlin at some point in the past, plus this is pretty wide spacing for header pins with large gaps in between..

Like I have already stated, the printer runs fine (albeit with some occasional missed steps) without the sd card firmware enabled, however once enabled the printer will disable itself after about 30 seconds due to negative temperature readings from the extruder thermistor.

Any guesses?

Zebethyal

Sounds like sd card uses the same pin as temp. sensor. Please also check the sd card detect pin and sd select pin.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Many thanks for your response.

I agree and that was my first thought as well, however I cannot find anywhere in the source code where this conflict may be happening.

The SD card uses the SPI bus pins - MISO (D7 or physical pin 7), MISO (D6 or physical pin 6), SCK (D5 or physical pin 8), CS/Chip Select (D31 or physical pin 40), as well as +5v and gnd all of which are presented as a group of connectors in one corner of the Sanguinololu (5 of these are also used for ICSP, along with RST (physical pin 9)), all as per a standard Sanguinolu and also standard settings in pins.h.

There is no sd card detect pin presented on the header of the SD card interface module, nor can I find a reference to it in the Repetier source code relating to a Sanguinololu board (for other boards - yes, but not this one).

None of these connections are anywhere near the pins for the extruder temperature sensor (D24 or physical pin 33), the only reference for any other board that comes close being SDCARDDETECT pin as D6 on a FELIXprinters board, would potentially be sharing my MISO pin, but MISO is pin 50 on this board.

I wondered if I should possibly add a define for SDCARDDETECT as -1 similar to RAMPS, as the Sanguinololu will also not support this port, however on tyying this it made no difference, probably because it is already the setting as defined in configuration.h just below the SDSUPPORT definition that enables the SD card usage anyway.

I have also looked at the board layout within Eagle and cannot see how any type of short I may have overlooked could have such a profound impact when the places where any of these signals come near or cross the E-Therm signal are on opposite sides of the board, and as I say I am sure I would have noticed this sooner.

I have also checked continuity and none of the pins associated with the SD card are common with the signal pin from the extruder thermistor.

Having said all of this, I am able to mount the SD card and see the files on it, I just cannot print from it as the printer is disabled the moment I mount the SD card and the extruder thermistor is permanently set at -20C. something I did not worry about on my previous testing as at that time I was still building the printer and did not actually have an extruder attached.

Edited 1 time(s). Last edit at 11/17/2014 11:46AM by Zebethyal.

Ok, I also can not see where that pin number should come from. If you have a look at Printer.cpp you find

Extruder::initExtruder();

which initalizes extruder sensors. sd card init comes later.

#if SDSUPPORT
    sd.initsd();
#endif

you could try copying initExtruder line after that to overwrite the transformation into an output. That should reset the overwritten part. It's still the question where the pin get defined as output. Guess is sd.initsd since you said it happens as soon as you call it by enabling sd card.

You can also output the real value of SDCARDDETECT there

Com::printFLN(PSTR("SDCARDDETECT="),SDCARDDETECT);

then you see if it is this var. Repeat it with other variables you may thing could be the reason.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hi There,

Thanks once again for your help, the ability to display variables has allowed me to test out all sorts of theories, most of which have proved nothing beyond the fact that the variable has the correct value.

Progress update.

Well I can confirm that the SDCARDDETECT variable is set to -1
I can also conform that all the other variables that I have checked are also set to the correct values, here are just a few:
EXT0_TEMPSENSOR_TYPE=8
NUM_EXTRUDER=1
TEMP_0_PIN=7 (Analog value)
EXT0_SENSOR_INDEX=1
EXT0_ANALOG_CHANNEL=7
MOSI_PIN=5
MISO_PIN=6
SCK_PIN=7
SDSS=31
SPI_FULL_SPEED=0

I had the digital pin definitions switched for MOSI and SCK in my second post, the physical pin definitions were still correct - the correct settings are present in the firmware and on the physical board, I have also double checked this with the chip pinout from Atmel and with Arduino.

I tried changing the order of initialization, as you suggested, for the SD card and the extruder - unfortunately it made no difference, the extruder temperature still shows as -20C and the printer is still disabled due to an invalid temperature.

I have even soldered up a second sanguinololu board and connected up the thermistors and endstops, This new board exhibits exactly the same behaviour, so I believe this test pretty much rules out a hardware issue (boards were even manufactured in different factories).

For both boards, the SD card can be mounted and files can be seen on the card, which shows me that I also have the SD card wired up correctly, likewise for both boards, with SDSUPPORT set to 'true', the extruder temperature is permanently at -20C, and yet with SDSUPPORT set to 'false' the thermistor values show correctly.

On the plus side, I am becoming more and more familiar with the code, although I still have yet to have any revelations with regards how/where the problem occurs.

Regards

Zebethyal

Edited 2 time(s). Last edit at 11/18/2014 11:26AM by Zebethyal.

On further testing, I can confirm that the call to sd.initsd() is what causes the extruder temperature to go to -20C.

Preventing this call allows the extruder temperature to read normally, attempting to mount the SD card will then call the sd.initsd() function which in turn calls the fat.begin() function and immediately the card is initialized, the extruder thermistor goes to -20C.

I tried swapping the pins for the Extruder and Heated bed sensors and all that happened is that the Heated bed thermistor experienced the same issue, started reading -20C and again was disabled - this ties the issue to Analog pin 7 and a possible conflict with digital pin 7 (SCK).

For the short term, until we find what is causing this, I have left the pins swapped for the Extruder and Heated bed sensors and likewise swapped the connections on the board, then I disabled the Heated bed in configuration.h - at least this will allow me to print albeit without the benefit of a heated bed.

Regards

Zebethyal

OK, I believe I have found a solution.

I am not entirely convinced that the digital pin numbering for the physical pins 33-40 is correct, there are differing sets of information on the web as to how Arduino maps these pins, the pinout shown in pins.h shows physical pin 33 as Analog 7 and Digital 24, with numbers decreasing for Analog and increasing for Digital up to physical pin 40 which shows as Analog 0 and Digital 31.

Pighixxx.com shows a different pinout with physical pin 33 as Analog 7 and Digital 31, with numbers decreasing for both towards physical pin 40 which shows as Analog 0 and Digital 24.

Short of running up a piece of code to check this out on a breadboard using LEDs to prove which physical pin is actually which digital pin, I am at a bit of a loss.

[www.pighixxx.com][gallery333]/0/

However, I decided to try moving the SDSS pin definition to Digital 24 and something different happened - instead of going to -20C on mounting the SD card, instead it went to about 998C! still obviously wrong, but at least it is a different result, the thermistor signal pin has gone high as opposed to low.

Further checking of the pinouts and datasheet shows that the correct pin to be using for SS with an SD card is actually physical pin 5 (Digital 4), this is also presented on the Sanguinololu board but with the name of PWM/D12, the D12 is somewhat misleading as this is more likely to mean PCINT12, and in the schematic shows as PB4-PWM wihich again are other names for this pin as defined in the Atmel datasheet (PB4/SS/OC0B/PCINT12).

After moving the CS/SDSS pin to D4 (physical pin 5) all appears to be working correctly once again - the SD card can be accessed and both thermistors are sending sensible readings.

Regards

Tim Moores