I’m running 9.09 with the patch from last night afaik. Earlier Oz helped me get my laser back to firing at full power. I burned a few files, then had one freeze at 69% complete with the laser off. I tried it again and got freeze again. I tried another file that worked so chalked that up to bad gcode.
Now I’m trying to burn another file that is 140x260mm, well within my 180x300 bed. To be sure I tried to frame it. Frame starts from the center position and heads NE, toward top right, and then just stops. No rattle, no missed step sounds. At that point it won’t go back to the origin, or center point. It tries but is way off. I can jog it all the way to the ends of the screws for x,y. Don’t know if this is related to the OP’s issue.
I just loaded another gcode that is 132x189 and framed it, worked fine and back to the origin. The files that failed worked fine a few days ago. All the files were generated with Lightburn and none are new today.
I’ve split this to a new topic because the framing issue with Ruida is not related to any framing issues with GRBL - the code is completely independent for these machines.
What origin mode (Start From setting) are you using for this?
I’m using center of the bed, job origin set to center.
I’ve burned a couple of other files with no problems, and framing works fine, with return to origin. One of the problem files may have been generated before I got 9.09 patch.
I can attach the problem gcode file if needed. I’m in the midst of making a new file, playing with text to path, and I will do more testing.
I just made a new design in Lightburn, 150x150mm. It frames fine, and burns great, a little hot. I have to remember that the laser is working 100% now.
Another new design, 117x129. It has text fit to a path and some lines from tracing images. I didn’t try framing, just started burning from center. It was making good progress and I was watching the 50% burn instead of the screen so I don’t know what percentage. It got to a part that was toward front left, but not near the corner, and just stopped with the laser off. There was “thunk” sound but it didn’t hit anything and the screws and bearings are free. I checked the coordinates and found that it had reset x0y0 to that point where it stopped. Of course go to origin does nothing because that’s where it thinks it is.
Wow, the settings are scrambled.
$$
It would not jog. I reset the controller, restarted Lightburn, and reset the settings to what I had earlier, with the corrections we made. Reloaded the file. Now it jogs and frames. I reduced power to 25% because 50% was still burning too hot. Tried a burn and when it got to the point it died the last time (as far as I can tell) it went off left and front and hit the wall, losing steps. No switches yet. It then returned to the burn, off by whatever steps it lost. The burn completed and it returned to where it thinks the origin is. A quick glance at the settings looks OK to my untrained eye.
I just ran this same file for the 3rd time and it completed with no issues other than running way off front left. I did not reset the origin so it didn’t bang the wall, just went there and came back. In this preview you can see the path that just runs off thataway for some reason. There’s nothing to cut out there. I’ve noticed several files that do that. It doesn’t at all explain the earlier crash on the 1st run of this file, that garbled my grbl settings.
There is no universe in which LightBurn would start sending commands that affect the settings of your controller in the middle of a job. It simply couldn’t happen. It sounds like the flash memory on your controller is fried, and not holding values. A power surge or ground fault could cause what you saw as well.
Since that incident I’ve successfully burned several designs and am 12% into burning a grayscale image right now. My fried flash memory must have healed itself during the night while powered down.
I would be more inclined to blame it on losedoze, The 10Pro I run is flaky and tends to crash randomly. It may have glitched the stream over USB. I’ve compensated by using Lightburn to save the gcode on my Raspberry Pi and using that to feed the code to the controller. I don’t trash as much material that way. The last couple of days I’ve gone back to using Lightburn to directly control the laser but am about to go back to the Pi for reliability.
Lightburn will still be the source of gcode and I really like most of the design capabilities. I do wonder why it seems to be all over the place with half of a letter here, half of one on the other side, back and forth. I’ve used optimization and obviously not correctly. Why did it need to send the head way off the pattern like in the above design? There is nothing in that corner at all.
That move on the preview is a travel move, which could just be it moving to the user defined finish position if you’re in “User Origin” or “Absolute Coords” mode. You might also have an empty object - try selecting by dragging a box around the origin point, from right to left (green, crossing selection) to see if it snags anything.
How long is the USB cable you have connected to the machine? If it’s over 16 ft it would be out of spec for USB.
The move to the corner is at about 45% of the burn, not the beginning or end. The cable is not long, less than 12’, and is not a cheapie. My origin is center with return to center. I’ll reload that design when the current burn is finished and see if anything selects over there, but there should be nothing. The design is traced images and I used boolean subtract to overlap them. There was nothing outside the design. I deleted the images after tracing so there is nothing left but the lines and the not shown and not output circle that the text was fitted to. I’m not complaining, just wondering why the text and other lines jump all over the place instead of burning all of an area at once. I’ve tried grouping and that didn’t help even with group priority set. It does take much longer to burn with all the extra back and forth movement but in the end it’s accurate enough that you don’t see any problems in the result.
For this file I was trying order by layer which does not do what I thought, obviously. It first burns part of the blue layer, then the orange layer, and then back to finish the blue layer.
I also checked machine settings and it only gives four choices for origin with the lower left selected. Definitely machine origin but it didn’t need to go there. In most cases it does not, it stays within the bounds of the burn and returns to center. It’s an aberration
Order by layer should absolutely do what you’re saying - it should run everything on a layer, then everything on the next, and so on.
Try enabling ‘Cut inner shapes first’ - it’s so rare for that to be off that it wouldn’t surprise me if there was a hole in the logic somewhere that’s causing the issue you’re seeing. I’ll run some tests here and see if I can reproduce what you’re seeing.
Before I do that - are you sure that you don’t have duplicate shapes between the two layers? I see parts around the middle that are both blue and orange - Turn off the ‘Show’ button for the two layers to make sure you really have what you think you have, just to double check.
There were four images traced, and then they were subtracted from each other to get the overlap without a jumble of lines. There are overlapping lines and when I preview it tells me it’s removing overlapping lines. Should I add them all together? I can’t test the file until that grayscale finishes in a couple of hours. In the burn I last did of this file it did not reburn the overlaps that I noticed.
I just enabled cut inner first. I could send you the file if that would help.
If you could, it would mean I’m looking at the same thing you are - send it to developer@lightburnsoftware.com and include a link to this thread so I know what it’s for if it takes me a day to look.
FWIW I tried union and weld of all the lines, and put them on one layer. Turned on “cut inner first”. The preview seems to have a lot less jumping around but it still wants to go the the machine origin in the middle of everything.
I’ve run this file on my system and I don’t see what you see - The ‘from the left’ long traversal is it traveling from the origin to start the job. It does all the orange first as expected:
