Extruder stops extruding

javitopia

Hi, I'm having problems with repetier firmware 0.92 (latest) wich I been having for some time (several months). The problem is that the printer stops extruding somewhere mid print (but continues printing and heating, just like dry-run, or when a heater is decopled). However, there is no mensaje in the lcd nor in the repetier host (the log shows the layer progress).

The printer won't extrude until restarted, and it could happen printing with repetier host or from sd-card and from different slicers. I'm pretty sure is related with repetier since both the motor and the driver have been replaced and another user in the reprap forums reported that switching to marlin fixed it.

Any way to get more info from repetier so there is something to start working on?

BTW, the printer is a delta

Repetier

Normally I would say decoupled triggered, but then you would see dec in lcd display.

I also do not think dry run got enabled? You could then try toggling dry run on/off to make sure or check in lcd debug menu.

The last reason not to extrude would be temperature to low, but you also said it is still heating.

These are the official cases where it is supposed to stop.

As you can print after restart I also guess it is not blocking.

So first is, is motor still enabled when it happens (can you turn it).

Does M302 S1 help (cold extrusion allowed)

You could compile with

#define DEBUG_QUEUE_MOVE

when you then enable echo it gives many log messages (so disable quickly after it). It shows one line with delta steps with 4th position = extruder steps. Question is if that value is always zero or contains a value. If it is zero some internal mechanism prevents extrusion, if it is not zero it should send stepper signals and might be thermal protection or something else.

javitopia

Normally I would say decoupled triggered, but then you would see dec in lcd display.
I also do not think dry run got enabled? You could then try toggling dry run on/off to make sure or check in lcd debug menu.
The last reason not to extrude would be temperature to low, but you also said it is still heating.

Exactly, it's not a decopled sensor since the log doens't complain about this at all, nor cold hot-end since the hot-end remains at it's setpoint temperature. Also, enabling and disabling dry run would not solve it.

These are the official cases where it is supposed to stop.

As you can print after restart I also guess it is not blocking.

As for blocking, i'm pretty sure the printer sitll accepts commands (i could move it from repetier host) but to make sure, i'll check.

So first is, is motor still enabled when it happens (can you turn it).

Does M302 S1 help (cold extrusion allowed)

You could compile with

#define DEBUG_QUEUE_MOVE

when you then enable echo it gives many log messages (so disable quickly after it). It shows one line with delta steps with 4th position = extruder steps. Question is if that value is always zero or contains a value. If it is zero some internal mechanism prevents extrusion, if it is not zero it should send stepper signals and might be thermal protection or something else.

