Not sure if there’s a better name for this, but I’m experiencing something weird with DRV8825 drivers on a Ramps 1.4 board running GRBL. I noticed an issue that while only telling one axis to move, the others will occasionally move random steps, throwing off the alignment. I originally thought it was skipped steps, but when running a program that only moves one (dual stepper X) axis back and forth, I noticed the other two (Y and Z) moving small amounts over time and you can hear the steps when they happen. I also unplugged the Y axis motors, ran the X axis only program again and didn’t get the movement on the Y axis while Z still moved a bit, leading me to conclude it is an electrical issue, not a mechanical binding. I then swapped the drivers for A4988 on the Y axis and the issue went away on that axis. What’s particularly weird to me is that it isn’t lost steps as the program never steps Y or Z (it’s just G0 X0, G0 X600 over and over), but rather extra steps that I can’t figure out where they are coming from. I tried two different brands of drivers with the same issue. I’m ultimately planning on just swapping all of the drivers for A4988, but wanted to see if anyone else had ever come across this issue.
I haven’t seen this exactly. But here are some thought that might give you some ideas:
- Could the grub screws be loose? They would let the pulleys move on the motor shafts without the stepper moving. That doesn’t really fit your symptoms. But it is worth a check.
- We have seen some noise in the gcode sending. Something like G1 X100 Y100 would be seen as G1 X100 Y10A, and that would be interpreted wrong, sending Y off to oblivion. That was due to noise in a uart connection (not USB or microsd). Pretty rare, but if you have a way for your sender to have noise, maybe it is that.
- The motor lines to the motors have a lot of current. They are pretty tolerant to noise because of that. But we have seen stuff like a dust connector hose or the router AC wire causing interference with the motor lines.
- The digital signal between the mega and the drv8825 is pretty short. But if this line is susceptible to noise. If that step pin flips from high to low and back, that will be a microstep. There isn’t a lot of current flowing here, so a loose connection or a bad solder joint can cause havok. Any large emi nearby could cause a little current, which would be enough to change the state. But we still haven’t seen that very often. But we also don’t have many Ramps users anymore. Most have moved to integrated drivers like the rambo and skr pro.
- My constant word of warning for ramps users is to make sure you adjust the trim pots on the drivers. They are never correct out of the box.
Thanks for the reply.
- Based on what I found here, the very first thing I did was check the grub screws. All are tight and I verified with the motors energized, it moves. With the motors not energized, it stays put, so that wouldn’t make me think the pulley is slipping.
- I’m sending G0 X0 and G0 X600 over USB to the Arduino Mega connected to the Ramps 1.4 shield. There is no Y value sent and with A4988 drivers, no issue so I don’t think it’s that.
- Same note about different drivers not causing the issue. Also, the longer wires don’t have as many issues as the shorter wires, but perhaps there’s something there if the current setting is different. I might look into shielded stepper cables.
- I’m thinking this may be the most likely, but again, different types of drivers didn’t have the issue. I’m wondering if one is more susceptible to a noisy input voltage (gray input) than the other though. I did notice when I put the DRV8825 into 1/16 instead of 1/32 mode it moved more so I’m guessing it was actually sending microsteps. I’ll probably upgrade the board to a spare BTT Octopus when I get a chance, I just have to pull together the firmware. The Ramps board was a cheap way to get it going for now, but that may be part of the problem.
- I have Vref set on all of the drivers. I tried increasing and decreasing pretty significantly with no impact.
Wait you cant just change steppers like that can you @jeffeb3 ?? Fw is set to one or the other. Does this happen if you put an sd card in and run it or is this only from pc? I run ramps 1.4 with 8825. Been flawless until i moved it manually too fast, oops.
Oh snap. I did not see you were running grbl. Can you put the v1e fw on and test??
I’ve have a couple of (non CNC) projects running on Ramps 1.4 and DRV8825 drivers. I’ve never seen an issue. You could swap in a new Ramps board for around $8 to see if that makes a difference. Could there be some issue with the microstepping jumpers or pins? If there was an intermittent disconnect in a jumper, you would see occasional extra movement.
I don’t think its the jumpers as switching the drivers to A4988 with the same jumper configuration doesn’t cause issues, but I do think it may be related to the cheap Ramps board. I’ll probably put the $8 towards a better board though and just make the switch if I ever get tired of the current setup with A4988 drivers.
Even in Marlin, I think they should be interchangeable as long as you get the microsteps set right. I’ve switched A4988 with TMC2209 before an never had an issue in standalone mode. I may try the v1e firmware, but I’d prefer to stick with GRBL for this as I want to use both a router and a laser with it and I’ve read about issues using Lightburn with Marlin.
Why not put the v1e fw and copy the crown just to seee. Before spending any money? The fw is there to download. Set steppers to .7 and use 8825 as that is what the fw is ready for. At least you would know if it still happens it is not grbl
That’s a good thought. I think I’ve narrowed it down to some interaction between the Ramps board and stepper drivers, but you bring up a good point that it could be GRBL related causing it as well. I’ll try that later tonight.
The steps per mm need to change. But that can be done with gcode. There are also driver type settings. I think that has some effect on the duration of the microstep pulses. They didn’t used to have those settings, so I have largely ignored them 
. They may make a difference.
Just wanted to say thank you to all those who offered suggestions. I’ve narrowed down the issue to either the Ramps board (most likely) or the Arduino Mega (less likely since I’ve had it for years). I changed the drivers to A4988 and noticed I still gained 2 steps on Z while repeatedly only moving X and Y via Gcode, although it fixed my X and Y problems. I flashed Marlin to verify it wasn’t the firmware and it still gained a couple of Z steps while sending commands via a terminal on a different computer and different sending software. Since a couple of steppers now seem good, I’m pretty sure it is the cheap Ramps board I’m using. Thankfully I’m still within the return window for it so I’ll send it back and I’ve got an SKR Pro 1.2 on the way. I may also stay with Marlin since I’ve got a spare TFT35 sitting in a drawer and it would be nice to have some controls outside of the computer.