I’ve done some more complex stuff, including purposely having the overscan go past the edge in the preview window…and I can’t get it to crash now. I’ve tried on all 3 versions mentioned.
The only change I made after installing the panel was to delete 2 projects that were listed in the controller’s memory. Maybe having old projects on their confuses the stupid controller or something? I might try sending a couple projects, and then run a new one with Start in LB and see what happens.
Wow. I’m trying to get my head around how people are expected to use this without a panel then…
If the controller is near the maximum storage limit this absolutely can cause odd behaviors so that might be actual root cause. Let us know if you can recreate the conditions.
Interesting… this is pretty much the scenario I was attempting to describe earlier. I’ll try pushing Enter at some point in the future if I run into this to see if I can get funky behavior.
The part I’m trying to understand now is if the LightBurn crash scenario is still in any way tied to this. And if so, how that could possibly be.
That did it. I loaded a bunch of files on the controller, and then running the rectangle crash test worked (well, failed 
). The job halted, then I tried to hit pause or other buttons in LB and LB crashed. There’s also a red status ring on the Polar and a hard limit showing on the panel. ESC sent the laser back home.
Hitting reset on the panel wasn’t enough to correct the communications with LB. I had to power cycle the laser.
This isn’t easily repeatable though. It seems there has to be files on there to annoy the controller in some specific way.
I’ll ask other users with the crash issue if clearing the files list from LB helps.
Thanks,
Josh
Even knowing that full storage on Ruida controllers caused issues I didn’t expect these symptoms. Very interesting indeed.
I’ll do some more experiments this coming week and see if I can make something easily repeatable happen.
This is great work. Thank you for sticking with it.
It looks like you’ve solved this. I’ll wait to see if you find anything relating to 1.4.02 and 1.4.03 and adjust the topic title to accurately reflect your solution.
I’m not sure there’s anything version specific at this point. Some people with other issues had less trouble on 1.4.01, but clearing the file list did help. I don’t believe the memory was near its limit, unless something wacky was going on. There were only two files on there at the time, neither bigger than 1MB. In my tests to crash LightBurn, I put more than 10 files on there with many around 1MB and one file closer to 5MB. I don’t know what the memory limit is, so I just threw a bunch of stuff at it.
Right now I’m using the 1.4.04 beta. Later this week I’ll be doing some larger/more complex jobs and I’ll see if the crashes are really solved or not.
I think a common symptom with errors on the Polar is related to the axis limits being a little awkward. The limits seem to get hit when the laser homes after running a job. The circumstances that affect this aren’t totally clear, but I think it’s more common if the job is already close to the work area’s edge.
It’s even more odd, because I can burn a line on the Y-0 edge, and it works fine. But if you burn a box, and it does the line near the Y-0 edge last, then it will hit the y axis limit error before completing the box. Obviously speed can affect how hard it hits that limit, but it’s easy enough to avoid the outer 3mm to avoid those errors.
I’ve seen mixed reports on this. It’s almost certainly either 128MB or 256MB. I suspect 128MB.
Just to check something, I grabbed a Grayscale image of a camera out of our docs here: Image Mode - LightBurn Software Documentation
Then I saved the LightBurn (lbrn2) file.
It’s showing as 206 KB
Saving it as an RD file makes the file 39 KB (ahh… it was set for passthrough)
Setting the Image for Stucki made the .rd file 9.5MB.
@KungFuJosh
If you’d like to know how much space the file might take on the controller you can load it as you had it in LightBurn and click File, then click Save RD file and check out the difference in file size. 
LightBurn says the file size when it sends the file to the laser, that’s how I know what sizes the files were that I mentioned.
My question is what the storage limit on the controller is.
This sounds like an mildly entertaining challenge. 
That’s total memory, not what’s available. There’s about 97.5MB available on my controller. I copied an image that was 37860.1 Kb twice. Then it said only 21780.0 Kb free when I tried a 3rd time.
The Chinese aren’t going to tell you any of the internals… you’re only option is to approximate it…
If it really cared, they would handle the software failure correctly and not just go into berserk mode.
Keep track of this, maybe you can figure out what it’s doing.
Good luck
With those 2 large files on the controller the rectangle test failed the first time the top line was within 3mm of the top edge of the work area. Hitting pause to continue sends the laser head in the wrong direction, then errors again, and LightBurn crashes. Laser needs to be power cycled to continue. This doesn’t happen every time though.
It seems the simple answer to avoid that situation is to not use the top 3mm of the work area. At 3.5mm no hard limit is triggered.
This is only what I assume is 1 of 2 problems. I’ll test the other crash issue when I run the larger tests.
This is interesting. I wonder if the controller returns a message LightBurn isn’t expecting and crashes from that.
It’s bizarre how storage can affect where a job fails.
Sure, but without repeatability or spending the time with a serial debugger, we’re going with correlation not causation. It may be a coincidence.
My guess is that when the laser hits an error (axis limit or whatever) and LightBurn is waiting for a response from the laser but doesn’t get one, that’s when LB becomes unresponsive and crashes.
If you’re willing… with your laser engraver connected and memory loaded as before,
Hopefully, this captures any code thrown by the controller.
Looking forward to the results of this test.
I’m happy to try this, but the Show all button won’t respond when I try to activate it. Is the debug log only in the console, or does it store a file somewhere?
Thanks,
Josh
I think it stores the log file in your Document directory.
