Here’s an update on the problem which as noted on Jan 4 post is an incorrect feedrate on linear and angular G1 moves/cuts.
After 3 days of testing, debug, and study I have found that…
-
the problem only manifests itself on XYA (optionally Z) CNC machines, where A is a dedicated rotary axis with it’s own driver and motor. Even simpler, only on XA combination G1 moves, which are typical in dedicated rotary gcode. So if you have an XY machine where Y axis motor drive is shared with the rotary axis motor, then you won’t or shouldn’t experience this problem. I ran a test to prove this after temporarily re-configuring my rotary to use XY motor control. However, I can’t continue to run this way because my Y motor driver is voltage/current tuned to driving 2 motors not 1, so it will burn out my single rotary motor if I do this for any amount of time.
-
Given this XA setup to trigger the problem, even if you have an XYA[Z] machine, if you only use 0 or 90 degree scan during Fill Mode when cutting/etching shapes, then you won’t experience this problem. 0 degrees being parallel to the rotary axis and 90 being perpendicular to it. I ran a test to prove this.
-
On an XYA[Z] machine, if you scan (Fill Mode) at other than 0 or 90 degrees, or if you use any mode other than Fill Mode, then you will experience the problem unless your design is simply 0 and 90 degree lines. I ran a test to prove this.
The problem is due to the grbl X and A axes using different units of measure, which carry forward into motion (feedrate) interpretation. X uses distance/time feedrate, A uses degrees/time. When performing this combo axis move in G94 grbl Distance Time mode, which is the normal motion mode in XYZ coord system, the vector in both axes must share a common feedrate as there is only one F value in the G1 statement block. 1000 mm/min does not equal 1000 deg/min unless the circumference of the cylinder is exactly 360mm, or 1mm/1deg. In my case the cylinder is 267mm circumference. So the math being done in this case to figure out the common feedrate of both axes where the laser is moving at the desired 1000mm/min appears to be wrong, again unless I have a gross misunderstanding of this problem.
So to prove that this is the problem here, and that my machine is configured correctly, I modified LB gcode to use G93 Inverse Time motion mode for those statements that are G1 XA combo coords, aka linear and angular moves. That test and subsequent laser cut work perfectly.
Although LB support has been in contact with me twice in the past 3 days, it’s always at midnight when they write me, and it seems like the problem has not left the ‘user error’ screener yet. So I’m including all the files in this post. I suspect LB support would really like to know if someone else with a dedicated XA rotary setup will experience the same problem. When I run the tests I use a glass mayo jar as a cylinder and wrap/tape a piece of 20# white paper around it. I’m also using a chuck on the rotary, I’m not sure if the problem will manifest on a roller device as there are additional calcs used I suspect. And lastly, I use Mirrored Output to Rotary mode but LB gcode without that mode shows the feedrates are identical.
Thanks for any help one can provide in advancing a solution here.
cheers,
Lou
XA tcB.lbrn2 (35.1 KB)
XY tcB rotary.nc.txt (600 Bytes)
XA tcB G93.nc.txt (756 Bytes)
XA tcB.nc.txt (662 Bytes)
XA tcB G93 v G94 compare rpt.html.txt (11.6 KB)
