Extruder motor stop working during print

MikeB

I have a problem with the lates version of repetier firmware, ramps v1.4 and Arduino Mega, with a cartesian printer with 2 extruder. After a random time of printing, the extruder stop working. I tried printing only with E0 or E1, but the motor stops after 40 to 80 minutes. I tried to change the driver, change the vref, put a fan overbthe driver, over the motors, even if both motors and drivers never went over 35C. So I passed to Marlin. Same STL, same HW, and the problem disappear. Do you have any idea?

Repetier

New firmware has a feature to test decoupling of heater and sensor. With bad settings it can trigger and disable extruding. You should see a message in the log for what reason it triggered decoupling. Latest version can also disable decoupling test by setting decoupling time to 0.

MikeB

I'll wait for a new controller, SainSmart 2 in 1 to make a further test. Also I notice that with the actual RAMPS + Arduino 2560, with Marlin I don't have any problem to use it at 250000 bps, with Repetier I have to use it at 115200 bps. About the decoupling I didn't see any message on the log. At the next test I'll check. But the problem is that to make a test I need to run a long print and if it stops I loose time and filament.....

Repetier

For decoupling testing you need no print. Especially if it happens so seldom it is already set quite good. So you must have had some code bringing the extruder to set limits. E.g. switch between 2 temperatures with extruder setup is always critical or if you print for a while faster. During print you have a banding area where temperatures have to stay and once they go outside that band the decouple error gets triggered.

MikeB

I discovered that the problem is Repetier Host.I tested with marlin firmware and also with Repetier firmware. During the Printing process I start having these errors :<font color="#6a6a6a">Error</font>:<font color="#6a6a6a">checksum</font> mismatch, Last Line ....If I print the same GCODE form the SD card I don't have the problem.I have Windows 7, 64bit.Reading in some other forum, with the new version of repetier, there are a lot of people that start having this problem. Someone solved using Pronterface (and this confirm that the problem is on Repetier host )Did you changed something from the previous version on the communication protocol?

Repetier

We are analysing this in a different thread http://forum.repetier.com/discussion/808/extruder-stops-extruding#latest where we already found out that the firmware seem to change the debug flags to dry run also there is decoupling error.

We are still searching what changed. One idea was that the new u8glib_ex could be the reason as both users having the problem and both have a graphic display and that was a recent change before the problem started. What display do you have if any?

Host only sends commands to firmware. Checksum error is just a communication error which happens from time to time depending on electric noise, baud rate .... No problem as long as there are only a few. When firmware tells this it did not use the wrong code, so no reason that it disables extruders.

MikeB

Yes . I have the graphic display.Just for your information, I checked with Baudrate at 115200 and at 250000. In both cases I had random errors.The strange thing is that I have the error with both repetier firmware (most frequent) and with Marin firmware (less frequent).

Repetier

So one more point for display theory. You can use u8glib_e.hx from april to see if it helps. The new additions were for other displays which are now supported.

Marlin is strange as I think it is a firmware issue and marlin works completely different and has no dry run mode as far as I know.

MikeB

The last u8glib library I can find is the V1.17 dated December 2014. Do you have another library?

Repetier

You do not need the original library. You need only the u8glib_ex.h from an older firmware e.g. master branch from github. We do not use the u8glib as a installed library.