Stepping Inconsistencies [Sanguinololu] [Prusa]

I am having trouble getting my machine to step. I believe there are multiple issues happening, and am concerned that some of my components may be damaged.
I am using a Prusa Mendel with sanguinololu 1.3 electronics running marlin and using pololu stepper drivers. My motors are NEMA17s, rated at 2.5v/1.2a.
My x and y motors just buzz, and if they do step they randomly switch directions. My z motor steps fine.
Because the z axis works, I believe I have the vRef on my stepper drivers set correctly, though I am no electronics expert. My vRef calculation set at 70% of the limit, given vRef = 0.4*I ,came out to vRef = 0.4*(0.7*1.2a) = 0.336v . All of my pots are currently set to just below this value (+/-0.01).

Where this gets particularly strange is if i switch the y and z motors on the board. The z then behaves consistently; it just buzzes and jumps randomly. The y motor, however, makes HUGE steps very quickly. stepping by +1 will rather violently throw the printbed beyond even what a +10 step should, albeit in the right direction.

At this point, I have tried several things to diagnose. Many posts have mentioned incorrect vRef causing the buzzing. I have tried turning them down, to no effect. I did not try turning them up for fear of damaging something (even more?). Some posts pointed to motor wires being connected incorrectly, which seemed possible, but after trying about half the possible combinations with all giving the same result i returned them to the original configuration. Another post mentioned "adding a delay to the step pulse", but did not follow up on how to do this, what this is, or where to make this change in firmware. I am switching over from gen6d elctronics that failed for mysterious reasons, but all the motors were working fine with those electronics previously, so it seems like they should still work here (though i have not ruled out the idea that bad motors were the cause of that failure!)

So, given all that information I don't really know how to proceed. My concern is that I have an issue with both my x and y motors AND my sanguinololu, given the behavior when the motors were switched. For the board, it seems like vRef on the steppers might be a likely candidate (though i dont know why z works fine at that rating), and i have no clue about the y motor.

Anybody have any idea? Let me know if you need more info or to see any of my firmware/picures/etc.

There are at least two possibilities: your motors are wired up incorrectly (the two phases are not firing in the right sequence to move it forward), or you're trying to move the motors way too fast.

First, check your motor speed, considering how fast your y-axis moves. How are you moving the motors (pronterface)? What firmware are you using on the sanguinololu? Make sure you have the right microstepping mode selected for the axis_steps_per_mm in your firmware. Also try turning down the default acceleration, at least to 1500 mm/s^2.

If that doesn't work, it's wire shuffling time... If you can get the specsheet for your steppers, you can try to figure out how they're wired up and adjust them accordingly.

Hi James,
I am using pronterface to test, yes. Also I am on Marlin firmware.
I will try setting axis_steps_per_mm , though I don't immediately see this value anywhere. I do have DEFAULT_AXIS_STEPS_PER_UNIT which is set to {78.7402,78.7402,200.0*8/3,760*1.1} - this appears to be (quite?) wrong as the comment on this line is "// default steps per unit for Ultimaker"
I have updated this to
#define DEFAULT_AXIS_STEPS_PER_UNIT {32, 32, 2048, 461.64}
from the blog post [the3dprinter.blogspot.com], which actually runs through calibrating my exact setup, so Ill try this out once i get home.
I turned down DEFAULT_ACCELERATION to 1500 as you suggested as well - I also have DEFAULT_RETRACT_ACCELERATION 3000 and DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} , should these values also be updated? Is there a good way to determine what these *aught* to be, or is it more of a by-feel sort of calibration?
If it comes to moving the wires, is it possible that my motors are wired inconsistently? I got them all from the same source, and their labels match, so i wonder why the z and y motors would behave differently. It occurred to me that having something set incorrectly in the pins.h file could be the culprit, but I wouldn't know what to switch with what to correct this.
Thanks for your help, and I am posting the relevant pins.h section below, if anybody who knows the sanguinololu schematic better than i do could scan the y and x axis (or other) sections to see if anything is wonky i would appreciate it:

/****************************************************************************************
* Sanguinololu pin assignment
*
****************************************************************************************/
#if MOTHERBOARD == 64
#define STB
#endif
#if MOTHERBOARD == 63 || MOTHERBOARD == 66
#define MELZI
#endif
#if MOTHERBOARD == 65
#define AZTEEG_X1
#endif
#if MOTHERBOARD == 62 || MOTHERBOARD == 63 || MOTHERBOARD == 64 || MOTHERBOARD == 65 || MOTHERBOARD == 66
#undef MOTHERBOARD
#define MOTHERBOARD 6
#define SANGUINOLOLU_V_1_2
#endif
#if MOTHERBOARD == 6
#define KNOWN_BOARD 1
#ifndef __AVR_ATmega644P__
#ifndef __AVR_ATmega1284P__
#error Oops!  Make sure you have 'Sanguino' selected from the 'Tools -> Boards' menu.
#endif
#endif

#define X_STEP_PIN         15
#define X_DIR_PIN          21
#define X_STOP_PIN         18
#define Y_STEP_PIN         22
#define Y_DIR_PIN          23
#define Y_STOP_PIN         19

#define Z_STEP_PIN         3
#define Z_DIR_PIN          2
#define Z_STOP_PIN         20

#define E0_STEP_PIN         1
#define E0_DIR_PIN          0

#define LED_PIN            -1

#define FAN_PIN            -1
#if FAN_PIN == 12 || FAN_PIN ==13
#define FAN_SOFT_PWM
#endif

#ifdef MELZI
#define LED_PIN            27 /* On some broken versions of the Sanguino libraries the pin definitions are wrong, which then needs LED_PIN as pin 28. But you better upgrade your Sanguino libraries! See #368. */
#define FAN_PIN            4
#endif

