Hey All - This is probably a 101 question that I just can’t quite figure out - but I’m struggling to maintain a high feed on a 3D finishing path of a relief map.
Using F360 parallel path with skinny jenny tapered bit - set to 200ipm. The thing flies just fine over the flat sections of the piece at 200ipm, but slows down to about 10ipm when doing the ups and downs on the 3D map surface. It doesn’t do this (at least as much) in the F360 preview, so I’m guessing this is an setting on the OneFinity itself?
Is it possible/advisable to keep the feed rate up, and if so, where do I find those settings?
this is not a setting in the Buildbotics/Onefinity Controller, but can be altered by g-code, so it is your CAM program that should have options for it. The Buildbotics/Onefinity Controller supports it, this is called ‘Trajectory Control’. Since this controller is patterned after LinuxCNC, this help page is relevant:
But how to insert this into your G-code, except doing it manually, is a matter of your CAM program. I don’t know in Fusion360 as I don’t know the program.
There is also something you can control in the Buildbotics/Onefinity Controller, this is on the SETTINGS page:
Path Accuracy
max-deviation mm [0.05]
Lower max-deviation to follow the programmed path more precisely but at a slower speed.
In order to improve traversal speed, the path planner may merge consecutive moves or round off sharp corners if doing so would deviate from the program path by less than max-deviation.
GCode commands G61, G61.1 and G64 also affect path planning accuracy.
Note: G61, G61.1 and G64 are explained in the first link in this posting.
The ‘max-deviation’ entry box sets the Path Accuracy. This defines how much the Buildbotics Controller is allowed to round off corners and defines the maximum allowable deviation when interpolating arcs. Setting this number too low will cause the machine to run slowly. The default value is 0.1mm. This value can be overriden in GCode programs using the G61, G61.1, and G64 GCode commands.
The ‘junction-accel’ entry box sets the maximum allowable centripedal acceleration around corners. Increasing this value will allow for faster traversal of corners but may cause the planner to violate axis jerk limits and stall the motors. Use with caution.
Hi Aiph5u - Thank you so much for pointing me in the right direction here. I spent a little time yesterday messing with the jerk settings, hoping that might help… but I’m still getting my head around exactly how these settings come into play, and the page you shared is really helpful.
I’m going to try tweaking some of these things, and will report back.
@Aiph5u If I understood this correctly, @tschrag needs to specify an F value on a corresponding G-Code line where there is a need to control the velocity for better resolution (finish quality) by controlling the feed rate, correct?
G1 X1 F10 (G1 is linear move, X1 is the destination, F10 is the speed)
I snatched a sample from within a random circular pocket milling file from here:
Given that G1/G2/G3 are movement, the F declaration only needs to appear on each line with a G value, other than G0. Correct? In the example above the pattern is easy to see because each helical pass has similarly formed blocks of G-Code where G0 (rapid movement that specifies Z axis [cutting depth]) Starts the next block.
This leads me to understand that ‘G0 is rapid, so why specify a velocity?’ Therefore, each line that contains some point to ‘go’ to, such as G1/G2/G3, should have the F value set to control the feed rate.
It’s possible that there may be lots of F values to insert. Assuming that the entire file was understood and that it was large, is there an easier way to do this (generically-speaking) without a beer and some hand-editing?
Sorry for the slow follow-up here, but I wanted to post a couple things I’ve found after spending some more time on this, and learning more about the helpful information from Aiph5u. Thanks as well to Timberly for the reply, but Aiph5u wasn’t suggesting I manually add F (feedrate) codes… but rather that I could use the codes he linked to programmatically change the couple settings mentioned here.
For other newbies like me, what I was failing to understand about the particular 3D toolpaths I was cutting (topographic maps with many vertices), is that lots of Z coordinates on a straight line is going to ultimately be just about as fast as the machine handling the same number of tight X,Y coordinates on a piece. For some reason, I was stupidly assuming that my parallel finishing paths ought to be going faster than say, a bunch of tight corners carving some intricate pattern, but the limits of acceleration, jerk, and others on the Z axis are going to be just as applicable with a straight X,Y line… so yeah… it’s just going to be slow doing a detailed 3D surface, even though you may only be taking off barely any material.
That said, the global Path Accuracy and Junction Acceleration settings mentioned by Aiph5u can help with this kind of thing - changing the Maximum Deviation setting from the default 0.05 to 0.1 decreased my finishing cut time by about 18% (no visible drop in quality)… and going up to 0.2 doubled that for a total 46% cut time reduction (maybe a little visible loss in quality, but very minor). Increasing the Junction Acceleration setting from 200,000 to 300,000 mm/min2 reduced the cut time by an additional 8% without any noticeable problems.
This was a huge time save on what started as a 17 hour finishing cut… and combining this with some of the max jerk increases I’ve seen elsewhere has optimized my roughing cuts as well. Again, big thank you @Aiph5u for pointing me in the right direction!
I learned how to change my jerk settings a couple months into learning my machine, and have been running the motors at the 10K setting ever since. It’s shaved about 15% off the carve times of all my reliefs. My usual feedrate for finish bits is 300ipm, and my X50 with Makita has been performing admirably. I’m going to try working with the Max Dev and J Acc settings next, to get some further time savings. Thanks!