2 more bugs in Snapmakerjs for laser

2 more minor bugs.

  1. When previewing a greyscale image with a pure white background (created/verified with Photoshop), SnapmakerJS will put dots in the background. Turning the White Clip down will make these go away, but also effects the image. If you run with this, the laser will draw dots there. The different algorithms handle it differently (but they all fill the background with dots), but a white level of 255 should be white at a clip of 255.

56 AM

  1. During printing via serial, the laser intensity increased without changing the settings.(change starting at nose - you can see the darker area that started at that pass)


Settings for SnapmakerJS:
59 PM17 PM


1 Like

Thanks for informative report!

  1. https://en.wikipedia.org/wiki/Dither . Dithering algorithm works as error diffusion. If the background is not totally white, the error will gather to dots. In theory, If white clip can make the dot go away, that means the background is not totally white. Could you provide the origin image, so I can verify it.

  2. Snapmakerjs’s gcode sending has a bug. Which I have solved. And testing it. You can expect a new release of Snapmakerjs in a few days after more tests. But it can only expalin from darker to lighter but not the reverse. So I still have no clue yet, failed to come up a guess. Could you export gcode to SD card and test it again. Let’s rule out the problem from hardware flaw first. If SD card printing works fine, then it definitely is Snapmakerjs’s fault.

1 Like

2 images that had the same issue:


I also tried it with transparent background to the same result.

  1. export to SD card and laser - I get NO image burned. Haven’t tested that one enough yet for your bug report - stay tuned.


perhaps a user available filter (ie: mostly 95% white --> 100% white)…

many of the image and high end cad packages have such a rendering filter…

this would allow “perfect” prints, from “non-perfect” original art-work…

back in my “tru2life.color.printing” days (1992), sublimation rendering software had such…

real world results count more than formula specifications…

(most inputs will not be pure from “best case” software, but copies from the real physical world, where phone cameras, copy machines, hand sketches, and such ARE the original art work, and expectations are the “magic” software outputs…)

The more “magic” you allow presented to the customer base, the more your product will be loved…

You WANT non-engineers to use and love your product…

They out number us tech nerds greatly…


Thanks again for informative report.

  1. I have figured out why.
    var grey = parseInt(0.2126 * this.bitmap.data[idx] + 0.7152 * this.bitmap.data[idx+1] + 0.0722 * this.bitmap.data[idx+2], 10); . A code-snippet from the image process library that I used Jimp. You see this is a float point calculation. color #FFFFFF -> #FEFEFE. I didn’t notice this before. Thanks again for report this. But I think I gonna let it go. Since this error won’t affect result much. You can set white clip to reduce dots dramatically. And dots is unavoidable. Below is the result that I remove extra greyscale transform which causes the problem.

@william.o.yates . I use 1-255 instead of percentage is to avoid float calculation. Which I argued with my teammate before. @Noah express the same idea like you say. ^ ^. Open to discussion. We might change it, if it makes user confused.

  1. A tis: Focus using software and save power to motherboard. https://manual.snapmaker.com/laser_engraving/set_the_laser_power_and_choose_a_way_to_engrave.html
    or It will use the default power(the power you set before, ), initial power is small.

ok - for the focus (detached) laser burning - I set the origin, focus and power with the software and saved. Started the engraving job from the SD card, and it started working. (YAY!) Then I closed the software, the laser engraving stopped, and zero was set to the current location of the laser.

I did it all again, but disconnected the serial before starting the engraving from the SD card, and it is working.

So - Bug? desired (or expected) function? - either way, the manual should probably be updated.

Also - there does not appear to be a way to set the origin and focus standalone. That would be a nice feature.


ok - print finished via SD card load. Looks perfect. Also, it only took 3 hours for the greyscale to print, instead of 7-8. So there does appear to be a serial sending issue.


Reimplement GCode-sender to avoid message duplication. and buffer overflow Snapmakerjs 2.1.1

Online printing, as the time goes darker-> lighter. This might be caused by the old bad implememtation of gcode-sender.

Yes, it’s expected result, but it’s compromise decision made before.
It’s the mechanism behind the scene is that ardunio need to use USB to upgrade motherboard. That demand USB connecton to restart motherboard.

We develop a new bootstrap program, so that we don’t need USB to upgrade firmware. So we change the hardware to prevent restart while USB connected. I am sorry to tell that it includes hardware change. So beta snapmaker can’t get this upgrade.

  1. I have repeated your print. The printing time did differ. Because the serial data transfer rate is far slower. SD card printing is faster. But the printing time difference I get is about 10%-20% difference.