Ok, the next time it happens i'll test that and report back. I'll also redo the last failed print to see it they fail at the same time (i allways tied to resume those prints, so i haven't tried reprinting the failed print)

javitopia

OK today happened again but enabling and disabling dry run from the host "solved" making the printer do a big extrude (arround 50mm) before continuing painting.

I enabled and disabled dry run while the printer continued painting mid air.

How can I check what is triggering dry run? The log is "clean" it only shows a checksum error at the first layers (and the printer continued painting normally) and BLK 5 (I know it means that the path planner was late for generating a stepper signal, but not the exact meaning of the 5). Could this be related? Unfortunately, I haven't recompiled the firmware yet so no additional debug info

Repetier

Ok that is strange. First the BLK shows buffer length when block happend I think. In any case it is not relevant for the dry run propblem.

Question is what changed dry run variable. To be sure you would need to write a different print command for each place where debug could change. Then in thery you should get a message when it happens so you know exactly when in in which combination it happens. Then we might see what the real reason is.

Theroy because it could also be a out of range array operation overwriting a memory area where it should not happen. But first lets assume some function calls it explicitly.

iceman1306

I seem to be having a similar problem. Extruder stops extruding randomly while printing, hotend, bed and all axes continue. Extruder won*t move until reset/restart. 

javitopia

Unfortunately, I'm upgrading some parts of my printer right now, so I have stopped testing. As soon as I have my printer back to business, I'll resume the testing with one of the problematic prints to check if the printer stops extruding in the same line. 

Iceman: try enabling and disabling dry run from repetier host (or check in the lcd if dry run is enabled). The last time I had the problema the printer resumed extruding after I did that (although the print was ruined since it missed several layers). Please check that to see if we have the same problem. Also, do you have a delta printer or a Cartesian printer? (all printers similar to the prusa, are Cartesian. )

iceman1306

My printer is a cartesian printer with a coreXY setup. I will check the dry run later when the kids are sleeping.

iceman1306

So a quick test shows as follows:

motor is not enabled after it happens, it can be turned by hand.

M302 S1 does not help

checked dry run in lcd display, was enabled

after disabling, extruder is enabled again, can be moved by octoprint.

The item I tried to print is about 20x20 mm, 9mm height. At roughly 4mm z-height the extruder stopped, octoprint ran through until the end.

iceman1306

Does the firmware switch into dry run under some conditions? I noticed that the hotend temperature dropped some degrees when the PLA fan came on, and it came back up to where it should be very slowly. Will it switch to dry run if hotend temperature stays below target for time x? Will make another test without pla fan...

javitopia

The firmware will enter into dry run mode if one heater is marked as decoupled, wich could happen if wile running the temperature drops (or increases) 20 degree below set point. However in these cases the heater is marked as decoupled (it shows Dec instead of the temperature) y and you get a message in the log stating the cause (wich could be due temperature difference or for slow rise when heating).


The problem I'm having is that the printer enters dry run mode but there is no error mensaje, not even the mensaje you have when entering dry run mode manually, so I have no clue why is this happening, and it only happens with large prints (longer than 4 hours) but can happen early in the print (as soon as 10 minutes) but I never experienced those problems with shorter prints.

iceman1306

OK so without pla fan the hotend temperature stayed where it was supposed to be. And no dry run this time, print was successfull!

Repetier

So your problem then comes more from a decoupled recognition. That should be easy to provoke if it is the drop from fan enabling. You need to relax the conditions so you do not trigger false positives any more. In worst case you can set 

#define EXT0_DECOUPLE_TEST_PERIOD 0

in the latest release to disable decoupling test completely. But maybe better only increase

#define DECOUPLING_TEST_MAX_HOLD_VARIANCE 20

if heater really drops more then 20°C (which is quite much for a fan that is supposed to cool the print and not the hotend).

iceman1306

Well the heater was not marked as decoupled, the temperature did not drop more than 20 degrees below set point. It should have been 210° and dropped to 195 when the pla fan came on. It only took 5, max. 10 minutes to switch into dry mode. No messages, nothing. And this is a short print, just 2 cable clips for 2020 aluminum extrusion. Print time was calculated at about 13 minutes. When pla fan is enabled, it switches on at the second layer, and 5-6 minutes after dry run is enabled.

iceman1306

I will try to increase the second variable later on, thank you repetier. I did not read your post until now, my last answer was written without reloading the page.

iceman1306

Well unfortunately i have been glad too early. The latest run switched to dry mode without pla fan. Octoprint shows that the temperature was within the range 209-211 during the whole print, 210 was the set point.

iceman1306

I tried to increase DECOUPLING_TEST_MAX_HOLD_VARIANCE to 40. That did not make any difference. Extruder stops after a few minutes, no matter if pla fan is running or not. Heater temperature drops when pla fan is on, but it does drop not more than 15 degrees. When it`s not connected, heater temperature stays between 208 and 212 degrees, but extruder still stops working in most tries.

javitopia

Does it happens at the same line every print? That's one of the things I want to test as soon I resume painting

Repetier

Are you both using Octoprint so send data?

Could you enable logging and also enable echo as debug option (hope it echos only the commands not any extra debug options). If it is not extruder related dry run switch it might by a command switching it on - maybe one with communication error that gets bisread. So with echo on you would see what octoprint sends and what firmware things it received. If we find then a M111 anywhere we know at least where and why it happens. Then we can see further.

In commands.cpp you have

    case 111: // M111 enable/disable run time debug flags

        if(com->hasS()) Printer::debugLevel = com->S;

which could be changed into

    case 111: // M111 enable/disable run time debug flags

        if(com->hasS()) Printer::debugLevel = com->S & 7;

That would disallow setting dry run from command line. I would be glad to find first the source of the problem.

iceman1306

I am using octoprint most times, but I think the problem occured once while printing from SD-Card. 

I will try to enable logging, but not before tomorrow. And I will check printing from SD again.

javitopia

I'm using repetier host, and in one of the tests it also failed painting from SD card.

iceman1306

Could not sleep this morning. I installed repetierhost, configured everything and started a test print with the same part that had the problem with octoprint. The extruder stopped again, dry mode was enabled suddenly, but unfortunately i had not enabled logging, found out it has to be enabled in settings when searching for the log file. After enabling, started another test.......worked this time, no error! Had to go to work now, will try again this evening.

iceman1306

Really strange... I have not been able to log the problem yet, the latest prints all finished flawless. Have been printing with repetierhost and from sd card, i am switching to octoprint now, will see if it happens again or not.

iceman1306

Well, it happened again when printing with octoprint. Unfortunately I had updated octoprint just before this print, and the setting for serial logging in octoprint was disabled by the update.....dooooh! Next try with logging enabled....I guess it will work flawless this time.

Repetier

Please also remember to enable echo in debug flags so you see what firmware thinks it got hoping that command it mistakes it with does not disable echo!

iceman1306

Today I tried to print a bigger file, and extruder did stop after only a few minutes. I was using octoprint this time, but unfortunately no log file. I tried to use Repetierhost from an old laptop I use for uploading the firmware. The gcode file is 55 MB and repetierhost keeps crashing after starting, even before the heatbed is hot. Guess the laptop is too slow and/or has insufficient memory.

iceman1306

I am printing smaller parts with repetierhost now, so far no error...all parts were printed completely.

iceman1306

Time to go crazy... Several attempts with repetierhost worked, so I switched back to octoprint with echo and logging enabled. This time the extruder stopped again, display shows dry mode is enabled. But nothing special in the log, it rolls over at 12.000 lines! That is no more than 7 minutes of printing.....doooh! The error must have been before that...

iceman1306

In commands.cpp you have

    case 111: // M111 enable/disable run time debug flags

        if(com->hasS()) Printer::debugLevel = com->S;

which could be changed into

    case 111: // M111 enable/disable run time debug flags

        if(com->hasS()) Printer::debugLevel = com->S & 7;

That would disallow setting dry run from command line. I would be glad to find first the source of the problem.

I made this change to the firmware yesterday.

After that I printed an extruder, over 4 hours of successfull printing (with repetierhost). The log does not contain an m111, and no communication errors.

Afterwards I started a long print from sd-card which should run over night. About an hour later I stopped that print because it had switched to dry mode after the first 5-6 layers....no log here.

Repetier

Starts sounding like some action overwrites the debug mode byte. So we should start going into that direction and I also would like to be able to reproduce the error myself. So here a few questions

1. What board/printer type?

2. How much free ram reported at startup? Should be at least around 1000 to be safe that stack does not overwrite stored data from ram.

3. Which OS/Arduino IDE do you use. They differ in compiler so output can also differ.

iceman1306

Printer is derived from sparkcube, I posted some pictures here: Printer

Electronics is a Ramps1.4 with 5 DRV8825 stepper drivers, full graphic display.

My Laptop uses Ubuntu 14.04, Arduino IDE 1.0.6.

Where can I see how much free ram is available at startup?