#ifdef STB
#define FAN_PIN            4
	//  Uncomment this if you have the first generation (V1.10) of STBs board
#define LCD_PIN_BL         17 // LCD backlight LED
#endif

#ifdef AZTEEG_X1
#define FAN_PIN            4
#endif

#define PS_ON_PIN          -1
#define KILL_PIN           -1

#define HEATER_0_PIN       13 // (extruder)
#define HEATER_1_PIN       -1
#define HEATER_2_PIN       -1

#ifdef SANGUINOLOLU_V_1_2

#define HEATER_BED_PIN     12 // (bed)
#define X_ENABLE_PIN       14
#define Y_ENABLE_PIN       14
#define Z_ENABLE_PIN       26
#define E0_ENABLE_PIN       14

#else

#define HEATER_BED_PIN       14  // (bed)
#define X_ENABLE_PIN       -1
#define Y_ENABLE_PIN       -1
#define Z_ENABLE_PIN       -1
#define E0_ENABLE_PIN       -1

#endif

#define TEMP_0_PIN          7   // MUST USE ANALOG INPUT NUMBERING NOT DIGITAL OUTPUT NUMBERING!!!!!!!!! (pin 33 extruder)
#define TEMP_1_PIN         -1
#define TEMP_2_PIN         -1
#define TEMP_BED_PIN        6   // MUST USE ANALOG INPUT NUMBERING NOT DIGITAL OUTPUT NUMBERING!!!!!!!!! (pin 34 bed)
#define SDPOWER            -1
#define SDSS               31

/* On some broken versions of the Sanguino libraries the pin definitions are wrong, which then needs SDSS as pin 24. But you better upgrade your Sanguino libraries! See #368. */
//#define SDSS               24

 #ifdef ULTRA_LCD
   #ifdef NEWPANEL
     //we have no buzzer installed
     #define BEEPER -1
     //LCD Pins
     #ifdef DOGLCD
       // Pins for DOGM SPI LCD Support
       #define DOGLCD_A0  30
       #define DOGLCD_CS  29
       // GLCD features
       #define LCD_CONTRAST 1
       // Uncomment screen orientation
         // #define LCD_SCREEN_ROT_0
         // #define LCD_SCREEN_ROT_90
       #define LCD_SCREEN_ROT_180
         // #define LCD_SCREEN_ROT_270
       #else // standard Hitachi LCD controller
       #define LCD_PINS_RS        4
       #define LCD_PINS_ENABLE    17
       #define LCD_PINS_D4        30
       #define LCD_PINS_D5        29
       #define LCD_PINS_D6        28
       #define LCD_PINS_D7        27
     #endif
     //The encoder and click button
     #define BTN_EN1 11  
     #define BTN_EN2 10 
     #ifdef LCD_I2C_PANELOLU2
       #ifdef MELZI
         #define BTN_ENC 29 //the click switch
         #define SDSS 30 //to use the SD card reader on the Panelolu2 rather than the melzi board
       #else
         #define BTN_ENC 30 //the click switch
       #endif
     #else
       #define BTN_ENC 16  //the click switch
     #endif //Panelolu2
     //not connected to a pin
     #define SDCARDDETECT -1    
    
   #endif //Newpanel
 #endif //Ultipanel

 #ifdef MAKRPANEL
     #define BEEPER 29
     // Pins for DOGM SPI LCD Support
     #define DOGLCD_A0  30
     #define DOGLCD_CS  17
     #define LCD_PIN_BL	28	// backlight LED on PA3
     // GLCD features
     #define LCD_CONTRAST 1
     // Uncomment screen orientation
     #define LCD_SCREEN_ROT_0
       // #define LCD_SCREEN_ROT_90
       // #define LCD_SCREEN_ROT_180
       // #define LCD_SCREEN_ROT_270
     //The encoder and click button
     #define BTN_EN1 11
     #define BTN_EN2 10
     #define BTN_ENC 16  //the click switch
     //not connected to a pin
     #define SDCARDDETECT -1    
 #endif //Makrpanel

#endif

Hmm, your settings sound pretty correct. The one thing you'll need to check is the microstepping. I have GT2 belts on my X and Y axes with 20 tooth pulleys. This is a pretty standard setup -- with 16x microstepping, I get {80, 80} for the axis_steps_per_unit in the X and Y directions. This value is computed this way: 200 steps / rev * 16x multistepping = 3200 steps per rev / (2 mm belt pitch * 20 teeth) = 80 steps per mm. Make sure all three microstepping jumpers are shorted on your sanguinololu. For the default acceleration settings, 1500 is a good starting point. 3000 makes the machine much jerkier, but things will print faster. That's for experimenting after it's working at 1500.

As for swapping wires, I severely doubt that they would be inconsistent. If you have one working, stick to that ordering. Start slowing down everything until you get reasonable movement.

Ok update - Looks like this was a combination of issues. Setting the jumpers correctly and adjusting the steps worked like a charm - I can now step any individual motor properly. Thanks so much James!
It does appear that I have a dead stepper - my x was not responding, but if i switch it to z, x behaves and z does not work. Im going to try resoldering the pins, and if that doesn't work (not super hopeful) ill replace it.

Other than that, when i switch the steppers the X does not return home properly - instead it moves a little bit in the wrong direction, even though I am able to step it +/- appropriately. Not sure what that means, because the stepper driver works correctly when places on the z-axis. Any idea why this might be?

Glad you got the steppers working! Also, check to make sure if it's the pololu that's bad, not the stepper -- the pololus are FAR more fragile than the steppers. The unidirectional movement sounds like your endstops are inverting, which is wrong for mechanical endstops. Make sure that all the ENDSTOPS_INVERTING variables in Configuration.h are set to false, assuming you have mechanical switches for endstops.