Decrease movement speed?

[MeticulousMaynard]

@krkeegan

Again, I strongly caution I never envisioned allowing a change to the maxfeed rate on the fly, so it almost certainly has major issues.

All $ commands are persistent until written again. Since the feedrate command is not currently in GC, setting it using $15=n will be a permanent change through restarts until you write it again.

Certainly. I figured this feature was one of those “no guarantee of success, use at your own risk” ones. So it would be a good idea to have the startup block say $15=2000 and have the end block say $15=1000 to revert it after the program concludes. That way the change does not persist after the test program.

@krkeegan

I know everyone wants their machine to go faster, but the sad news is that it just can’t with the current hardware. There are a few places near the center where vertical movements could be faster, but most of the horizontal movements are all maxed out around 1000.

Yes, I know that the limit is really in the hardware, not the firmware. I went through a couple of hardware options in this thread to fix the issue. I have some 25 tooth sprockets as @dlang suggested that I am planning on testing (you know, when I have that magical thing called time ). If that doesn’t give me the results I’m looking for, I intend to look into 24v motors and the needed H-bridges to power them.

@krkeegan

Agree, but this is a ways off. A lot of work needs to be done to the firmware before we are at a point where something like this would be possible. Grbl solves this problem by breaking each code block into 100s or 1000s of execution blocks, which is probably what we will end up doing as well.

Definitely, I meant that as a “wish list” sugestion more than an immediate fix. I’m not an Arduino/Python programmer but I can imagine that is no easy feat.