I am most certainly sure, that this is an electronic problem, but there is a way to make a workaround in software, since the electronics of this project can’t be altered.
The problem: Z axis is not moving, right after one of the other axes stopped. So e.g. the mill moves it’s planar position to where it should drill, but Z won’t move downwards there.
BUT if there is only a fraction of a second delay in between stopping X/Y and moving Z, it moves without issues.
I already tried hard-coding a delay in grbl in various locations, only resulting in stutteringly motions, when milling circles.
My question to someone, who knows and understands the code better than i do: where does it make sense to put a hard-coded delay, so it will only delay right before a Z movement?
评论 (2)
#2 – c5e3 于 2019-10-23
We actully ended up replacing the drivers. It was quite expensive, but the best solution.
#1 – biasedlogic 于 2019-10-15
Make a software parser that will pre-parse the G-Code and inject G4 P some-little-time wherever necessary. Trust me, this will be faster and easier to do.