Teacup/Gen7 buggy print with M101 & M103

Hi all!

I am changing my Mendel electronics & FW to Gen7 & Teacup. Making my first test prints, I could'nt get my hexagone without a "big bug": one of the faces is replaced by a descending wall going to the center of the bed. Using Multiply plugin into Skeinforge, this wrong face goes outer the hexagone, to the center of the bed too. After a long long search I understood that my print was buggy because of M101 & M103: without thoses codes the print is OK…!

So what to do with M101 & M103? There are deprecated but used by Teacup (I forgot the reason why…) an must be present…

I attached my config.h too. I am using Gen7 branch of Teacup, commit 85e29e8c91.

Thanks for your answers !

---

François

try changing this line in config :
/// this is how many steps to suck back the filament by when we stop. set to zero to disable
#define E_STARTSTOP_STEPS 289

to this
#define E_STARTSTOP_STEPS 0

and work from there.

every time a 103 command goes thru it backs up 289 steps. just a guess

Thanks for your answer… which proudly solved the problem…!

But I don't figure out why an E parameter plays with X & Z toolpaths, how did you guess that?

I suppose we suck back filament to avoid oozing; now my E_STARTSTOP_STEPS equals 0, I'll try to increase it little by little before this crazy geometry comes back…

---

François

I spent a half hour going thru the source code, and verifying your config.h. whenever your m103 code is sent the extruder was pulling feedstock back 289 steps worth. the missing side on your picture is the amount of time and distance for the feedstock to feed back thru to the nozzle and allow it to again pressurize and start extruding.
I figured it was a ghost setting from forking the config over to the new firmware. It's easy to have happen.
glad the setting change worked for you.

Actually, the E_STARTSTOP_STEPS number is micrometers now. But the principle it the same.

As other firmwares didn't have auto-retract until recently, none of the G-code compilers produced appropriate commands, but did retracting with additional G-code (G1). Recently, auto-retract was re-invented and implemented as M227 ... M229. I haven't found out which mechanism/situation triggers modern firmwares to execute the auto-retract, yet.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Many thanks for your research into firmware and the time you spent for this! I should'nt have the idea to investigate the firmware… just found the switch statement into gcode_process.c…

After further trys, the only good value for E_STARTSTOP_STEPS is 0, the geometry error comes back when the value is bigger. As you said a ghost effect…