Connect to Printer and Y-Axis Might Just Go Nuts

Hi Everybody,

I've been trying to finish my first printer, and have gotten as far as getting all my axis and endstops acting as they should without too much hair pulling. Everything is working great except:

When I connect to the printer (I'm using Pronterface) my Y-axis stepper is somewhat unpredictable. Sometimes it behaves as it should (waits for commands). Sometimes it whines for a few seconds, and when that's over behaves nicely. Sometimes it's very naughty, and it takes the platform for a wild ride for a few seconds, and then behaves as it should. Until, that is, I disconnect, and then it goes for another ride. The video below shows:
1. Connecting using Pronterface - Y-axis zooms
2. Homing routine - all is well
3. Moving all axis away from endstops - all is well
4. Disconnecting - Y-axis zooms
[www.youtube.com]

Here's a less exciting video of connecting and disconnecting, each act prompting some stepper noise. Had I given a command while the printer was connected, the stepper would've worked flawlessly.
[www.youtube.com]

I've searched the forum and haven't found another case of this. Anybody have any ideas?

RAMPS 1.3
Marlin
Pronterface

Thanks.

It looks like it happens when the micro is reset and the bootstrap is running before it transfers control to the firmware. The step and enable pins will be defined as inputs at that stage and it appears the Y axis is enabled and the step pin has noise on it.

I had a similar problem with the extruder motor on a Sangunololu, but only when loading firmware. I fixed it by putting a pullup resistor on the enable line to the Pololus.

---

[www.hydraraptor.blogspot.com]

Thank you for the reply, nophead. I forgot to mention that when communicating with me regarding matters of electrical engineering, you should picture yourself talking to a loyal dog that's wanting to please its master, but its head is tilted in confusion.

The mega is reset when pronterface connects and disconnects? (I see the console says "echo: External Reset" after connecting, is that it?)

Since this is only happening on the Y, should I be searching for the source of noise that's unique to that axis' driver before I start adding a resistor? I'm not sure how I would search, and beyond repairing a cold solder joint, not sure how I would fix whatever I found (switch metaphor to "babe lost in the woods"). Does the fact that the bad behavior doesn't always happen, and when it does it's variable, suggest the noise can be eliminated? (I'd be satisfied with minimized, I can live with the stepper whine).

I have no idea what value resistor would be appropriate, if it comes to that. I assume I can just remove the header pin that goes to "enable" and replace it in a hacky manner with the resistor. Is that the location that makes the most sense?

Thanks again. I hope I won't tax anyone's goodwill too much.

kongorilla Wrote:
-------------------------------------------------------
> The mega is reset when pronterface connects and
> disconnects? (I see the console says "echo:
> External Reset" after connecting, is that it?)

Yes the USB connecting or disconnecting resets the Mega. It goes into the bootstrap for a couple of seconds waiting for a download. When that times out it runs the firmware. When the firmware runs it defines that motor pins to be outputs with defined levels and that appears to be when the Y axis behaves.

Looking at the schematic there should already be a 10K pullup on Y-EN, R19. Perhaps that is missing, or the wrong value, or that pin is shorted to ground. If you disable the motors in pronterface does the Y motor get disabled?

---

[www.hydraraptor.blogspot.com]

Yes, if I disable the motors in pronterface the Y motor is released.

My RAMPS is 1.3, which has 100K resisters on the EN of each driver. Looking at them, they are all decorated in 100K stripes, but when I put the probes to them they're each metering at 19.5K. The other 100K resisters on the board (the ones not connected to ENs on drivers) meter appropriately, around 97-98K.

You can't really read resistance of a resistor while it's soldered to the board.
If they are marked correctly for now I'd assume they are functional and the correct values, the fact they all read the same is probably a good indication they're functional.

According to the 1.3 schematic, there are no pullups on the enable lines. Ramps 1.4 added 10K pullups.

You're right, Andrew. I wasn't looking at the schematics, I was mistakenly going by the traces I saw on top. I now see the resistors are going to MS2 on the drivers.

Now do you see why I'm hesitant to start soldering in modifications to the board?

"Back up, everybody! He's got a soldering iron!"

Well that accounts for why the motors are enabled during the bootstrap. Adding 10K pullups will fix that.

What actually causes Y to step I don't know. In the case of my Sanguinololu the E step pin was next to the pin the bootstrap thought was an LED. When it was loading firmware it flashed the LED and there was enough capacitive coupling between the tracks to trigger the step input.

As yours runs even when it is not loading software, just in the bootstrap it must be a different source of noise. Y seems to work properly when the pins are configured as outputs so it should work fine with the enable pullups.

---

[www.hydraraptor.blogspot.com]

I removed the Y driver's header pin at EN, and soldered a 10K resistor between EN and the pin that goes to the mega that formerly had continuity with EN.



The runaway Y-axis problem persists despite this. Did I do it wrong?

By the way, I confirmed that the problem occurs when I hit the reset button on the RAMPS board, no host involved.

Yes, you did it wrong. A pullup (pulldown) resistor weakly ties the line to vcc (gnd) so that, if the line isn't being driven one way or the other, it naturally goes high (low) rather than floating in an undefined and potentially dangerous state.

In this case, the resistor should go from EN to +5V, and you will also need to restore the EN connection so that the processor can drive the line down when the steppers should be enabled. This results in failsafe behaviour, the enable line is always high unless the processor drives it low, the steppers are only active if the firmware explicitly enables them.

Thanks, Andrew. It might not surprise you, considering the evidence above, that I'm not 100% sure of where to connect to +5V. I'm assuming it should be the pin on the shield that goes right to the 5V on mega (third from the left, on the bottom), but my confidence is at an all time low about now. And there's also an unused pad labeled '5V' next to the 5A terminal block.

^^^^^Babe^^in^^Woods^^^^^

I'd put the resistor between the EN pin and the Vdd pin on the polulu. You could connect it to any other source of 5V on the board, but linking the Pololu to the RAMPS that way would cause problems if you ever needed to replace the board.

Thanks, guys. The 10K resistor between VDD and EN on the driver did the trick. I salute you!

Moving on to the next challenge....*the crowd murmurs*