There is no official support for Linux for this LASER, but I wanted to use it with some scriptable projects so I've developed this package and a cli tool to bridge that gap in a way that meets my needs. See the References section below for a gui alternative.
Before using this tool, and the Omni 1 in general, do yourself a favor and watch this highly accessible video. Or this shorter, drier, video. All tools are potentially dangerous. A LASER like this definitely is.
Be sure to wear 355nm UV protecting LASER eye protection whenever the LASER is powered on.
Build and kick the tires (no LASER activity from this first example):
$ git clone https://github.com/tinkerator/glase.git
$ cd glase
$ go build examples/glase.go
$ ./glase --info
To get started, assuming you have the 150mm lense installed in your
device (this was the default when I received mine), you also need to
copy the jcz150.cor file to your working directory and rename it
local.fixup.cor. (Creating a new file instead is covered in the
Recalibrating section below.)
- My device is
mfg="BJJCZ" product="USBLMCV4" ..., so I won't be surprised if a different device misbehaves. - If you are fortunate enough to have more than one of these devices,
you can specify
--serial=<xxx>on the command line to operate on a specific one.
- If this fails with an error about
libusb-1.0not being found, try one of the following and then thego build examples/glase.gocommand again:- Debian:
sudo apt install libusb-1.0-0-dev pkg-config - Fedora:
sudo dnf install libusb1-devel pkgconfig-pkg-config
- Debian:
- The first time you run this, you will likely get a
bad access [code -3]error.- To resolve that, create the following file with
sudo nano /etc/udev/rules.d/99-omni1.rules, with this content:
- To resolve that, create the following file with
# This rule was added for the ComMarker Omni 1 5W UV LASER device.
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="9588", ATTRS{idProduct}=="9899", MODE="0666"
- Then, to refresh the rules, run
sudo udevadm control --reload-rulesand alsosudo udevadm trigger.
The examples/glase.go tool can be used to make a LASER caution sign. I used
the following commands:
$ go build examples/glase.go
$ ./glase --burn-speed 1000 --hatch .2 --laser --size 30 --x -40 --burn
$ ./glase --burn-speed 1000 --hatch .2 --banner "CLASS 4" --size 20 --x 30 --y 10 --burn
$ ./glase --burn-speed 1000 --hatch .2 --banner "(355nm UV)" --size 15 --x 30 --y -5 --burn
$ ./glase --burn-speed 1000 --hatch .2 --banner "! CAUTION !" --size 35 --y 30 --burn
$ ./glase --burn-speed 1000 --hatch .2 --banner "LASER ACTIVE" --size 35 --y -30 --burn
On an acrylic sheet using my system, the result looks like this:
The LASER is shipped with a copy of EZCad2 Windows software on a USB
stick. My Omni 1 arrived with the 150mm lens mounted on the LASER. The
USB stick had a file jcz150.cor on it that was the distortion
correction file for my LASER. It seemed to mostly work fine (--cor jcz150.cor). But I found it generated a non-square coordinate pattern
at the left edge of its 15cm range. After teaching the glase package
to consume this file format and upload it to the LASER, I followed the
following strategy to generate a new local.fixup.cor file for my
specific LASER.
This is the procedure I followed:
I placed a transparency sheet (the type you can use with a LASER printer) flat on the work surface of the machine and adjusted its z-height to match what the factory said was the focal point of the LASER.
I then burned a barrel distorted calibration grid with default parameters over this sheet (without any correction data applied):
$ ./glase --cor "" --burn --calibrate
The grid spacing generated by the --calibrate flag is 1000 galvo
units of distance (with 64 squares, this is a total galvo unit range
of 64000). For the official height of focus of my LASER this 1000 unit
distance burned marks on the transparency sheet close to 1/10th of an
inch (or 2.5mm). So, I derived a correction file that forces exactly
this normalization. That is, 1000 galvo units is, by definition,
2.5mm.
Next, by examining the outer 4 corners of the grid, its center point
and the central point of each of the 4 sides you can capture
information needed to make the grid rectangular. That is details about
these 9 points can be used to generate a new .cor file. To do this,
create a local.fixup file with information about how much each of
these 9 points deviated from its ideal point. For example, I took the
center point (0,0) in galvo units to be the true mm center of the
LASER's range. Further, the outer edge centers appeared to be aligned
well with this center point to generate a convenient perpendicular
cross. From the center, however, they just weren't exactly 8cm in
length. Finally, I looked at how the outer 4 corners of the grid
deviated from the (+/-8cm,+/-8cm) positions I wanted. I corrected for
all this with these 9 lines in the .fixup file (if you repeat this
exercise with your LASER, you may get different numbers):
0 0 0 0
-32 0 -2 0
32 0 2.5 0
0 -32 0 -2.5
0 32 0 3.5
-32 -32 2 -4
-32 32 1.5 5
32 32 0 5.5
32 -32 -2 -4
Each line of this file is of the following form: xGrid/1000,
yGrid/1000, mmXWrong, mmYWrong. That is the mm*Wrong values
capture how wrong the rendered crossing point is in mm. So, if a
rendered point is a little to the right, its mmXWrong value is
positive by that many millimeters. To be very clear about orientation,
in the conventions glase uses, the smallest (most negative) Y values
are closest to the front of the machine - the edge that features the
red emergency stop button. Left (negative X) and right (positive X)
are as viewed from this front of the machine.
The first line of this file says no correction is needed for the origin point (0mm,0mm). The next two lines say no Y correction is needed, but the rendered (-8cm,8cm) X-axis line, without correction, is observed to be 4.5mm (or 2.5-(-2) mm) too long. Similarly, the rendered (-8cm,8cm) Y axis line is 6mm too long. It took a few attempts to get the remaining 4 point corrections to generate a correct 2.5mm grid. Indeed, for my LASER, the bottom corner points seemed to resist rendering as (+/-8cm,-8cm) points. This is, I presume, the reason the ComMarker writeup asserts the LASER only has a 15cm range.
To create a custom local.fixup.cor file from this data, do this:
$ ./glase --cor local.fixup --regen --sim
- The meat of the generated
local.fixup.corfile's content starts at byte offset 36. The bytes before that are not important to theglasepackage, and other than theJCZ_COR_2_1magic, are mostly filled with nonsense bytes. I have no idea if the generated file will work with the EZCad2 software. I don't intend to bother trying that.
The ./glase tool can operate directly with an ASCII .fixup file
(omit the --regen argument), or a .cor file. It defaults to
looking for a local.fixup.cor file in the working directory. So, if
you want to use the jcz150.cor file you received with your machine,
supply that info explcitly on the command line as --cor jcz150.cor,
or make a local copy of that file with the local.fixup.cor name.
- The development of this code was inspired by this post and benefited greatly from that pioneering work, Balor.
- The excellent meerk40t successor to Balor.
- Also galvoplotter.
The glase package is distributed with the same BSD 3-clause
license as that used by
golang itself.
This is a hobby project, so I can't guarantee a fix, but do use the
github glase bug
tracker.
