Motor is stuck and only humms loudly, will not home or move. M114/Move commands returns crazy value

sgregory

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.

Repetier

Humming sound are lost steps. Typical reasons are
- 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.

sgregory

I should clarify, the motor isn't locked up, it can still move. When I try to home, the one axis that works homes, but the other will move forward some, then back off like it hit the endstop, then move back forward and stop. The thing here though, is that the endstop is NOT getting tripped (LED on the sensor, and I checked with M119 like i said in my earlier post to confirm they were working correctly), and there is one more strange thing it is doing during this homing sequence.

Like I said in earlier, it will move forwards, backwards, then forwards and stop like it is at home. But, it is moving forwards more than it is backwards. So I can keep hitting the home button, and it will slowly move closer and closer to the actual endstop, and once that gets triggered, it won't continue this pattern of moving forward more than it does backwards. If what I am saying doesn't make sense, I can try to reword it. I just have doubts that my speeds or eeprom settings are wrong since it has been running fine with its current settings for months.

Repetier

I was more concentrated on humming since that is what you get loosing steps.
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.

sgregory

I misspoke when I said that it was freezing up and humming, that has happened before in the past sometimes but rarely, so I do think that it is missing steps sometimes so I will look into what you said to solve it.

I am now mainly concerned on why it the motor wont continue to home and it just stops randomly, and why it is giving an extremely off value when I ask for its position. No end stop is hit when I home it (except the X axis one which homes fine), the Y endstop LED does not flash when the motor thinks it has hit the endstop.

In response to homing being short in one direction, it is homing short, but if I keep sending it G28 to home it, it'll eventually make it to the end stop since it moves forward about 10mm every time I send G28 before thinking it hit an endstop, so I can keep sending G28 till it actually hits the end stop. But even after the endstop gets triggered, it still thinks it is at some astronomically high value (well, the value is negative but it is something like -1,667,777.22).

I will look into my eeprom settings like you mentioned, and also make sure my homing steps are correct and get back to you. I just wanted to retype some stuff to make sure I was conveying all the information I have.

RAyWB

Can you swap the TB6600 from the working axis to the not working axis vice versa, I remember i had a similar issue with a broken TB6600 a couple of years ago.

In my case it was a burnt resistor inside the tb6600 so only one stepper coil was working

sgregory

RAyWB said:

Can you swap the TB6600 from the working axis to the not working axis vice versa, I remember i had a similar issue with a broken TB6600 a couple of years ago.
In my case it was a burnt resistor inside the tb6600 so only one stepper coil was working

I just tried out a different one, and that axis was still acting up in the same manner. I also realize that I have them set to 1/32 steps, and I know that most people set it to 1/16, so I am going to go ahead and do the same. I will try to find where in the firmware it mentions this stuff, but if anyone can point me where to go make those changes I wouldn't mind the help!

sgregory

The motor in question is able to turn, I have buttons on a UI that will send it to a specific coordinate, and when I hit that button, the motor will work and move, but it will move past that coordinate and hit something, stopping it there. The motor will continue to hum since it cannot move, and I have to manually shut the machine off or else this will continue. I believe it tries to keep moving since it is seeing its current position incorrectly, even if both end stops were actuated in the homing sequence.

This is why I am lead to believe it may be a hardware failure somewhere in the RAMPS or ardunio MEGA 2560, because of that extremely incorrect value that is being assigned for the X axis. I am looking into the eeprom settings now to ensure everything is correct, but I think it is since it was running totally fine for months. I am guessing this all stems from the massive amount of EMF generated from the weld torch and it somehow broke the arduino/RAMPS

Repetier

Test with torch not enabled so it can not interfere.

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.

sgregory

I am using two linear slides as a X and Y axis, I switched out the arduino for a new one and it is working fine now.

My steps per mm on 1/32 stepping was 1280. The linear slide has a pitch of 5mm, which i used here to compute the desired steps per mm: https://blog.prusa3d.com/calculator_3416/  the equation was (200/rev (1.8 deg) * 16)/(5).

I now bumped it down to 1/16th, and set the steps to 640. With this setup, it was actually dropping steps a lot when trying just to home. Changing it back to 1/32 and 1280 steps in the config file fixed it and it is working fine now. What was I doing wrong where 1/16th wouldn't work? Do I need to change some other setting that I am missing?

Repetier

What speeds are you using? Normally you can reach around 12KHz and with double/quad stepping a bit more. Since 1/16 or 1/32 does not differ much for motors I guess speeds were too fast with 1/16 since processor could create them while on 1/32 it slowed down no being able to do the steps. Or it was jerk related. First step is always critical especially on high acceleration and jerk values. But can't say for sure what exactly it was.

sgregory

Here are my settings for what I believe are the relevant values you're asking for:

#define ALWAYS_CHECK_ENDSTOPS 1

#define MAX_FEEDRATE_X 200
#define MAX_FEEDRATE_Y 200

#define HOMING_FEEDRATE_X 40

#define HOMING_FEEDRATE_Y 40

#define STEPPER_HIGH_DELAY 0
#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

#define MAX_JERK 20

These settings work with 1/32 and 3A set on the TB6600 Drivers, yet when I change to 1/16th it didn't

I set STEPPER_HIGH_DELAY and also DOUBLE_STEP_DELAY to 1, and then ALWAYS_CHECK_ENDSTOPS to 0, and tried to run 1/16 on that and it would still lose steps while just homing (I turned off power and manually turned the motors so it was far away from endstop so it would have to move a lot to home, to make sure that it was doing it well). I tried out every combination of those 3 settings turned off or on, and still no luck.

Are you saying that with 1/32, I would be able to achieve faster speeds as compared to 1/16th? meaning that I have to slow my homing and max feedrate?

sgregory

Thanks again for taking the time to help, it is immensely helpful and I really appreciate it. To tack onto my last comment, what benefit do I gain from going to 1/16th? I was just doing it so it was the same as a lot of other people's builds, but if it doesn't help me reach faster speeds while not hurting accuracy and precision of of the motors, then I see no point in me doing this change from 1/16steps to 1/32.

Also, I guess my original problem is some hardware failure on the arduino, as switching it out solves any issue instantly.

P.S.

I am doing all of this without any welder running, I have yet to run the machine with the new arduino, while the welder is on. I am waiting till I confirm it is all working okay, then I will go back to running the machine as intended.

Repetier

> Are you saying that with 1/32, I would be able to achieve faster speeds as compared to 1/16th?

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.