Ramps 1.4 + sprinter + pronterface + Mac OSX

Hi,

Finally got my Prusa up and running! I've used the test file for Ramps and everything is moving and flashing as it should do - great!

So I moved on and uploaded sprinter, using Ultimachine's configured file and pronterface (I struggled with repsnapper, but bash was having none of it!).

Pronterface has no problem manually controlling and measuring temperature of either the hot bed or hot end, but it just won't budge any of the stepper motors except for the extruder, which again, it does fine. Anyone have any ideas or experienced this before?

Much appreciated!

I finally got Repsnapper to compile under Ubuntu in a virtual machine on my Mac. It won't compile native on a Mac, and the Windows version is broken as it can't connect to a printer. Great slicer and gcode visualiser, but that's about it. Haven't run any gcode from it. Better off for the moment sticking to Slic3r for slicing, and pronterface for printing.

Sprinter is great, but I had the same problem with it on my RAMPS1.3. Do the motors come on when you send a move command? You'll know if they do, as you won't be able to turn them by hand. It could also be related to the endstops, and/or the axis direction. Try inverting them in the firmware. When you turn the board on, wherever the nozzle is, it assumes it is at 0,0,0. It can't move negatively, as there is (I think) a software endstop that prevents a move below 0. But it can't move positively, because the endstop is triggered!

Another option is to move the nozzle to the middle of the printbed, and type:
G92 X100 Y100
This will set the firmware to think it is in the middle. Try moving + and - from there.

Thanks for your suggestion - I'll give it a shot tomorrow and let you know.

I do think the motors turn on, as there's usually a very high pitched tone coming from then when trying to manually control the printer.

Hmmm, OK, so I've tried inverting the endstops in the firmware and no luck.

The X-axis does move, but only 1mm. 10mm or 100mm send the thing whirring but without much movement. The Y-axis doesn't move at all and is easy to move - so I assume it's not even turning on the motor. I know this motor works though, because I checked the test-file and everything moves fine.

Z-axis is like the X-axis. Moves, but struggles and screams at you.

So... pretty stumped!

Sounds like the motors are stalling. Have you tried turning up the motor current, by turning the trimpot on each Pololu a little bit at a time? Start with the trimpot turned completely anti-clockwise, then increase 1/8th of a turn clockwise. You can do this with the electronics switched on. If you have an axis that still isn't working at all, swap the motor onto a header that you know is working. CAUTION: Make sure you turn off the electronics before you unplug/plug motors into the headers, you can destroy the Pololus if you leave them switched on.

Ah great! That's solved the X and Z axis - they run smoothly now. But still nothing on the Y-axis.

Gave it a bit more current and it just jars itself when activated. I've tried it unloaded without a timing belt connected and still nothing. Re-checked the test-file and the Y-axis moves as expected. Except, now that i've switched the driver over to the X-axis, the X-axis, won't move when controlled in Pronterface.

So to summarise, a driver works as you would expect in the test-file, but not when controlled via pronterface...?!

Most likely an endstop problem. Are you using microswitch or opto endstops? If you are using microswitch endstops, they can pick up noise and be triggering by mistake. Try unplugging the Y axis endstop, (see if it moves properly) then invert the endstop in firmware by changing this line in the firmware:

const bool Y_ENDSTOP_INVERT = false;
to
const bool Y_ENDSTOP_INVERT = true;

(update firmware and test to see the result), and finally try inverting the axis so it runs the other direction:

const bool INVERT_Y_DIR = false;
to
const bool INVERT_Y_DIR = true;

(update firmware and test to see the result).