Here’s an update on this mess I’ve created and an attempt to clear it up…
Primarily the problem (in my machine’s case) continues to be the problem as described in this post #8 above
My machine mfg (MillRight) folks have been looking at this in priority with other work for the past week as a possible bug in their custom grbl v1.1i. The history of them even having a custom grbl version has origins in that they were one of the first Arduino grbl versions to support XYZA axes, having adding dedicated A axis support in the then grbl XYZ v1.1i in 2018-2019. Although we’ve corresponded several times in the past week, and I’ve run some further testing for them where the results suggest its their bug in grbl (according to CNC Machine Overview) I have not heard from them that they have actually run my simple “XA tcB.nc” test case that produces the over cooked laser lines in the photo of post #8. However, I corresponded with another of their customers that has the same model of machine as I do, and he’s a known prolific rotary project craftsman, he tells me he has noticed at times much slower than expected G1 XA moves but couldn’t put his finger on the cause; he’ll run my test case within a day or so to confirm it and get back to me, as will the mfg I expect.
So net msg is-
- I have two more data points that suggest the root cause bug is in the mfg’s custom grbl controller of my machine. Absolute confirmation of this will take another couple of days perhaps, until someone else with my machine model runs the “XA tcB.nc” test case and times the G1 XA moves, those are all 45mm lines that should traverse in ~2.7secs if grbl is operating normal, in my machine’s case the steeper angle lines take progressively longer times to traverse, the last line at 80 deg takes ~15secs; hence the cooked line.
- However, in another test case I made the other day for LB support to demonstrate the problem, I discovered that LB ‘Fill’ mode uses the layer design feedrate for F value on all scan angles 0 to 90. So any angle other than 0 degrees is using the wrong gcode F value, but as the angle gets steeper in this case, for a normal operating grbl, traversing the lines gets faster since delta X is getting shorter and the programmed feedrate is not changing for those G1 XA moves. This threw me for a loop early on in this saga and I went down the simple test case rat hole of “XA tcB”, and being “lasered” in on that expecting it was the cause for all oddities in feedrate that I observed in the gcode and as my machine ran the motions.
Net net - It appears very likely there are two bugs here, one in my machine’s grbl controller, and one in LB in the case of Fill at other than 0 deg scan angles.
Both companies are working on it at a priority relative to other issues, understandable.
Here is the holy grail of both bugs in one test case.
Cheers,
Lou
XA tcC Fill-OffsetFill-Line.nc.txt (8.3 KB)
XA tcC Fill-OffsetFill-Line.lbrn2 (26.2 KB)