Debuging RAMPS Stepper Problems

This is a bit of a departure from my usual Ruby, Ops, and Security posts. However, recently I acquired a mostly completed RepRep 3D printer and wanted to document an issue I had to debug. One of the reasons I blog is to share the answers to problems for which the Google couldn’t find me an easy answer. And this problem was “Why does the y-axis stepper motor only move in one direction?”.

RepRap is a project to develop self-replicating 3D printer, a printer that can print most of it’s parts. It’s a long way from that goal, but it has resulted in a family of affordable, open source 3D printers you can build yourself.

At the RepRap’s heart is the RAMPS board, an Arduino shield that drives the stepper motors, heaters, and other electronics on the RepRap.

Friends had started to build a Prusa Mendel, ran into a problem with one of the stepper motors, and put it aside. Life then got busy as it will and they never got back to it. After watching it gather dust for too long, they passed it on to me.

The problem was that the extruder would only move in one direction along the Y-axis (X and Z were fine). A bit of Googling comes up with plenty similar sounding problems and the answer always is that the end stop is incorrectly reporting that it’s being hit. That makes sense, if the motor thinks it’s against an endstop, it will only move away from it.

Turns out that wasn’t problem and finding the solution was hidden by the wrong adverb. In this case, the stepper motor doesn’t only move in one direction it always moves in one direction. It moves forward correctly, but told to move backwards it also moves forward. This is not the endstop problem where it moves when told to go one way, but ignores commands to move in the other.

Once I’d convinced myself that the endstops where working correctly and that the problem was something else, I finally found the combination of search terms to get to this post:

https://groups.google.com/forum/#!topic/mendelmax/xjGJu8edHro

And this bit of wisdom:

Just in case you are curious, and for the benefit of future mendelmaxers, the “dir” pin for the x driver on my ramps 1.4 is shorted to ground. Hence the unidirectional motor.

The RAMPS board has It has five daughter boards for the stepper motor drivers. The “dir” pin is a input to the driver that set the direction the motor will turn. Definitely a candidate for our problem.

For completeness sake, I first swapped the X and Y stepper motor connections. The problem stayed with the Y axis, not a wiring issue.

Next, I swapped the X and Y driver daughter boards. Again, the problem didn’t move, ruling out an issue on the daughter board.

Finally, I broke out the multimeter. The Y “dir” pin was never getting voltage. However, it was connected all the way through to the pin on the Arduino Mega and didn’t appear to be shorted.

That suggested a problem with the Arduino itself, which seemed unlikely, they tend to be rock solid. Unlikely, that is until I detached it from the printer and looked at the back of the pin in question.

That’s not good. So, I wired up your standard LED/resistor setup and loaded the standard blink code:

int led = A7; // Y DIR PIN
void setup() {
  pinMode(led,OUTPUT);
}
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Nothing happened.

To verify my wiring and code, I also tested the adjacent pins by setting:

int led = A6;

and

int led = A8;

Both worked fine. Definitely the solder joint.

Honestly, I figured this would end with my ordering a replacement Arduino, as most of the pad was gone and making the connection was beyond my I-wouldn’t-call-them-modest soldering skills. However, I got lucky and I’m back in business!

Now on to “Why don’t the hot end and bed heat up?”.