1.4.0 Windows Crashes Every Time After Multi-Image

I was able to sort that out based on the earlier revelation about the grouped photos. I just wanted to be explicit in what I had done from the perspective of documenting for reproducibility purposes.

Now that I re-read I see we were saying the same thing :slight_smile:

Have you tried to clean up your PC/ Laptop by doing some housekeeping on it? If there is not enough spare space for the program and operating system to use it can crash program. Also, ensure that there is no large drain on graphics - like screen saver or wallpaper with massive graphics in it.

The issue is Lightburn not the PC. Still need to follow up on additional tests. Things are very busy this week. Will do so and get back and soon as I can.

2 posts were split to a new topic: Ruida, Connection issues after 1.4.00 update

So a single 142dpi image (organized the same way in a stack of images) using print and cut causes Lightburn to hang after every cut. This happens whether sending the file or starting from Lightburn. The only way to prevent the hang that I have found is to power cycle the laser after the cut before asking Lightburn to do anything. If you ask Lightburn to do anything at all before power cycling, it hangs every time.

How do I get more useful information that I can provide toward getting this bug fixed?

No support for this crash?

We’re patiently waiting on Error logs and Crash reports…
:slight_smile:
Help us Obi wan Kenobi - You’re our only hope.

I would also be very interested to know how much available storage is on your Ruida Controller (once you’ve deleted all the files of course).

1 Like

Thank you. I forgot about the crash logs. I will take care of those this evening.

It’s a Thunder Nova 35. We regularly delete all the files (and number of files has not had any observed relation to this crash). What else would take up storage on the controller? Where do I find available storage?

Hosted files and the overhead caused by “Bloaty” image formatting.
If you clear everything out of the controller you should have some information as to ‘available memory’

I will review your other posts to confirm that you shared the model number of the controller.

This may be helpful:

This is a Lightburn issue that Lightburn devs so far refuse to acknowledge. Happening all the time here.

No guidance has been offered in order to provide more useful information to resolve the crash.

It appears in my case this is in part due to devs taking a personal vendetta against me due to my pointing out massive failures in Lightburn interface design along with other bugs in behavior.

It wasn’t happening until the upgrade, which already tells us that.

Can I simply use the installer on a prior version to downgrade? Or what is the appropriate process?

False positives are very commonly reported due to other changes happening during the same period so good to narrow this down.

But to be clear, I was addressing the original poster on this as that was the reported behavior. It’s not clear to me or apparent that you’re facing the same issue but potentially worth exploring if you feel you’re in the same position.

I’ve never had a problem doing it this way but I could see it potentially being a problem. You could do a full uninstall first, preserving the prefs folder, to otherwise make sure that a full set of installation files have been replaced.

1 Like

What is the best way to determine the controller model number?

The best way is actually two-fold.

  1. From the HMI (screen / keypad) there’s a key sequence for controller info. This should yield the Model Number of the controller and the firmware revision number. It may also offer ‘available memory’ but I don’t want to get too greedy. The value of this information is in the idea that this is what the controller believes it is. There are examples of the incorrect firmware being flashed across model numbers to unlock rotary tool use.

  2. From the manufacturer’s label on the side or face of the controller. With this second more physically robust number we can confirm that the firmware does or does not match the controller.

I’m not expecting anything strange with the firmware. You asked for ‘Best’. That should be it.

RDC 8.07.70
HMI 7.4.82.03

I didn’t see a way to get it to report on available memory, but the menus are far from intuitive. Any suggestions where to look?

Not my expertise, but this text jumped out at me… “So a single 142dpi image (organized the same way in a stack of images) using print and cut causes Lightburn to hang after every cut. This happens whether sending the file or starting from Lightburn. The only way to prevent the hang that I have found is to power cycle the laser after the cut before asking Lightburn to do anything.”

This leads me to suspect Lightburn is waiting for the controller to respond with something. If LB queries the controller and gets no response, HANG is the obvious result. I expect the controller to be the issue because there is a boatload of Ruidas out there running just fine.

If Lightburn is waiting and doesn’t handle a timeout properly, that’s Lightburn’s fault. It doesn’t matter if the controller caused it, Lightburn should handle it appropriately and not crash.

Crashing is never acceptable. It is an implementation failure. Blaming it on the controller might be a starting point for figuring out how to fix it, but is never an excuse for why it crashes.

With UDP coms from the Ruida, I’d have to investigate further.

Yes, and I’m not certain that this is related to the cause.

Agreed on both points, LightBurn shouldn’t crash. We take this seriously and I look forward to reviewing the Crash logs and forwarding the files to the Dev team.

I went looking for the Crash Logs you offered and I didn’t see them in the support Email. I have responded to your support request email in an effort to accurately track progress on this.

2 Likes