Teacup: random communication hanging and axes crawling

Hello!
I am using Teacup Firmware on Gen7 1.2 and printcore.py as sender. I have experienced a strange problem recently. Chip randomly stops responding mid-print and axes crawl like "At one feedrate, the axis will suddenly slow down to a crawl (1 or 2 steps per second) due to ATmega's processing power exhaustion." from Teacup wiki page. It happens very randomly, sometimes around 400-600 line of GCode, sometimes after 10k or more. Firmware temperature/heaters loop stil works as LEDs are going on and off like under normal conditions.
After finishing all moves, I can communicate with printer, but any subsequent buffered motion command cause very slow movement. No matter how long I wait before executing manual commands, nothing changes. Also, quick reset and everything works again as expected. Teacup debug output (mode 6) is consistent with input GCode. One weird thing I noticed was value of "c" variable returned by M114 command, it was always 0.
I am attaching my config.h if it may help pinpointing a bug. I am running out of ideas what might be wrong.

*Host OS: Windows 7 64-bit on laptop
*Host: printcore.py (master) running on 32-bit python 2.7.3
*USB-TTL: Arduino MiniUSB

I will appreciate any help or advice.
Best wishes,
Mark

Quote

One weird thing I noticed was value of "c" variable returned by M114 command, it was always 0.

That's a symptom of the problem and probably the cause of the crawling. Should never happen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi!
My recent test run revealed that something is wrong with RAMPING acceleration, which is default. Crawling happens randomly, but no matter how I set movement, every axis steps at the same very low constant rate. Change to REPRAP acceleration allowed me to run whole 36k lines gcode. Also debug output changed, no more constant 0 as "c" value. Ramping acceleration has a few comments about wrong code and TODO.
Reprap linear acceleration seems to be slower than ramping, but introduces less vibrations. It also proved that neither my motors nor drivers overheat.

Best wishes,
Mark

There may be something in the timing of the gcode lines, does printcore.py verify data with a checksum, or assume a certain time to run the code and just send commands in advance? what may be happening is the buffer fills up, and printcore.py keeps sending data. Does the baud rates on host and firmware device match?, and is there a way to slow down or delay sending commands?

Hi!
Baud rate on device and host is the same 115200. Delay seems unnecessary with reprap acceleration, ramping causes problems, gives constant 0 "c" value and this crawling. GCode is sent just fine, slower on longer moves, faster on arcs. Same file with different acceleration, reprap allows to run whole file, ramping causes stop at 6-8k. It's not a matter of sending more than there is space in buffer. I'm not so familiar with printcore code, I don't know where should I add delay or if it validates checksums, but it sends them. Even after stopping sending file and finishing all moves, any new buffered command causes this behaviour. Unbuffered commands like M105 still work fine.

Best wishes,
Mark

Quote

Crawling happens randomly, but no matter how I set movement, every axis steps at the same very low constant rate.

As Teacup is convinced about the reliability of its algorithms, c is set only once after a reset. After that, it's calculated up and down as required.

Once c is zero, the step timer is set to zero, too, which causes the timer to fire only after an overflow. This should result in always F_CPU / 2^16 = 20'000'000 / 65536 = 305 steps per second. At least that's what I guess to happen.

I consider faulty G-code as a unlikely cause, too. There I'd expect different symptoms, like occasional dropouts with recovery.

Quote

Same file with different acceleration, reprap allows to run whole file, ramping causes stop at 6-8k. It's not a matter of sending more than there is space in buffer.

This sounds like you have a test case! Great! If you can switch between working and not working reproducible, 50% of fixing the bug is already done. Could you tell me which acceleration works and which not and also add a G-code file showing the crawling?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi!
The working algorithm is ACCELERATION_REPRAP. ACCELERATION_RAMPING causes this weird behaviour. What is really odd about the whole situation is that any longer file causes this. I tried 4 different files sliced by Slic3r 0.9.9. All attempts resulted in crawling at some point. My machine is a bit slow, so it takes some time before getting buggy.
With RAMPING, M114 always returns "c" as 0. Also manually issued buffered commands just after start/reset return "c" as 0. REPRAP acceleration gives some big but reasonably looking values.
I'll try tomorrow switching to RAMPING acceleration. It's so hard debugging embedded code without more complete overview of what's going under the hood.
All four test GCode files in attached 7-Zip archive.

Best wishes,
Mark

You're experimenting ACCELERATION_REPRAP? That's an entirely different strategy of accelerating: all movements start at the previous F value and end at the F value given in the current G-code command. One move either accelerates, decelerates of keeps speed, but doesn't do a combination of these. The idea of this strategy is to do ramping computations on the PC side. Good old RepRap Host tried to serve this, but this strategy never got a foothold in the community.

In contrast, ACCELERATION_REPRAP accelerates, moves at constant speed and decelerates all with one command. That's the usual strategy, also used by Sprinter, Marlin, Repetier, GRBL, ... All slicers these days serve for this strategy.

I'll try with the G-code you provided wether I get the same results.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I just tried with your G-code ... and found your config.h requires TT_NONE, a (now obsolete) thing removed from Teacup back in November. Apparently, your Teacup sources are pretty old. Could you please update your copy and try again? This also requires starting with a fresh copy of the config.h template.

Other than that, your G-code runs apparently fine here. In case it still doesn't for you, you can insert something like this in dda_start() to debug this c:

sersendf_P(PSTR("c: %lu\n"), dda->c >> 8);

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY