Print stops every time at the exact same line of Gcode.

Hi

I'am Gregor, and coming from Austria.
I have built a standard Reprap mendel and I am now
in progress of finetuning the machine and troubleshooting
some small but also big problems. I hope you can help me
with such big problem, which frustrates me
for over 3 days now, and is driving me crazy.

My setup:
* standard Mendel
* with Gen3 Electronics
* Firmware is orignal "reprap-mendel-20100806"
* Adrians geared stepper Extruder
* 8 times microstepping on X,Y,Z axis using the capabilities of the A3977 Chip
* using Replicator G 0025 for printing and Gcode generation

Everything works fine so far. The Extruder works, the X,Y,Z Axis work also perfect. I've done also some complete prints which were perfect. So I am soooo close to finish my project "reprap", if there isn't that annoying error.

On one hand, some generated Gcode-files print out unitl the are finished. On the other hand, there are Gcode files which everytime produce a resend request on the exact same line of GCode. Undependend of what Skeinforge parameters I use. And i've tried many, but everytime the print stops at the exact same line. So this is maybe a firmware issue. If it is a transmission error this would occour much more random, and not evertime on the exact GCode line.

So I thought lets disconnect everything connected to the Motherboard except power and serial, to narrow down the error source. And guess what? The same error again. Everytime on the exact G-Code Line.
As you can see on the attaced image:
1. ReplicatorG sends the G-Code line
2. The line is beeing processed in the firmware, but it seems some string to int conversion fails or the string is not parsed correctly. So some characters are lost during the parsing process.
3. Firmware detects a mismatch, and requests resend.
4. Replicator G resends the GCode line
5. Firmware accepts it and returns ok.
6. And now the problem. After the firmware returnded FW Accepted: ;resend-ok the print is halted forever. ReplicatorG freezes. So I can't abort or pause the print or disconnect the machine. So I only could close ReplicatorG.

So what causes this problem. Anyone had the same issues before. Is there a solution out there? Please help!

Thanks in advance,
Gregor

Edited 1 time(s). Last edit at 10/02/2011 12:22PM by Gregor_R.

Looks like the resend is successful, isn't it? So, either ignore this or fire up your Arduino IDE and add debug messages to the firmware to find out what's received vs. what's sent. Possibly some sort of variable overflow.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Was the resend really successful since it didn't echo the command back? In the previous line, it echoed "FW Accepted:..." with the line that it received. In the one that had a checksum error, it never echoed the line back. It might be a communication error. Gen 3 is prone to that.

@ Traumflug

How should I ignore that? After the "FW accepted: ; resend ok" the reprap doesn't print anymore. It freezes forever. Until I switch it off and on again or press the Reset Button on the Motherboard. If I do so, the print is useless.

A variable overflow might be a possible reason. Interestingly the error everytime occours on the beginning of a command. As you can see in the attaced screenshot, some characters are lost. So for exampe: N201 G1-43.02 .... leads to N2G1 -43.02. The error has never occoured in the middle or the end of a command. And I have debugged nearly over 30 errors.

Edited 1 time(s). Last edit at 10/03/2011 01:24PM by Gregor_R.

I also have a pretty similar setup, down to a3977 hehe. With the 20100806 i also had same issue and found no end to it. The rs doesnt appear often, and not in each print, some small prints will work allright. Resend is not fatal by itself, at start, but turns into some weird avalanche of resends which become fatal. I also experienced certain prints stuck at exact same point. Also I think its usually caused by very long lines, so have SF set to "gcode small". Resends gets "jammed", e.g. if i get 4 buffered lines, once first resend happends, each of the next lines in gcode file is sent 4-5 times over and over again untill machine gets stuck later on. If the buffer in config is set to less then accordingly less rs will happen for each line. What i think happens is that the new linenr isnt updated so all the following lines need multiple resends each untill they get past the line buffer. To check this, when at the printer and you see a rs in comms, press pause printing, and buffer empties, then un-pause and it continues to print normally afterwards. Use repsnapper comm log to see this happening, or repetitier if it works for that firmware dunno. However this cant be a real fix since it cant work unatended, and one cant stare at comm lines for half a day.

I used another version for a while and i found it pretty reliable on the overall although had tones more of rs, like one rs each 50 lines, but fixing itself and none become fatal. But the thing i would really want to say is to start using Teacup, if u need a little push to this direction i mentioned my config files here and i hope those work for you although ofc some tweaking will be required. I am confident that you will find it much better.

Edited 1 time(s). Last edit at 10/03/2011 01:20PM by NoobMan.

Thanks NoobMan for your detailed description. Maybe I'll give the Teacup firmware a chance.

