Motor is stuck and only humms loudly, will not home or move. M114/Move commands returns crazy value
I am using a X and Y gantry robot to do some movements while holding a welding torch, which is causing a lot of EMF issues. The program will sometimes just freeze and need rebooted, but now it has just broken. This is the second time it has happened.
My setup is an arduino mega 2560 with a RAMPS 1.4. The motors are wired to a TB6600 micro stepper driver, which wire directly to the three X step, dir, and en pins on the RAMPS. I believe I had it all wired correctly as it was working totally fine for a while until the EMF just got too big for the arduino to handle I guess. Now, I am trying to find out what in the arduino/RAMPS is broken.
The main bug that I am seeing is that when the program starts, it will home to origin, but instead, the motors will just hum loudly and not move, or move back and fourth slightly like it just hit the endstop. When I open the serial monitor and try to home, move, or get the current position (M114), it will read out some crazy wrong number (something like -166677.72, this isn't the exact number but it looks a lot like that).
I checked the analog pins that correlate to the three pins connected to the stepper driver by just hooking up a potentiometer and seeing if they were reading out correctly, all three for the X and Y were reading out fine. I then checked the digital pins that the end stops were using with a pushbutton and pulldown resistor, and they read fine. I also checked the endstops by manually tripping them, then calling on them with M119 and they would read open or closed correctly.
I have no clue what is wrong with the Arduino, and I do not think it is the RAMPS fault as I was able to just switch out the arduino for a new one, and it worked fine again (albeit this one also ended up doing the same thing but for both axes now). If there is any idea please let me know.
Comments
- jerk too high
- acceleration too high
- speed too high
- motor current
- only one coil has contact to motor driver
- movements blocked
When it starts loosing steps it often does not recover until steps end. So first step is check eeprom setting - especially if steps per mm match your microstepping setting, acceleration and jerk and max speed make sense. Strange values should not appear - start position is normally 0. Bit when some eeprom values are bad anything can show up and mess frequencies.
Make sure no end stop is hit. If you home x first you must untrigger x end stop before homing y. That is a special gantry problem since both motor move for x and y movements.
Also if all homing are too short in one direction, check eeprom what length for that direction is stored. Homing stops at 1.5 x distance so if you have 10mm it will move 15mm or until end stop is hit. Of course if you have 100 but steps per mm is 10 and should be 100 it will also only move 15mm:-) Both would fit what you now described.
But when you see it moves, just more then expected it very much sounds like the steps per mm is too high which can also lead to strange coordinates. Also with gantry position depends on both motors and xy position gets computed from x and y motor position. But still strange since for pure x it must fit as well.
Are you using plain xz gantry or nonlinear version? They differ in steps per mm by factor 1.414 or 2.0.
#define MAX_FEEDRATE_Y 200
#define DIRECTION_DELAY 0
#define STEP_DOUBLER_FREQUENCY 12000
#define ALLOW_QUADSTEPPING 1
#define DOUBLE_STEP_DELAY 0 // time in microseconds
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_X 1000
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Y 1000
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_X 1000
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Y 1000
No, the opposite is true. Higher microsteps need more signals and these are limited. Only below STEP_DOUBLER_FREQUENCY you have full accuracy. If you get faster it starts first always sending 2 steps at once and than add a pause instead of step pause step pause. So if you have 200 steps per mm this switch happens at 60mms. If you reduce to 100 steps per mm the limit is 120mm/s. If you exceed 40khz the timings can not be reached and moves are slower then you said. If it moves fast enough for you with 1/32 just stay since it works and be happy. On low speeds it does not double steps, only once speed reaches the limit and there double/quad steps won't hurt and on low speeds you have more silent motors with higher accuracy.
ALWAYS_CHECK_ENDSTOPS is only used when not homing. If you get wrong end stop signals (crosstalk) during print it is better to disable test and just asume you loose no steps. Otherwise you shift position during print with each wrong end stop signal.
DOUBLE_STEP_DELAY is if you are >12000hz. Drivers need a minimum low time on step signal to detect it. If you loose steps because you are too fast changing signal (or driver is too slow) you can add this. If fast moves running faster then double frequency are precise the value is good.
For 1/16 test you'd rather reduce acceleration to 100 and see if it works. Not that 1000 is much, also it really depends on mass you are moving. But printers can do more normally. Just used low value to be on safe side. You can adjust in eeprom easily if it then suddenly works. Also jerk is mass dependent and 10 for testing is better. Once it works you can test limits and reduce enough to be on safe side.