Motors don't move RAMPs 1.4 + Arduino Mega 2560 + Sprinter Kliment + Pronterface

misan Wrote:
-------------------------------------------------------
> Motors should move without reaching 5A current
> limit. Only a single 2 wires from your power
> supply should work.
>
> the repetitive sound on your x and y axis seems to
> be caused by these drivers not providing enough
> current (or too much). Yes, both cases may create
> a similar condition though it sounds weird. Unless
> cabling is wrong (which I assume it is not as your
> z-axis is working) I think you need to adjust the
> potentiometers on x and y so motors move properly.

thx i done it, but - i need to pin X and Y by makerfarm instruction and Z - going to reprap shceme what link i post before. =\
now i have only 1 trouble - i not understan how calibrate axis in marylin but i think i can do it

thx again!

I am trying to get some good advice on programming the Arduino Mega to use the Ramps Board... where exacly do I go to get the Software for my Arduino. so I can run my Ramps 1.4???

arduino.cc look for download and select version 22 or 23 better than 1.0

hello again
my endstops not working
Z-axis pull endstop (i have a mechanical one) and still going down

maybe i going somethere wrong with a marlin? could someone give me a working code lines?

p.s. sorry for my english

Does your z-axis goes down when you request the axis to move downwards? If not, you need to invert the z-axis direction in the firmware.

misan Wrote:
-------------------------------------------------------
> Does your z-axis goes down when you request the
> axis to move downwards? If not, you need to invert
> the z-axis direction in the firmware.


z-axis go down when i`m request, yes. but she(z-axis) don`t see a endstop and move down with pulled endstop O_O

That is possible if firmware is configured to just sense end-stop when homing (but ignore it there rest of the time).

What happens if you request a home operation on z-axis if when you do it the z-axis end-stop is pressed by hand?

What happens if you request a home operation on z-axis (and end-stop is going to be touched by the bed in its way down)?

misan Wrote:
-------------------------------------------------------
> That is possible if firmware is configured to just
> sense end-stop when homing (but ignore it there
> rest of the time).
>
> What happens if you request a home operation on
> z-axis if when you do it the z-axis end-stop is
> pressed by hand?
>
> What happens if you request a home operation on
> z-axis (and end-stop is going to be touched by the
> bed in its way down)?


1. Hm... where is in firmware? i think my problem where. I don`t see this settings =( Cause X-axis see a endstop then homing (push endstop - move backward, push again, goin backward a little) cab u give a small "code line" for me to i can search for this.

2. still going down, z-axis just don`t care about endstop
3. i check it tomorow.


i feel deeepest sorry for make u read my english

Etherlord Wrote:
> 1. Hm... where is in firmware? i think my problem
> where. I don`t see this settings =( Cause X-axis
> see a endstop then homing (push endstop - move
> backward, push again, goin backward a little) cab
> u give a small "code line" for me to i can search
> for this.
>
> 2. still going down, z-axis just don`t care about
> endstop
> 3. i check it tomorow.

1.
Not sure what firmware you are using, both Sprinter and Marlin have this on Configuration.h file. In Marlin look for these lines:
#define INVERT_X_DIR true // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

changing each value will intert that axis direction.
2.
If you z-axis motion is not affected by the end-stop state then I guess you have a wiring problem.

misan Wrote:
> 1.
> Not sure what firmware you are using, both
> Sprinter and Marlin have this on Configuration.h
> file. In Marlin look for these lines:
> #define INVERT_X_DIR true // for Mendel set to
> false, for Orca set to true
> #define INVERT_Y_DIR false // for Mendel set to
> true, for Orca set to false
> #define INVERT_Z_DIR true // for Mendel set to
> false, for Orca set to true
> #define INVERT_E0_DIR false // for direct drive
> extruder v9 set to true, for geared extruder set
> to false
> #define INVERT_E1_DIR false // for direct drive
> extruder v9 set to true, for geared extruder set
> to false
> #define INVERT_E2_DIR false // for direct drive
> extruder v9 set to true, for geared extruder set
> to false
>
> changing each value will intert that axis
> direction.
> 2.
> If you z-axis motion is not affected by the
> end-stop state then I guess you have a wiring
> problem.


i use marlin oh - i see this lines - but i think it just a direction of axis?
u say
"That is possible if firmware is configured to just sense end-stop when homing (but ignore it there rest of the time)."
line which are responsible for it I didn't find

It is the direction of each axis.

also in Configuration.h you can tell it whether you have end-stops in the MIN or MAX position of the axis ...

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

and in Configuration_adv.h you have:


#define ENDSTOPS_ONLY_FOR_HOMING // If defined the endstops will only be used for homing

misan Wrote:
-------------------------------------------------------
> It is the direction of each axis.
>
> also in Configuration.h you can tell it whether
> you have end-stops in the MIN or MAX position of
> the axis ...
>
> // ENDSTOP SETTINGS:
> // Sets direction of endstops when homing; 1=MAX,
> -1=MIN
> #define X_HOME_DIR -1
> #define Y_HOME_DIR -1
> #define Z_HOME_DIR -1
>
> and in Configuration_adv.h you have:
>
>
> #define ENDSTOPS_ONLY_FOR_HOMING // If defined the
> endstops will only be used for homing