Ok
I've downloaded and burned the teacup firmware with NoobMan's config files. I can connect with the machine and all the axis move correctly. Haven't adopted my configurations out of the reprap firmware to the teacup firmware, because this should only be a first test, to see if it works or not. (I've used other aluminium gearwheels on my reprap), so the steps/mm have to be adjusted in comparison to a standard mendel.
I can also make the extruder turn and read out the extruder thermistor temperature. Which is by the way at least 5°C higher than the reprap firmware read out. I can also turn the Extruder heat on and off.
I'am using the extremly tiny and fragile EPCOS Thermistor from RS-Components.
[tinyurl.com]
Everyting is totally fine, except that i can't read out the temperature of my heated Bed. I can turn on the heat, and the bed gets hotter and hotter and if i measure the resistance of the NTC with a multimeter it changes continously, but the firmware doesn't recognize this, and all what it gives me is 0°C.
I think there must be a #define statment to activate the heater. Which i found and uncommented. But nothing changed. Then I've increased the NUMTABLES define from 1 to 2 and appended the same temptable after the first. See the code below.

// default thermistor lookup table

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

#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
},
{
   {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
}
};

So how can I fix this?

Edited 1 time(s). Last edit at 10/03/2011 04:44PM by Gregor_R.

The way it was default, it worked with 1 table for both temperature readings. I think your changes made 2 different tables, e.g. to be used in case of 2 different thermistors.

If the bed temp is not working, see config file for extruder board and check if the right ADC pin is set. I think its 6, maybe its connected on 7, which is the one nearby. But its probably correct. To debug, in ec22 firmware, try changing the pins between extruder and bed, and see what happens, it should read bed temps now as E:xx, thats only to test the sensor. Also in ec22 firmware, you have bang-bang defined or pid?

I think its probably smth with mb config which may explain reading exactly 0. Post your config files it might help.

In the firmware for mb12, at chapter 4 and 5, dont define temp sensors and heaters, just
#define TEMP_INTERCOM
DEFINE_TEMP_SENSOR(noheater, TT_INTERCOM, 0, 0)
DEFINE_TEMP_SENSOR(bed, TT_INTERCOM, 1, 0)
#define HEATER_bed HEATER_noheater
#define HEATER_BED 1
thats all, i think the rest is for sensors and heaters directly attached to main uC. Also interesting because i think if you had some parts of those wrong, i think it would of reported only E: and and B:0 wouldnt of appeared at all.

Edited 3 time(s). Last edit at 10/03/2011 06:50PM by NoobMan.

Dont miss out to calibrate your thermistor table against thermocouple. At 180-230C temps thermistors wont be interchangeable and therefore their tables wont either. To calibrate, put multimeter thermocouple near heater. Or best place would be inside the barrel where the plastic melts. Heat up the heater at say, first value from table (the teacup table 2nd column is temp x4) and when the reported temp stabilized, we know we "tricked" the system to read that value on the adc pin (or close). When it reads the old table value, means its adc reads the table value to the left (or smth like that as principle). Thats the important thing, and you read what multimeter says and simply put that value to the right. Or to be correct in our case with teacup, again, that value x 4. Repeat for all other values. Do that for rest of values. This way: screw beta. Beta equation(s) will get you so far as 150-170C, after which you will see more and more errors showing up. Basically you will have to calibrate/change values for each table values with temps after 150C, more or less.

Done like this, it offers you a reading that is correct on the entire range. And again it doesnt matter if you use 100k or 200k or 10k, or whatever beta is, or what r1 r2 or c values are or if exists at all. Its just like a closed loop system you are adjusting, it doesnt matter what is inside the box, only what box output is. Its just you get for each adc value a real life thermocouple reading. Thats all. Where previously done tables come in handy, is that we dont need to discover the start and end parts of the adc interval (we could do it empirically tho) as different sensors would output different voltages, but this way we have an ideea where to expect readings. And also we couldnt get starting values of the table, say for temps less than room temp - well unless we do it with our heads in the refrigerator.

This way you end up with a system that will read as good as a thermocouple +/-1~2C. Well, actually thats what you fed in, so it better be good. If you wait a few sec for each temp level to stabilize, it will be perfect. Between values will try to interpolate, so besides feeding correctly read values, its also important for the adc intervals to be as low as possible. The table i linked starts from 15 and ends to 265 (last 400 is just provisional) and has somewhat equal intervals, although you can use smaller intervals in the temp range of interest (~extruding temps, ~hb temps) and big intervals where the readings dont matter. I for one use same table for both HB (low temps) and for extruder (high temps). I dont think that within a 15C interval the linear interpolation could give an error more than say 0.5C, so the biggest part of errors are human, like came from me rushing the calibration and reading the temps faster, sort of near the adc value the old table targetted.

Edited 3 time(s). Last edit at 10/03/2011 06:11PM by NoobMan.

