Trouble moving two of the three motors
I'm having trouble with enabling my X and Z axis motors. The Y motor works fine.
Swapping out the X motor cables with those on Y moves the X motor. Swapping
out Z with Y moves the Z motor. In other words, all three motors and their
wiring are OK.
I'm using RepetierHost V0.85c on Ubuntu 12.04, Arduino 1.0, Repetier-
Firmware 0.92.8 and an Arduino Mega2560 with RAMPS1.4 for the hardware.
The !ENABLE signal on the X and Z Pololus remains high (properly low on Y).
Changing the ENABLE defines to "#define X_ENABLE_ON 1" and "#define Z_ENABLE_ON
1" do not change the behavior.
Swapping X and Y Pololus doesn't change the behavior, either. The Y continues
to work and the X, does not.
I've changed ALWAYS_CHECK_ENDSTOPS to 0 to try to eliminate the endstops as a
factor.
Being a little confused as whether to change the EEPROM_MODE to 0, or to
increment it with each new upload, I've tried both.
In a somewhat desperate move, I tried setting both DISABLE_X and DISABLE_Z to
1. No help there either.
I just swapped the host machines. Now I'm using RepetierHost V1.0.5 on Ubuntu
14.04, Arduino 1:1.0.5dfsg2-2. Same results.
I have another board set (Mega 2560/RAMPS1.4) set up the same way, so to
remove the hardware from suspicion, I tested that set. The behavior is the
same, leading me to believe that there's something I've set wrong in
Configuration.h on both board sets, but now I'm at a loss as to what it might be.
I'd very much appreciate some help.
Thank you, Kent
Swapping out the X motor cables with those on Y moves the X motor. Swapping
out Z with Y moves the Z motor. In other words, all three motors and their
wiring are OK.
I'm using RepetierHost V0.85c on Ubuntu 12.04, Arduino 1.0, Repetier-
Firmware 0.92.8 and an Arduino Mega2560 with RAMPS1.4 for the hardware.
The !ENABLE signal on the X and Z Pololus remains high (properly low on Y).
Changing the ENABLE defines to "#define X_ENABLE_ON 1" and "#define Z_ENABLE_ON
1" do not change the behavior.
Swapping X and Y Pololus doesn't change the behavior, either. The Y continues
to work and the X, does not.
I've changed ALWAYS_CHECK_ENDSTOPS to 0 to try to eliminate the endstops as a
factor.
Being a little confused as whether to change the EEPROM_MODE to 0, or to
increment it with each new upload, I've tried both.
In a somewhat desperate move, I tried setting both DISABLE_X and DISABLE_Z to
1. No help there either.
I just swapped the host machines. Now I'm using RepetierHost V1.0.5 on Ubuntu
14.04, Arduino 1:1.0.5dfsg2-2. Same results.
I have another board set (Mega 2560/RAMPS1.4) set up the same way, so to
remove the hardware from suspicion, I tested that set. The behavior is the
same, leading me to believe that there's something I've set wrong in
Configuration.h on both board sets, but now I'm at a loss as to what it might be.
I'd very much appreciate some help.
Thank you, Kent
Comments
Thanks for the response.
M119 reports Xmin:L Xmax:L Ymin:L Ymax:L Zmin:L Zmax:L
All the end_stops are set to inverting=true, as are the end_stops themselves and the pullups(=true).
I set them all to INVERTING=false and m119 reports they're all now set H. Same result though. Next, I set all MIN/MAX_HARDWARE_ENDSTOP_X/Y/Z to false, thinking that this removes the end_stops from having any effect.
M119 now reports N25 M119 *61
No change. X and Z motors still don't respond. Y still moves OK.
I notice in pins.h that MOTHERBOARD=33 defines the board as RAMPS1_3, not RAMPS1_4. Presumably, though the pinning is the same(?)
I have a (nearly) identical setup handy, which I've uploaded the same firmware to. It shows the same behavior as the other. Y moves fine, X and Z not at all. Also, with the stepper drivers in the circuit, just after a connection (before movements attempted) the !ENABLE voltages are X=4.53; Y=4.98; and Z=4.98. After movements were attempted they are X=4.53; Y=0.01; Z=0.01
I put an oscilloscope on the Z motor leads and it shows activity. The Z lead-screw is stiff, as it is holding against torque, though not moving. Both setups show the same behavior. (Since the Z motors are smaller than the X and Y, I'll redo Vref on the DRV8825s).
I spent some time cunderstanding the end-stop settings and think I've got them properly set now. Non-inverting (NC), pull-ups enabled, and set to 'false' at those positions where I have no end_stops.
That both setups show the same results with the same firmware, it would seem that either the configuration is wrong or the boards (same manufacturer, probably same lot as they were bought together) are messed up in the same way.
STEPPER_HIGH_DELAY and DOUBLE_STEP_DELAY are both changed to '1' as you suggested.
Same situation: Y moves OK. X doesn't move. The X leadscrew is limp (turns freely) after a move command. Z doesn't move. The Z leadscrew, though, reacts by going stiff on a move command.
I re-verified that swapping X with Y cables allows X to move, while Y now doesn't move.
Here are the voltages re-measured:
With USB connected at both ends and 12V power applied, and repetierHost
NOT CONNECTED CONNECTED AFTER A MOVE (attempted)
=============== =========== =====================
X !ENABLE = 4.54V 4.54 4.54
Y !ENABLE = 4.99 4.99 10.3mV
Z !ENABLE = 4.99 4.99 10.9mV
X DIR = 1.2mV 1.2mV 0.8mV
Y DIR = 1.2mV 1.2mV 0.9mV
Z DIR = 0.5mV 0.5mV 4.4mV
X STEP = 1.2mV 1.2mV 0.8mV
Y STEP = 1.2mV 1.2mV 0.9mV
Z STEP = 0.4mV 0.8mV 4.1mV
X !SLEEP = 4.5V 4.5 4.5
Y !SLEEP = 4.49 4.49 4.49
Z !SLEEP = 4.5 4.5 4.49
X !RESET = 4.5V 4.5 4.5
Y !RESET = 4.5 4.49 4.49
Z !RESET = 4.5 4.5 4.5
As before, Y moves, X doesn't and turns freely, Z doesn't move but goes stiff on the command to move (gripping the coupler, it vibrates some and feels like it's trying to move).
I noticed that there was a slight difference in the planes of the two boards (Mega 2650 and RAMPS), such that the pins connecting the boards were further apart at the top (Aux header) than at the bottom. Tightening the screw at the top and loosening (slightly) the screw at the bottom provided the connection needed.
Repetier and docpayne, thank you very much for your help. You are a credit to the open source community.