›

Trouble moving two of the three motors

kentmcnkentmcn
in Repetier-Firmware
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
 

Comments

  • docpaycedocpayce
    Did you check your endstops via "M119"? (http://reprap.org/wiki/G-code#M119:_Get_Endstop_Status)

    Check whether they report back correctly to Repetier Host (both activated and non activated). Perhaps the configuration for them is not correct (pullup, active on low/high) and they dont allow the motors to move, as they are always active.
  • kentmcnkentmcn
    Hi Don,

    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(?)
  • RepetierRepetier
    First use the same settings as for the working y axis. Assuming you have identical drivers.

    MOTHERBOARD=33 is for Ramps 1.3 and 1.4 which have identical pins.

    It's no host problem as it only sends commands.

    It might be a bad ramps board/dead avr pins. If you have a multimeter you can unplug stepper drivers and measure voltage at enable pin. As I understand even when moved the motors do not get any current which means enable pin does not get triggered. So measure the enable pin after a move and after you hit disable motors. The value should differ. Depending on X_ENABLE_ON one of them is 5V and 0V.
  • kentmcnkentmcn
    After removing the stepper drivers, the !ENABLE voltages are: X=4.89; Y=0.0009; Z=0.001. After attempting moves (with the stepper drivers missing) they are: X=4.89; Y=0.0009; Z=4.88.

    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.
  • RepetierRepetier
    Ok, first check with M119 all endstops are low. Just to prevent the chance endstops are preventing moves. Then since you use DRV8825 set stepper high delay 1 and double step delay 1. These drivers are slow and need 1,7us long signals.So that is just to make sure timings arer really correct. Once it works you can try with 0 and see if it still works - would be faster then.

    Motors are only enabled when you move it, so you need to move all axis to change voltages. Your results are a bit hard to interpret. enable should have changed and Y whcih works did not change, that makes no sense so I'm wondering if you really enabled/disabled motors. The RAMPS pins are correct as it is the most commonly used board. But maybe the endstop check already helped.
  • kentmcnkentmcn
    M119 shows all endstops are low.

    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).
     

  • RepetierRepetier
    Ok, i think z os ok. It behaves as expected. It's quite common for z to stall which are the vibrations. If z uses lead screws make sure acceleration is 50 and z speed 2mm/s. Once on also check how much force you need to turn motor - maybe current is even a bit low. Especially if it is shared with 2 motors. Friction is often quite high and steps per mm also high and high accelerations cause a stall and high stepp frequency then just jitters the motor which never catches up.

    Swapping cables only verifies motors are ok. You need also once swap the drivers to see if the drivers are also ok.

    Also check in eeprom if steps per mm is a correct value. 0 or NaN might prevent enabling motor.

    Sleep/reset never get set, dir depends on last move direction. step is only high for a short time so it is hard to measure.

    In case it is just a defect on board/avr move x to E1 socket and use that for driving X axis and see if it works better. In config tool it is just selecting the other socket for x axis.

    Hope one of these helps finding the reason.

  • kentmcnkentmcn
    Problem solved:

    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.
Sign In or Register to comment.