Hey
I think I've found the problem. But I have no idea how to solve it yet. But it's late (1:48 here) and I should go to bed
I am using a ATMEGA168 on my Extruderboard. I've studied the pinouts of the TQFP package version. [www.atmel.com]
... and compared that with the extruder code. And i've found something that took me aback.
Let's have a look at the following piece of code.

#define AIO5_PIN		PINC5
#define AIO5_RPORT	PINC
#define AIO5_WPORT	PORTC
#define AIO5_DDR		DDRC
#define AIO5_PWM		NULL

#define AIO6_PIN		PINC6
#define AIO6_RPORT	PINC
#define AIO6_WPORT	PORTC
#define AIO6_DDR		DDRC
#define AIO6_PWM		NULL

#define AIO7_PIN		PINC7
#define AIO7_RPORT	PINC
#define AIO7_WPORT	PORTC
#define AIO7_DDR		DDRC
#define AIO7_PWM		NULL

As you can see AIO6 is defined as PINC6. A quick look in the Datasheet of the ATMEGA168 reveals that Pin PC6 is actually the RESETPIN So it is logical that there are always 0°C read back. By the way: There is no PINC7 existing on a standard ATMEGA168.
So NoobMan you must have a other AVR on your Extruder controller, if yours is working.
In fact the TQFP version of this AVR device has two additional ADC pins, which the DIP version doesn't. These two pins are called ADC6 and ADC7. The problem is that these Pins aren't part of a I/O port, but separate only analogue pins. So I will have to change the firmware a little bit.

This is gen 3 electronics extruder controller 2.2 which i understood you have: [www.reprap.org]
My own boards are pictured here and are same in most regards.
Techzone Gen3 remix [www.reprap.org] i believe it to be also pretty much same schematics just with compacted layout.
Yes extruder board of Gen3 has tqfp version of 168 and has adc pins 6 and 7 and these a bit different from the others.


Isnt that what you got? What you got then, can you post picture(s)?

I never saw an extruder board with mcu in DIP package. And if you did that yourself... can i ask why? Do you use a DC extruder motor with encoder? Extruder controller its an relic from the old time of DC motor extruder, now we dont really need it anymore. Its like an apendice, nowadays only causes inconveniences.

Edited 2 time(s). Last edit at 10/03/2011 10:06PM by NoobMan.

Hi it's me again.

I have a very stressful week behind me. So I had no time to update this thread. So here's is the update, and there are very good news.

The teacup firmware is runnig perfect on the Gen3 Electronics. The problem with the temperature reading of the heated Bed, is actually a problem of ReplicatorG. The firmware passes extruder and heated bed temperature trough the serial interface properly, but ReplicatorG only displays the extruder temp. The Repetier Host software displays the temp values just fine. I've also found out what's behind the "problem" with the separate analogue pins. In fact it's not a problem, because the ADC- function doesn't need the Port and Pin defines to work correctly. The only thing which is important for the ADC function is the number od the channel which is multiplexed to the ADC unit. And for this multiplexer the value "6" is a valid one. So there was actually no problem in the firmware, it worked fine from the beginning.

@ Noob Man:

Yes your self built electronics look amazing. Good work.
I've done the same thing, I made them up completely my own. First of all I had to relayout the pcbs because there are vias underneath the SMD ICs, which you then can't solder with the "wire" technique. Because i was already relayouting the boards, i also cleaned up the really messy original pcb layout. Will be better for signal integrity too . I've etched drilled and populated all my boards my own, so you presumably also did. I've also used a solder mask resist called "bungard Dynamask". It is a dry laminate, which is laminated onto the pcb after etching and cleaning. After uv- exposure (negative Film) and etching with Natriumcarbonate you have to harden the laminate for about half an hour under uv- light and then another half hour in a good ventilated oven at about 150°C.







I have already made some prints and they came out pretty well. Of course there will be some fintunig left to do. But the whole reprap moves smoother, and responses faster. Also the extruder retraction finally works, which it never did propery with the 5D firmware. And the most important thing, it has never freezed up to now, and i've printed up to 6hours in one go .

Tomorrow I will get my camera out and take some photos of the prints.

Greetings, Gregor!

Nice, and BIG congratulations!
Very nice job really. Your boards look very pro, way better than mine. )
Check the firmware config.h and see what compatibility date you have set - set the latest.
I havent used repg much myself, in general i prefer the other alternatives, atm i find Repetitier to be pretty sweet.

As an aside, I have to wonder why the wiki is still encouraging people to build Gen3 electronics. The alternatives (RAMPS, Sanguinololu, Teensylu, Gen7) are far superior, far easier to build, and less likely to cause issues.

I think because those parts of wiki are old, outdated, and nobody really got back to them to change them appropriately. Some pages do have mentions like gen3 depercation note on top, and this i guess shows a more current situation. Probably too hard to find all places gen3 is mentioned and add warnings everywhere, but its a good reminder that something like that should be done at each chance given.