Steppers Don't Always Move

on4now4

Hello all,

I have been absolutely stumped by this problem I am having. Please move this if I am posting in the wrong place.

I have a Prusa i3 knockoff with a Ramps 1.4 and TMC 2100 drivers, for a long time I have been using Marlin firmware with Repetier Host to run everything. Recently I started having a problem where after after printing a couple of layers the Y-axis will miss a few steps and I will have to scrap the print.

My initial thought was that something is causing the motor to over torque so at first I just lowered the speed to 50% and still I experience the same problem. The more I looked at it I started experiencing the problem even under manual control where the motor will just not move no matter what I do. But I was able to determine that the motor seems to be just not being told to move. Its not an over torque issue. The motor just is not even trying. Even if I disconnect the belt it simply will not spin.

I have tried increasing and decreasing the current from the drivers and swapping drivers. I have checked all connections and even verified that I am not drawing more power than the power supply can handle 350W rated (Only drawing 200W).

The problem is that this behavior is seen erratically and does not seem to be predictable so it is not easy to track down.

So then things got really confusing for me... Last night I took the G-Code that is generated in Repetier host, the same exact G-Code that I was running when I had all these problems and ran it through Pronterface... Everything worked perfect!

So then I played around with it some more and I have been unable to repeat the problem either via manual control in Pronterface or through G-Code. My conclusion is that something in Repetier Host is causing the problem, but I am absolutely baffled what it could be.

Any help would be greatly appreciated, I do greatly prefer to use Repetier Host, but at the moment it is unusable.

Repetier

I do not think it is a host problem. Hosts only send the gcode. You can enable echo in debug options and you will see firmware received the commands and from there on it is a firmware/hardware issue.

I don't know marlin good enough to say when it prevents moves, but I think when an endstop is triggered it might do. That often happens through crosstalk. With TMC2100 it could of course be the driver triggering it as well. Overheating, wrong current are other reasons. And simplest reason is just a defect on the driver chip. Have you tried switching Extruder with y driver to check if it a driver issue.

on4now4

Yeah, I have tried swapping driver chips as well as reverting back to the old non TMC 2100 chips (I don't remember the model of those but just the basic super common chips). Neither of these options work reliably. I have also tried swapping stepper motors.

I would tend to agree that I don't understand how the host could cause the issue I am seeing, but why does everything work fine when I run the same G-Code through pronterface but fail consistently when run through Repitier Host?

I will add that when running through pronterface it appears to not be utilizing the EEPROM settings and rather reverting to the settings hard coded into the firmware. Could my problem be entirely revolving around the EEPROM settings?

While saying that, I should add that I have not changed the EEPROM settings at all since the printer was working. It just stopped working one day. This is why I initially ruled it out.

Repetier

Why do you think pronterface does not use eeprom settings in firmware while repetier host does? There is no command to say do not use eeprom. If you have compiled eeprom support these values are used, otherwise not. Host just has a window to show the settings and allowing you to change them or reset to defaults. But that does not change how firmware works.

As always with such strange errors you should have a look in the log - that is what it's for. Host sends a command and firmware says ok, thank you I do it. So as long as host send the right commands and firmware receives it, it is up to firmware. You can even enable echo in debug so firmware repeats what it receives. That you can be sure where the problem lies. Problem is always with errors happening infrequent and at random places. But even there you see it.

And last thing - slicers always have absolute positions so even if a command was omitted, the position would be still correct. So if you get a skewed print from loosing steps it is the firmware loosing them. Only thing host could do is send speeds too high for the printer, but then you have set the limits in firmware badly and need to reduce maximum speeds.

Very last thing - slic3r can change acceleration I think, if you configure it. So it can also use accelerations too high for printer also causing loosing steps in a print.

on4now4

I have finally gotten around to looking at this again.

I finally got my scope hooked up and the Ramps board is not sending any signal at all to tell the motor to move. When the motor does decide to move the signal is clearly visible.

When the motor does not move, the log is showing an OK for ack.

Repetier

If you enable command sin log as well you even see what it did ack and with debug echo firmware would repeat the command received. But it looks from your description so far that the problem happens on printer side. Firmware could think a move is illegal and just do nothing or driver has problems like overheating. Would at least explain why it sometimes works and sometimes not.