As is, the Lasersaur I built comes with a very capable interface, but along with the hardware mods there were a few tweaks to the UI and machine behavior that I wanted to make. Unfortunately it seems that the original software repository is no longer being maintained, as there are some bugfix pull requests that have been sitting there for the better part of a year. I started with FREILab’s fork of the Lasersaur software, since they had already implemented a few of the changes I wanted to make, and forked that off into my own repository to make my changes.

There are still a few things that would be good to add, and some places where things aren’t working perfectly (mostly cross-platform compatibility). I have a list of those at the bottom of this post. My status here is “my setup is working so I may or may not ever get around to making these additional changes”, but pull requests are welcome!

Python 3 Port

The first order of business was actually getting the original code running as-is. However, the backend was written in Python 2, and in tracking down dependencies I needed, I found that some of them no longer had Python 2 versions available online. I’m not sure what build environment everyone else had when they got this running, but I wasn’t able to duplicate it. In lieu of trying to recreate missing function, porting this to a more modern supported codeline looked like it was going to be the easiest way to get things done.

Luckily the port to Python 3 was fairly straightforward, though there were some subtle changes to reading and writing serial data from the Arduino that got me stuck for a while. All the functionality is working right now (at least on Windows), and the build environment got a good bit easier – simply clone the repo, install WinPython, then run pip install -r deploy/requirements.txt.

Quality of Life Improvements

Compared to the original nortd repository, this fork has quite a few quality-of-life improvements.

• You can now jog in 1 mm increments by holding the ctrl key with the arrows (added by FREILab)
• Your current X-Y coordinates are shown on screen (added by FREILab)
• “Set Offset” now sets the offset to the current head position (added by FREILab)
• The head position is now set in relative rather than absolute dx, dy coordinates (added by FREILab)
• Faster raster and fill engraving (details below)
• The debug terminal can now be resized, scroll, and will not auto-jump to the bottom of the window if lines print after you scroll up
• Functions to print out human-readable versions of the transmitted and received serial commands were added to the source (disabled by default)
• The head will auto-home when the interface is first started (user-configurable)

Raster and Fill Engraving Speedups

The main reason I wanted to dig into the software in the first place is that the raster and fill engraving modes are infuriatingly slow by default. They scan down line-by-line, engraving on the forward left-to-right pass, and then scroll in reverse all the way back to the left side to make a forward engraving pass of the next line. The backwards pass that wasn’t being engraved was completely wasted machine time, and at a pixel size of 0.2 mm, a feedrate of 4000 mm/min, and no lead-in, filling the lasersaur test image takes 4 minutes to complete. (Side note – for fills, I have noticed no benefits to setting a lead-in distance).

So, I created a new user-selectable mode for raster and fill engraving, which is to simply engrave on the backwards pass as well as the forward pass. Switching to this “Bidirectional” mode brings the time down to 2 and a half minutes.

In addition to that, I put together another mode for fills (not rasters). When the path planner finishes engraving a line, it looks at the endpoints of all the other unengraved lines, and chooses the nearest one to start etching. This “NearestNeighbor” mode shaves another few seconds off from the Bidirectional mode, even though in the video below you can see that it’s not a strictly optimal solution.

NearestNeighbor happens to perform better than Bidirectional for the Lasersaur test image, but whether or not that holds true depends on the shape being engraved. In general, dense, complex shapes will be faster with Bidirectional, while simpler, wide shapes will go faster with NearestNeighbor.

Fill Engraving Mode	Time to Complete
Forward	4:01
Bidirectional	2:33
NearestNeighbor	2:27

Known Issues and Future Improvements

There are a couple known issues with the code right now, and a couple things I think would be universally useful as future improvements. Again, feel free to contribute these changes and I’ll merge them in!

Known issues:

• Loading up raster image files in Chrome fails (works in Firefox, haven’t tested anything else). Fixed 12/1/19 with move to Python 3.8!
• Building a Windows executable isn’t currently working.
• Documentation needs to be updated.
• I have not tested this on Mac or Linux.
• The air assist valve remains open in some early-shutdown scenarios even after a power cycle.

Future Improvements:

• Calculate a time estimate for how long a job will take / how long is remaining in the job.
• Make the “red dot marker” in the web interface snappier.
• Make the fill UI better (button to delete fill, allow changing of pixel size).
• Allow jogging the head away from the magnetic stops (force 1mm steps in case axes are misaligned?)
• Add a UI button to pulse the laser. This will require updating the firmware to implement a “dwell” command, which might be difficult since currently the laser power is tied to stepper movement. Done 12/22/2020!
• Add “reverse” option to raster and fills. Done 12/1/19!
• Calculate and skip over right and left whitespace in raster images, so successive passes don’t go to the edge of the bounding box if not needed. Done 12/1/19! Also skips over large interior whitespace, gives a pretty nice speedup to sparse raster images.