oh!!! conf_adv!!! thx u a lot!
if i //#define ENDSTOPS_ONLY_FOR_HOMING - endstops will work always?

thank you Misan! it finaly worked!
i rewire endstop and "//" this line

Hello,
I am having a similar issue. I am trying to test out individual stepper drivers with one motor but nothing is working (no movement). I have the one stepper motor and driver hooked up on the X axis portion of the RAMPS. I have a 850 Watt power supply connected to the RAMPS. I believe everything has been changed correctly to make everything work. I have the feedrate set to 30 mm/s in the firmware, and have tried changing the homing direction. The motors that I am using have a current rating of 1.8A and I have set the driver to about .5V (I have tried .7V but had same results). I have all of the jumpers installed. When I use pronterface or the LCD control to home the axis, I can hear the motor make the very quiet, high frequency sound, and the shaft becomes unmovable. I have tried all of the drivers and different motors. All of the motors are the same type. From the seller of the motor they describe the wires as: A+ A- B+ and B- instead of 2B 2A 1A and 1B; I wired them as the instructions say red green yellow blue which is A+ A- B+ B-. I have been sure to keep it on for as shot of time as possible in order to keep the drivers from burning up. I would try ramps14test.ino but it will not work due to a line saying that serial is not defined. Thanks in advance.

It looks like you are almost there: motors being hold means the driver is doing some work. No motion could be done due to a software/communications problem.

Have you loaded any firmware to your board? If so, which one? What sorftware do you use in your PC for communicating with the board? Do you get any messsage back from the board on connecting?

If you cannot try the test code, maybe there is a problem with that code and the newest version of Arduino. Could you try that with Arduino IDE version 23?

I have Marlin as the firmware and I am using pronterface as the control interface. I am using Arduino 1.0.1 to upload everything. When I connect with pronterface, it connects and it ouputs all of this:

Extruder switched off. MINTEMP triggered !
Printer stopped deu to errors. Fix the error and use M999 to restart!. (Temperature is reset. Set it before restarting)
SD init fail


I will give the older version of arduino IDE a try to run ramps14test.ino.

Thanks for the reply.

Ok. Stop. You have a problem with the thermistor connection. As Marlin senses an impossible value it shuts everything down.

This makes it not to accept any motion command.

You need to fix the thermistor connection first (even if you do not plan on using the hotend yet).

Alternatively connect a 10K resistor on the thermistor inputs on the RAMPS board.

Then, try again to move the motors, I think they will run fine.

Oh, ok. Thanks for your help. I will dig up a resistor out of one of my bins and give it a try.

Well do not look too much, just a value between 4K7 and 100K will likely be ok.

I tried using a thermistor, the error went away. I inserted a SD card too, and that error went away. I tried to get the motor to turn.... and it moves at an almost immeasurably small rotation. So now it is turning... Just way slow. I will reload the origininal settings into the firmware and see where that gets me. Thanks again for your help this far.

Great. Please note that you can change the speed from proterface boxes "xy:" and "z:" by changing the numbers there.

Anyway, it is likely the default values of Marlin not to fit your hardware. Calibration is needed so motion scale is true.

Sure.

It seems to be working... for the most part. It now has good speed and enough torque; enough to move something heavier than what it's purpose is. For spinning for as long as it has, the motor and controller are very cool. My one and only issue is if I click on the axis movement twice it seems to get suck in moving that axis that one direction and will not respond to anything else until it is reset--That cannot be normal.

I think it must have to do with the firmware and trying to home the axis.

For homing operation you need to have the end stop properly wired (Normally Closed). If not, it will only turn one way.

@kabory thanks for the information about test firmaware & I have tried it with SMPS of AcBel PC8061 + Ramps 1.4 + arduino mega 2560 + nema 17 stepper motor + a4988 stepper motor driver module. thank god it worked. stepper motor started running when i uploaded test firmware but unfortunately motor isn't running when i upload the stepper motor examples from arduino IE. if anybody have solution to this please help. thanks in advance !!

Arduino IDE stepper motor library and examples have nothing to do with RAMPS and they are not expected to work with it.

Quote
misan
Arduino IDE stepper motor library and examples have nothing to do with RAMPS and they are not expected to work with it.

thanks but I've seen so many videos & posts that uses ramps 1.4 with arduino mega 2560 & a4988 motor driver module. i want this combination to be used in my dlp printer for z axis movement only. I tried with test firmware set up worked for first but now its stopped working (may be i need to change motor). same set up did not work with marlin firmware. please help !!

Marlin should work with your hardware if the test code works. But it needs to be configured properly. You need to adapt it to your needs and hardware [solidutopia.com]

Stepper motors hardly are to blame. They are quite durable and resilient.