Stepper driver DIR pin not changing properly
vivian-ng opened this issue · 13 comments
During testing with A4988 stepper driver + 24BYJ28 12V stepper motor, it seems the DIR pin is not changing direction properly. This resulted in random shifts due to skipped steps or moves in the opposite direction.
This phenomenon was not observed when using A4988 with NEMA17 stepper motors.
If anyone experiences the same issues, please report your setup here.
When I was in the use of efsa used use A4988 stepper driver + 12 v MODEL 17 hs4401 stepper motor with computer on line before and after the printing is also about irregular running around, I began to think is PCB version without welding is good, then switch to WEBUI for printing test link to print will be better than the computer, and then moving range before and after the origin about 0.5 2 mm deviation, in the same machine in other printers board go up to normal, I tried many methods, just haven't found the problem...
@wuxiaoyi88 Try using this old version of Marlin, it was the fork by luc before he came up with ESP3DLib. I just did a test today and it seemed to work fine.
I suspect the problem is with Marlin, there were some major changes made to the stepper routines (see PR#16128) and that might be the cause of problems with stepper control on A4988 on 12V. I am not sure if there is any problem with A4988 on 24V. A lot more work will need to be done to narrow down the actual problem in Marlin, because there has been quite a few changes to the stepper control since December 2019, and it will be tedious to determine which change actually cause this problem.
Which version did you test that worked well? Which version did I use? I want to find a version like yours for printing test.
@wuxiaoyi88 Please try this version here.
https://github.com/maplerainresearch/Marlin
It is the old fork by @luc-github before he developed ESP3DLib. I kept it as an archive in case there is a need to fallback on something that works. Like in this case.
Note to self: test Marlin 2.0.2 to see if issue is likely caused by changes made in PR#16128
This is a video demonstrating how steps are being lost in Marlin 2.0.x on the MRR ESPA (ESP32 without I2S stepper stream).
The fork by @luc-github (archived here) works fine. But newer versions of Marlin 2.0.x (including bugfix-2.0.x) seems to cause issues with the steps. As mentioned in a prior comment, I think it has to do with the new stepper routine.
I suspect the problem is with Marlin, there were some major changes made to the stepper routines (see PR#16128) and that might be the cause of problems with stepper control on A4988 on 12V. I am not sure if there is any problem with A4988 on 24V. A lot more work will need to be done to narrow down the actual problem in Marlin, because there has been quite a few changes to the stepper control since December 2019, and it will be tedious to determine which change actually cause this problem.
The motors also sound different, which is why I think it has to do with the stepper routine.
Also, while watching this video by Andreas Spiess, it seems the ESP32's frequency for handling interrupts can become unstable beyond 200 kHz. I wonder if this is something that would affect Marlin, and if so, maybe there is a need to tune down STEPPER_TIMER_RATE to something lower than 2 MHz (maybe 250 kHz like the I2S stepper stream). Wonder if @simon-jouet or @felixstorm has any ideas?
Sorry, but I don't think I can be of much help here, as I only use the I2S stepper stream and also have not followed up with the latest Marlin builds for the last few weeks/months.
I did try to take a short look at the video by Andreas Spiess though and as far as I understand it, he talks about interrupts triggered externally and uses the Arduino framework functions to deal with them. AFAIR the ArduinoESP32 interrupt handling code is a pretty big mess with lots of code running after the actual hardware interrupt came in and before the corresponding application code gets called in the end. This probably needed to be done in order to make the ESP32 core compatible as much as possible to the way interrupt processing has been defined for the Arduino framework some 10+ years ago.
Marlin in contrast uses timers (also interrupts, but internal) and directly uses ESP-IDF functions to setup and handle them, so I do not think that one can transfer Andreas Spiess' observations 1:1 to timer handling in Marlin.
This is a video demonstrating how steps are being lost in Marlin 2.0.x on the MRR ESPA (ESP32 without I2S stepper stream).
The fork by @luc-github (archived here) works fine. But newer versions of Marlin 2.0.x (including bugfix-2.0.x) seems to cause issues with the steps. As mentioned in a prior comment, I think it has to do with the new stepper routine.
I suspect the problem is with Marlin, there were some major changes made to the stepper routines (see PR#16128) and that might be the cause of problems with stepper control on A4988 on 12V. I am not sure if there is any problem with A4988 on 24V. A lot more work will need to be done to narrow down the actual problem in Marlin, because there has been quite a few changes to the stepper control since December 2019, and it will be tedious to determine which change actually cause this problem.
The motors also sound different, which is why I think it has to do with the stepper routine.
Also, while watching this video by Andreas Spiess, it seems the ESP32's frequency for handling interrupts can become unstable beyond 200 kHz. I wonder if this is something that would affect Marlin, and if so, maybe there is a need to tune down
STEPPER_TIMER_RATEto something lower than 2 MHz (maybe 250 kHz like the I2S stepper stream). Wonder if @simon-jouet or @felixstorm has any ideas?
I work in a board similar of ESPA but using esp32 devkit, like a ramps+arduino, and i noticed this problem too, i'm using DRV8825. When a try this fork of marlin the problems gone and i my printer works fine.
I dont think the problem is the timer configuration, beacuse looking the timer.h is the same in both versions of marlin.
I do not think that it has anything directly to do with either the (hardware) timers or 12V vs. 24V.
But since the timing of the stepper pulses has been made "more accurate" in the code with PR 16128: Has anybody tried to play around with the stepper timing parameters (e.g. reducing MAXIMUM_STEPPER_RATE and increasing MINIMUM_STEPPER_PULSE from the defaults)?
If a logic analyzer (or an oscilloscope) would be around, one could even compare the outcome of the pulses with the old firmware against with the current one to get a hint on why the steppers now sound different and might even "see" the lost pulses.
@felixstorm Thanks for the suggestion. I do agree that it is most likely not a timer or voltage issue. I did try to play around with some of the settings in Configuration_adv.h.
Settings and values tried:
MINIMUM_STEPPER_PULSE: 1, 2, 3, 5
MINIMUM_STEPPER_POST_DIR_DELAY: 200, 400, 650
MINIMUM_STEPPER_PRE_DIR_DELAY: 200, 400, 650
SLOWDOWN_DIVISOR: 2, 4, 6
BLOCK_BUFFER_SIZE: 16, 64, 256
Not much improvement.
@luc-github just told me it could be due to a missing #define in HAL.cpp. This causes the I2S stepper stream to be initiated even on boards not using the I2S stream, like the MRR ESPA.
So one thing to try is to edit HAL.cpp such that the HAL_init() function is defined as:
void HAL_init(void) {
#if ENABLED(I2S_STEPPER_STREAM)
i2s_init();
#endif
}
This should solve the problem. I am a bit busy with other things at the moment so I will only be able to try this some time late. I just thought I would share it here for those who want to give it a try to see if it solves the problem.
it was found by @GerogeFu actually
Great!! Thank you all!
I compared the "luc" step.cpp with the official one ... until I've seen this post.
You saved me from a big headache!
Should be fixed. Closing.