I just spent about an hour working out best reliable accelerations and max seek speeds on my SO3 XL. I have a leadscrew Z axis, which has considerably higher friction than a belt system (the cncnewbie one…not the cool one from Mr. Beaver…).
I don’t know if all machines should be able to do this or not, yours might not.
This doesn’t change the proper speeds/feeds for cutting, it’s just the seek/jog speed. I don’t think this is useful for actual cutting, but if you have a lot of seeking going on in your gcode, it might make a difference depending on the length of those seeks.
X Axis maximum rate 35000 (yes, 35k, not 3.5k)
Y axis maximum rate 25000
X axis acceleration 1000
Y axis acceleration 700
Z axis is “pretty slow” by comparison, but only moves a few inches.
Z axis maximum rate 6000
Z axis acceleration 500
I have homing seek set to 8000 because it really shakes the machine and table hard when it slams to a stop when it hits the switches at 35k.
I tested by setting a WCS zero in the far corner from home, wrote a macro to go back and forth between an inch from home and WCS zero 100 times and watched for skipping. It’s really easy to see and hear the skips at these speeds. At the end of the test, it showed within a few thousandths when seeked to WCS zero, so I’m pretty confident it’s not skipping.
Y appears to be more sensitive than X to speed and acceleration - which makes sense, it’s moving a lot more mass.
It is really startling to see the machine move this fast after it’s been set to 3000 max speed for a year and getting used to that.
This may have been true with earlier versions of GRBL, but it is not with 1.1. There is a parameter for ramp speed (which is also configurable per axis - see the “axis acceleration” values above), and GRBL is clearly honoring it.
I will take a look at g2core though, thanks for the pointer!
Ahhh, reading over the g2core jerk control wiki page again, I may have been misunderstanding the acceleration bit for GRBL. It seems like the non-jerk-controlled approach is to indeed use an axis acceleration value. The problem is that it’s static and not an s-curve.
The math itself is beyond me atm, but the animations I can get.
There is definitely a difference between the two, and how is approaches combined axis movement, but it’s not clear to me if the difference is mostly academic or “actually makes a difference.” In the case of rapid’s from a to b, seems like probably not. In the case of milling operations between b and c, given how slow those usually occur with a tool (ie. not with an extruder) I’m not sure there would be much difference. For 3d printing with an extruder, I can see how it might be a bigger deal. Either way, it’s interesting that there is a different take on the problem.
Yeah, I’m not sure with finish quality stuff either, as I mostly cut MDF for prototyping. I wired together my own g2core controller board based on an Arduino Due and some stepper motors, then rewired my S3 with that.
The higher speed thing was somewhat useful when the spindle moved around the table. On the other hand, it was noticeably way more dangerous too. With GRBL it’s fairly predictable once a job has been run a few times to understand how fast it moves. So, if you happen to be manually vacuuming stuff every now and then to remove sawdust or whatever, it’s mostly ok.
DO NOT do that with a g2core system. It’s quite capable of moving at such a speed that it’s not possible to react in time. I came close a few times (twice I think) early on before realising this was no longer an acceptable approach to vacuuming.