Closed campe89 closed 9 years ago
How many steps per mm do you have? That speed is slow for belts but fast for lead screws.
The speed is referred at the X Y movements with belts and t20 pulley; the microstep is 160.
There are un-resolved issues with DRV8825, see https://github.com/MarlinFirmware/Marlin/issues/975. Not sure if that is your problem though.
I can try with the old a4988
is this one still relevant or can we close it?
I haven't resolved the problem; but you can close.
we should only close if either:
1) its not a bug in firmware 2) it has been fixed...
as @nophead said there are some un-resolved issues in #975 and in there at least one other issue is mentioned... but those issues went dead and we opted to close them as there was no response.
i have now opted to mark it as a verified bug on the grounds that there are still issues..
My guess is, that the gcode has a very high resolution. With that, the planner has a lot to do (a lot of expensive devisions) and this can make this issue.
@Wurstnase I think the same. Maybe Arduino Due can resolve the problem?
that would also mean its not a bug in marlin
@boelle yes, I think so @campe89 well, the Due is much faster (~10 times) but the planner is a realy expensive part of Marlin.
Just 2 numbers: With the old 32bit Marlin from bobc (with only some tweaks) you can reach 46k steps/s. And there is just one division in stepper.cpp. With the lookuptable the possible steps/s are doubled to ~96k steps/s.
The only thing which could help is that the buffer can be bigger than in the AVR.
will close this one...
its not a bug with marlin, but rather just a limit on the speed that the hardware can process gcode at
Issues like this can be exacerbated by having a graphical LCD which uses up time, and by printing over USB, which is not as fast and error-free as printing from SD. It's not just limited to the planner. Even if there is some planner optimization, it probably wouldn't be enough to completely eliminate stuttering when resolution is very high and when printing from a host. But when we hit limits like this it's good to know! We can now at least document that such speeds are close to the limits of USB printing for a basic RAMPS (with Mega 2560?).
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.
Hi, I have a ramps 1.4 with drv8825 (32 microstep) mounted on a home made printer for laser engraving. I have repetier-host 1.0.6 on windows 7 x64 and the gcode file is about 80MB. With 10000mm/s² of acceleration, I can go up 2000mm/min for a fluid movements; at more speed the printer goes at intermittent movements. Can be a mechanical problem? firmware? host software?