I was 45-min into a 2.5 h laser cutting project when I returned to the OF and found it ramming into the right side of the frame. For whatever reason, it appears to have lost orientation during the cut. After stopping the operation, I haven’t been able to reset the job, even after a full restart of the controller, and now when I use the same file that loaded previously, I get the following toolpath error on both the X and Y axes: “The current tool path file would move 0 mm below limit with the current offset.” This is occurring even though the offset is zero for both X and Y, so I’m stumped. I had hoped that I could line up the laser on the origin point, re-zero the work coordinates, and restart the cut, but I can’t get anything to start because of the toolpath error.
Thanks, and I had considered that point. I’ve diagnosed this as a Lightburn issue, considering upon running the gcode again, it failed in the same place on line 20838. Having been present just before the failure, I could hear the OF servos ‘twitch’ while moving on the long horizontal (straight) line that constitutes the bottom of the model. Whatever happened at that juncture in the gcode caused the OF controller to lose orientation and the simulation point suggested the machine was parked at the origin, when in fact it was in motion and heading toward crashing on the right side again. I’m not an expert in diagnosing gcode, but at least I know this has to do with the output from Lightburn.
I’ve continued trying to diagnose this issue, and I’m hoping that someone could evaluate the gcode file that is causing the issue. Also, I’ll clarify that this gcode is produced by Lightburn as this is a laser-cut project, and I’m happy to have this thread moved to the OF>Lightburn board if that’s most appropriate.
I’ve attached the gcode file here and the line where things go awry is 15855. Basically, this is the Y move where it creates the straight line at the bottom of the cut (see attached image). And the ‘toolpath under’ warning that I’m getting in the OF controller web interface still doesn’t make sense to me, because the entire workspace fits well within the OF limits. Again, I’m not homing the laser before the cut but I am positioning the stock in the middle of the workspace, which means both X and Y axes still have plenty of room to reach all edges of the cut.
I’m really at a loss here and my mother-in-law has asked for these to be cut for inclusion in her Christmas decorations, so any assistance is appreciated!
Alright, one more update here. I took a different approach and homed the OF before starting the cut. That action ensured that I started with all toolpaths ‘green’, which means the under limit ‘yellow’ warning was not present. I made sure I was by the OF when it was making the long X travel at the bottom of the cut (approximately 18" left-to-right). When the laser was approximately 10" into that cut, I could hear the servos ‘jump’ for a split second and when I looked at the OF screen, I noticed that the X position went from +10" to -10" and was moving toward 0". In that moment, I had the wherewithal to capture the screen for documentation purposes. What I noticed was that the servo ‘jump’ coincided with the workspace origin changing, and this is why the laser keeps moving past the right of the cut. Attached are images of the servo positions (notice the negative X value) along with the cut simulation (notice the tool is WAY to the left of the workspace origin).
I’m hoping that the OF support team is willing to keep helping me figure out this situation. I’ve already posted the gcode and I would appreciate it if OF (or others) could use that code to verify whether this phenomenon can be replicated. Again, this gcode was created in Lightburn, but the errant travel in the middle of a straight line X move and concomitant and audible ‘jump’ of the OF servos suggest this is more than just a gcode issue.
Just in case this is helpful information, I also flipped the toolpath such that the long cut at the base of the shape was on the Y-axis and the exact same behavior occurred. While at the 60% mark of the long, straight cut at the base of the shape, the OF servos audibly jumped and the tool in the simulation was relocated outside of the workspace bounding box. When this occurs, the OF never deviates from the straight line, nor does the laser stop cutting. Because the tool thinks it has a much longer distance to travel after that event, the machine attempts to continue beyond the max travel distance.
I remain hopeful that this is something obvious that I’m missing, and perhaps this thread can be used for others that are experiencing this strange behavior.
I also tried changing the ‘Start From:’ in Lightburn from ‘User Origin’ and ‘Current Position’ to ‘Absolute Coordinates’, and the same behavior occurred at the same place on the straight line at the base of the shape. I was hopeful that this was a coordinates issue (relative vs. absolute), with the OF and Lightburn not necessarily aligning on what it meant to be out of bounds, but alas.
One more update. If I resize the full shape to be just 5" wide, then everything works perfectly. Again, this suggests an ‘exceeding bounds’ issue between Lightburn and OF is causing the servos to twitch and the tool location to be reset mid-cut.
Okay, I don’t give up easily, and I plan to continue documenting the various troubleshooting steps along my journey in this thread because this is strange. I went back to the original model and cleaned up a few sketch remnants in my drawing (originated in Fusion 360); that gcode file is attached here.
I thought that had fixed the problem because when I ran a single laser pass at 25 ipm of just the model outline, everything worked just fine. Of course, at that velocity, I’m only etching the 3mm plywood even at 100% power on the laser, so I reset the Lightburn settings to be at 3-passes and 6 ipm, which does a great job of cutting the plywood. To my chagrin, the cut failed in exactly the same way (this time, on line 21922).
The ONLY difference between the test and real cut was the velocity of the OF gantry, though I don’t understand how moving more slowly would cause the observed behavior. All I can do at this point is to test various velocities to see where the threshold may exist. Perhaps someone out there will see these posts and be able to shed some light on this confusing situation.
Last post here, but changing to 10 ipm and using 5 passes at 100% power allowed me to finish the job. This situation still makes zero sense to me, but perhaps someone smarter than me can use this anecdotal documentation to their benefit down the road.
