[BUG] Ramps/Re-Arm losing steps with DRV8825 (layer shifts) #11047
Comments
Bob-the-Kuhn
changed the title
|
There's a possibility that this is related to the layer shift problem we've been having for a long time. I've changed the title so that people from that thread will look at this one. |
|
Its possible that it is related, but I didn't had this problem before yesterday.
|
|
if you are sure that it isnt related to the mechanics / drivers, Try looking at the feedrates, max accelerations and jerk configs, maybe there is something different there |
|
I checked feedrate, acceleration and jerk |
|
Do you have the hardware to check how long the step pulse is? I'l try to get time to look into this, lots has changed in the planner/step generation recently, but I'm not sure what, if anything, has since the 3rd. |
|
I'm sorry I dont have the hardware for this |
|
Could it be that the current of the drivers is just too low or too near the limit ? When playing with new versions of Bugfix and 8825's, I experienced also once a "skip" of steps (but not on all axes) and I had to increase it a bit. To test that, I issued G1 on X, Y or Z to move the head along an axe and put a "light" hand in the way of the head to increase a bit the resistance. If skipping steps, I increased a bit the current of this drive. Perhaps nothing to do with your issue but who knows... |
|
I checked the drivers Vref and it is 0.5V, exactly what it should be. This gives me 1A max current for 1,5A motors (67%) |
|
It was the case for me too. Nevertheless, I had to increase a bit my X and Y axes after the little test explained above. |
|
Okay, I tried to stop the carriage with my finger with no effect. The motors have a lot of torque. I still suspect the stepper timing is off just a little bit. |
|
@kAdonis : Try to increase pulse width a bit. |
|
I tried to increase pulse width up to 5us with no effect. |
|
Okay, 3 motors are probably too much for one 8825 driver and 12V, so I tested with dual z drivers directly on RAMPS |
|
Humm... |
|
ejtagle, noob question, If i use 24v will i be allowed to go faster before the motor stop? I'm trying to increase my 400x400 printer speed, the first step was the volcano hotend, but now i'm looking into faster motion. |
|
24v allows more precise control of motor coil currents. But, you must be very careful, as most RAMPs do not tolerate such increase of voltage, and if they do, then the problem could be the arduino itself, as it also powers its 5v regulator from that voltage. The drivers themselves have no problem going up to 30...40volts |
|
In case of RAMPS/REARM, i dont know, but if the board tolerates being powered from 24v, then i would certainly recommend it. |
|
On my z axis I have 1600 steps/mm but only 4mm/s max speed, 6400 steps/s, much lower than x and y. |
|
I had reliability problems when moving my Z axis at more than 1mm/s. I have 4000 pulses per mm. One of the problems we have now is that the old firmware placed a hidden limitation on the maximum pulse speed ... We removed that limitation (because Arduino is able to keep up without problems at higher speeds. But that seems to be triggering hw problems... |
|
I'll reduce the steps/mm on z axis and do more test tomorrow |
|
I have learned that deducing the maximum feedrate for an axis is very complex... It is not enough to test a plain move. |
|
If, as @kAdonis says, it is possible to go back to the June 3rd build and have no problems with the same configuration then we must have changed something that is either reducing the maximum rate he can drive the axis, creating a pulse train his drivers do not like, .. or running the axis harder at the same specified rate. When it's reproducible like that I can't see it just being the hardware even if lowering speeds fixes it. |
|
I think there was a change... After June 3rd stepper pulse period was fixed. Previously, the pulse period was 8x larger than the desired configured one. That IS a change - The bug only triggered when doing double/quad stepping... |
|
For what it is worth, I have a similar arrangement with high current motors and 8825s. Some time ago I stumbled upon some flyback diode boards on AliExpress, They were cheap so I decided to try them. |
|
@ejtagle Were you able to scope the pulse width when making the changes? Because if you didn't I can take a quick look. |
|
update: |
|
I dont wanted to give up my extra board easily, because (I think) its cleaner to use one driver per motor. I'm really curious how long the pulse actually is? Update : There are still layer shifts |
|
@teemuatlut : I didn't scope the pulse width yet. I have the hardware required to do it, but as printig was and is working pretty well (using 2uS pulses on DRV8845) so i didn´t do it. kAdonis: Try the following: Use a HEAVY copper wire (2.5mm^2 or even more) to join the ground of your external board with the ground of RAMPS/ReARM. Also, place 2 capacitors in parallel between GND and +V of your external board, AT the external board connector. One of the capacitors should be 1000uF/25v (or more), the other one should be 100nF ceramic disc |
|
@ejtagle Thank you for the advice with the capacitors |
|
Hi, I mount my news tmc2130 with external board |
|
The same problem with sbase |
|
+1 |
|
I'm curious, has anyone with this problem tried installing the flyback diodes??? |
|
@ruggb i did, it did not help. both with 4 and 8 diodes versions. |
HI, i try flyback diodesbut it was the same result with smoothieware no pb with or without diode and fast decay |
|
interesting since it worked on my ramps board with 8825 drivers. What could the difference be? I do have some powerful steppers, about 70 (whatever that is, I only remember the number at this point). |
|
@kAdonis many updates have passed, is this still an issue on latest 2.0.x? |
|
Yes, it is still an issue, it would seem the only way to eliminate it is to use the settings above from kadonis.... "The printer prints fine with pulse width set to 5us and a max stepper rate of 140000 kHz( dont know if this rate makes sense)" ... I implemented those settings in the advanced config and the issue instantly disappeared. I am using MKS SBASE 1.2. Thanks! |
the above seems to fix the issue, hence its more a config issue and not firmware issue |
Well .. it is a firmware issue in that the default config value doesn't work, but 32bit timing issues in the stepper ISR are an ongoing investigation so setting higher pulse duration is currently the best solution even though 2us(+abit) should be the correct setting for DRV8825. The timing discrepancy should only be in the ns range though so why people seem to need to go as high as 5us I don't know, unless the drivers don't actually work close to the minimum pulse duration the datasheet says. |
|
I think this should be reopened |
|
we need to figure out if its a bug as such or if default config is wrong and there is also the problem if the drivers work with the pulse the datasheet says, how can we make a default if datasheets are not true? |
|
The Problem here is, that under some circumstances, the actual step pulse duration is shorter than the configured step pulse time. p3p (and me) measured step pulse times as low as 1690ns with configured step pulse time of 2000ns, this is too low for the DRV8825 drivers to work reliably. |
|
i agree, if we can trust the default config actually ouput 2000ns then there is a problem @shitcreek or @thinkyhead should look at this |
|
Having the feeling that issue #11205 is related, I retested with a step pulse of 2us to 5us |
|
@kAdonis, I just posted a link on issue #11205 to a branch with an experimental change to resolve the short pulses. It isn't a fully complete solution. More work will be needed to make it acceptable across all devices, but it could be worth trying. If it does resolve the issue that could inform possible fixes for this. @p3p and I were discussing this issue earlier. The pulse lengths are actually much worse than have already been mentioned in this issue. I saw pulses as low as 856ns when a 2us pulse was intended. |
boelle
changed the title
|
Hello. I apologize for my English. I seem to have encountered the same bug on MKS sBase v1.3. I print through OctoPrint, connected directly to the AUX1 connector. Printserver Octoprint is installed on OrangePi PC+. On advice sjasonsmith (#16218 (comment)) i configured MINIMUM_STEPPER_PULSE 4. The seal more less normalized. Does this mean that I faced the same bug in the firmware? |
|
PR #16128 has been merged into bugfix-2.0.x. This definitely fixed timing issues impacting 8825 drivers on 32-bit controllers, but probably fixes sporadic issues elsewhere as well. It would be great for people to test the latest bugfix-2.0.x to see if issues remain. I recommend you remove any custom MINIMUM_STEPPER_PULSE or MAXIMUM_STEPPER_RATE to be sure you are testing the fix, and not working around issues in other ways. |
|
@sjasonsmith Wel done Jason ! Thanks a lot |
|
I dont have the hardware to test myself, but the issue seems solved |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
and others
Hi there
With the current bugfix version I experience lost steps on all axes with 8825 Stepper drivers
I tried the versions from June 16. and June 14.
The bugfix version from june 3. works fine
I use a selfmade coreXY printer with 8825 drivers in 1/32 mode on X/Y and 1/16 mode on Z axis, after the update the X/Y motors made a strange noise and when I tried to move in X it also moves Y
I played around with parameters and tried MINIMUM_STEPPER_PULSE 4 which helped, but when printing there are layer shifts on every layer.
I tried different MINIMUM_STEPPER_PULSE values in combination with MAXIMUM_STEPPER_RATE down to 65000 with no luck.
Disabling Linear-Advance helps also, but there are still layer shifts.
Disabling Adaptive Step Smoothing does not change anything
I changed the 8825 Drivers with spare A4988 in 1/16 mode and it prints fine again, but now i could see that the z axis with 8825 drivers also loses steps.
I keep Investigating, but I need help
Thanks in advance
configs.zip
The text was updated successfully, but these errors were encountered: