Bug: Luban does not finish loading STL on MacOS Sequoia 15.0.1 with Apple Silicon M3

[ITmaze]

🐞 bug report

When attempting to load an STL file, even the standard included ones, the loading starts and stops at different locations, depending on the mode and the model. It appears that you cannot complete the loading of any STL.

• On 3D printing, the vase loads 75% and stops
• On CNC, the chess pieces do not load, a standard benchy loads 12.5%, the cube.stl in the /Applications/Snapmaker Luban.app/Resources/app/resources/engine-test/cube.stl also loads 12.5%
• I can see the laser giftbox, but the preview is empty.
• I can see the CNC phone holder, but the preview is empty.

Affected Version(s)

• Version 4.13.0 (4.13.0)

To Reproduce

• Install Luban
• Launch Luban
• Configure machine
• Attempt to open a supplied model
• See failure

I also attempted to use "Help" -> "Reset Configurations" with the same results.

🌍 Your Environment

• MacBook Air, 13-inch, M3, 2024, 8GB RAM
• MacOS: Sequoia 15.0.1 (24A348)
• Printer: Snapmaker A350 with enclosure and 4th axis.

[ITmaze]

I raised this issue directly with Snapmaker Support who asked for the log file.

I've also attached the index.js file (though to send it, I've had to add a .txt extension) that the log refers to, since there's nothing quite like having the actual file to debug an issue.

  errno: -86,
  code: 'Unknown system error -86',
  syscall: 'spawn'

I note that this appears to be a known issue with node.js, indicating a mismatch between the binary architecture (of the file being spawned) and the system CPU architecture of the computer on which it's running.

It appears that the Electron development environment Snapmaker is using is not configured correctly to deal with the M3 CPU in my Machine.

Snapmaker Support indicated that the "workaround" was to install Rosetta, which is not a viable option in my system for reasons outside of the scope of this ticket, suffice to say, there is no "undo" from installing Rosetta, as far as I know, you cannot remove it after installing it.

The reason that installing Rosetta works, is that the bug caused by this mismatch is hidden because the binary will run fine on an emulated x86 machine which is what Rosetta does - unfortunately it doesn't actually fix the issue.

I suspect that this github issue is related:

• Building Apple Silicon (arm64 or universal) builds on Intel-based Mac electron-userland/electron-builder#5689

The files:

• index.js.txt
• luban.log

[ITmaze]

In response to a (for some reason not visible here) direct email from "@xiwai2" which stated:

Sorry, we are unable to analyze the problem based on the information you have provided. We hope you can contact our after-sales service to help you solve the problem.

I'd like to point out that I have been in touch with the Snapmaker support team (Ticket: 180620) throughout the past month. I have also provided the same logs to them as I have here. I have also confirmed that the bug persists with version 4.14.0 of Snapmaker Luban and version 15.1.1 of MacOS.

It occurred to me that if the person testing this bug is unable to reproduce it, they have Rosetta installed, which I do not. Snapmaker support appears to confirm this:

Our developers found that there is indeed a problem with the system after analysis.

It appears that the bug occurs because the electron-builder in use has not been properly configured to generate actual ARM binaries, which I've also pointed out to the Snapmaker support team.

Shy of me installing electron-builder on my own infrastructure, cloning the repository, I'm not sure what else is required to fix this bug.