From Make717 Wiki
Jump to navigation Jump to search

LaserCube is a creative repurposing of a Cube 3D printer.[edit | edit source]

The Cube 3D failed at its intended job, but its internals are solid and with some new parts, it has been reborn as a solid-state laser engraver. It is now a compact laser that can be transported offsite for public events. It has full safety features and ventilation, and is sized to fit the Make717 tricycle. A full educational program is being developed around LaserCube, to support STEM.

Michael conceived the project and Nate is providing Linux advice and support.

Now that the laser is operational, we would like to train a team of operators so that the laser can be manned at public events. It will require special training in addition to the usual laser qualification.


  • 2W 445nm blue laser
  • Working area X=155mm, Y=135mm.
  • The LaserCube can cut at speeds up to 600mm/min, rapids at 800mm/min.
  • Cutting range 20-100% power.
  • 75mm focal length.
  • GRBL core, ver 0.9j on Arduino Uno
  • Raspberry Pi 2 host running Debian, serving XYZBots GRBLWeb control interface.
  • HTML5 Client.

Speed and Feed[edit | edit source]

This table also serves as the Approved Materials List. If it isn't on this list, you can't cut it!

Material Cut Grave Power Speed Notes
Paper 20 lb x 100 600 Max speed of the machine.
Paper 20 lb x 100 550 Under glass platen.
Card Stock x 100 50
Card Stock x 20 300 Vector engrave.
Cardboard x 100 50 2-pass may be needed.
Whiteboard x 100 600 Vector engrave.
Slate x 100 50 Vector engrave.
Baltic Birch Ply x 100 600 Vector engrave.
Baltic Birch Ply .0625 x 100 200 3-pass
Basswood .0625 x 100 200 3-pass
Anodized Aluminum x 100 500 Vector engrave.

BUILD LOG[edit | edit source]

Components (as built)[edit | edit source]

  • GRBL 0.9j on an Arduino Uno.
  • Raspberry Pi 2 hosts the user interface so any HTML5-compatible browser can control the machine.
  • Chinese solid-state laser module and controller. Provides 2 watts of 445nm radiation, enough to engrave anodized aluminum, wood and slate. Can cut paper, thin wood, and some plastics.
  • External power supplies - 5V and 24V and 12V.
  • An enclosure to attenuate laser radiation and guard the cutting beam. Equipped with ventilation and air assist.
  • Fixturing so that small projects can be processed with efficiency.

10 August 2016[edit | edit source]

  • The Cube has been stripped of unnecessary components: motherboard, power supply, fans, extruder and the Z-axis motor.
  • The Z-axis has been converted to manual operation with a slip clutch, because the laser needs to be focused but doesn't need to move during engraving/cutting.
  • Laser is on order, delivery expected 12 August, more or less.
  • Lasersaur DriveBoard has arrived and Bruce is populating it with components from his stash. Some assembly required, as they say, and there will be a pile o' parts that need to be ordered from Mouser.

16 August 16[edit | edit source]

  • Replaced the wound spring in the slip clutch with Belleville washers, which gives it a consistent feel in both directions and less hysteresis. The action is much stiffer, and could probably use a bigger knob to reduce the perceived force during adjustment.
  • Bruce is ordering components from Mouser.
  • Lasersaur offers an optional use of Nanotec SMC11 drivers, which cost a lot less than the Gecko drivers. If only NORTD provided some documentation on the proper configuration of the board... let's assume that we won't need headers for the Gecko drives, nor the current setting resistors. You shouldn't have to resort to the schematic to figure out what is supposed to be populated on the board; that's what a user manual is for. The SMC11 calls out a 47K charging capacitor to throttle back EMF. There is no place to mount them, though.

20 August 16[edit | edit source]

One of the goals of this project is to compare a Lasersaur DriveBoard to a SmoothieBoard. Looks like Lasersaur has already lost on cost/convenience. The standard configuration calls for Gecko G201x drivers. They run about $130 each, so a 3-axis DriverBoard already costs $400 more than a Smoothie, which comes with drivers built in. The alternate DriverBoard build uses Nanotec SMC11 drivers, $39 each, which you and I cannot buy, because Nanotec will not sell to individuals. Really. Their ordering page has a checkbox that certifies that "I am not an individual". We might appeal that policy, but Nanotec does not take emails from individuals. So while Make717 can buy the part, no hobbyist may. Either way, Smoothie wins, on price or convenience.

  • The laser arrived, and its drive circuit is mounted to the cube. The laser mount is designed and needs someone to mill it.
  • Ordered honeycomb for the bed, 6x6x1. The intention is to replace the Cube glass build plate with a more appropriate material.
  • Also sourced a ventilation fan and charcoal filter, and buying that combination put us on a watch list for marijuana growers. We were probably tagged as terrorists when make717 adopted Telegram, anyway.

25 August 16[edit | edit source]

  • The laser bracket is done. It could use some minor improvements, which perhaps will happen before the project ends. Mostly, aluminum angle is not square nor uniform in cross-section, making for a visually unappealing bracket.
  • All power supplies have arrived. They will fit neatly under the Cube. The enclosure needs to be designed.
  • Still missing Nanotec drivers - they haven't responded to Bruce yet. Mouser has not shipped the solid state relays that drive Estop and air assist. The exhaust fan should be delivered soon.
  • The honeycomb arrived, it needs to be backed and cased. This is bandsaw and metal brake work.
  • The only electrical items left are the CAT6 cable for hookup, and some 18Ga wire for power supplies. And an air assist pump.
  • The nozzle for air assist is designed. It will be 3D printed and press fit to the focusing ring.

30 August 16[edit | edit source]

  • The new laser bracket is in place. Much better. Still a bit off center, because its hard to guess the designers intent when you are pulling dimensions off an existing part with hand tools; all the parts seem to fall on conventional imperial units (1/4", 1/2", etc.) but all the fasteners are metric. So I chose a .250 centerline but it looks like it ought to be .255 or .260. Maybe in the next life...
  • The air assist nozzle was printed on our Flash Forge, and works as intended. It is powered by a Coralife Super Luft pump, from our local fish place (yes, That Fish Place).
  • Honeycomb is cased and ready to mount. The lazy way would be to stick it to the glass build plate with foam tape. The ideal way would be to carve a hunk of steel to fit the magnetic base of the Cube. I'm feeling lazy. So maybe that calls for a day or two of contemplation.
  • Bruce did a fabulous job tracking down Nanotec drivers and mounting them to the DriverBoard. Looks like everything is in place and ready for connection to the hardware bits. The wiring is based on Cat5 cables, which should arrive next week.
  • Speaking of hardware, all the auxiliaries have arrived. As soon as the enclosure is cut, we may tally the cost of this adventure. Looks like a laser - any laser - falls into the $500-$1000 range. Next one will be bigger, so it's more cost effective. This one is supposed to be space effective for traveling laser demos.

Time to start design work on the enclosure. There are three design goals:

  • Mount all the components in a compact envelope.
  • Provide easy access to the work space and less easy access for maintenance.
  • Protect the user from the laser, and the laser from the user.

2 Sept 16[edit | edit source]

The "final" electrical parts arrived and 80% of the laser cube is wired. Why 80%? because the power supplies are discreet wiring and they're not mounted yet. Also, getting non-standard wires into CAT5e connectors turned out to be fraught with peril. So we'll need a few more of those.

As for the enclosure, how's this for an idea? A tube into which the Cube fits, with all the exotic electronics mounted to the outside and covered with acrylic. Bright yellow. With a view port in the door.

There are now 2 projects intended for public use of the LaserCube. One is a disk shooter, using recycled cardboard and 1/8" ply. The other is a bookmark, in the user's choice of Chameleon, Lizard, Clownfish or Cat. The LaserCube should be able to engrave the flashlights, too.

11 Sept 16[edit | edit source]

All internal wiring is done. Time to mount the DriverBoard and wire the power supplies. LCD has been replaced with an acrylic panel, since there's nothing to drive an LCD.

13 Sept 16[edit | edit source]

The case pretty much designed itself. Everything was laid out in SolidWorks, then laser cut from whiteboard material. It has a clean white finish, and can be used as a message board in a pinch. The panels are held together with 1/4-20 threaded rod, nicely capped with acorn nuts.

Of course, nothing ever is simple; the design called for 1/4" Masonite, and after it was cut it was apparent that the whiteboard is 3/16" thick. That required a second trip to Lowes so the panels could be re-cut.

25 Sept 16[edit | edit source]

Trial assembly proved that the bottom of the case needed reinforcement due to the weight of laser. That's done. But it also suggests that the Cube might best be mounted in the case through the side panels, because that would relieve some of the weight on the bottom.

It needs a door and related hardware. There is a minor symmetry issue in the front and rear panels, so they could be re-cut. Maybe after any other deficiencies in the design appear.

Ventilation is attached to the case by way of a quick-release mechanism. That way the machine can be broken down for travel. That's where you'll notice the asymmetry; the idiot designer forgot to relate the holes to the center line of the case.

The DriveBoard is mounted. Socket head mounting screws inside the case interfere with the homing routine, so they will need to be replaced with flat heads.

Power supplies are mounted and ready to wire. There needs to be a pair of AC outlets for the auxiliaries. The air assist pump and the ventilator plug into 120V and have no off switch, so it makes sense to switch AC through the DriveBoard.

The resulting machine is very steam punk. Phil has a pile of gears, maybe we'll throw some on "chust for pretty". Because form really doesn't need to follow function.

27 Sept 16[edit | edit source]

Power supplies are wired. Motors are cabled. The air assist is screwed to the side opposite the power supplies. Hoses are in place. All the little adjustments that needed to be made are done. The cube is mounted in its case. It's time to deal with the front door. That will take care of containing the laser radiation, and mounting the door interlocks.

Bruce is digging up AC outlets for the auxiliaries. The ventilation needs some stove pipe bashing.

One more day?

2 Oct 16[edit | edit source]

The front and back panels were remade, which fixed some problems but created some new ones. Humidity makes a huge difference in fit when cutting white board Masonite. The switched AC panel is mounted, and an SSR to control it if needed. Can DriveBoard handle the switching by itself? It does have a 25A SSR onboard, and terminals rates at 10A max. If only we had some documentation!

That leaves the door (still) and the guards to design and install. The door is laid out, but won't be cut until the hinges are printed and tested. The guards mount the power entry module (PEM) that supplies the entire system. To finish all this detail work, magnets are needed for the door and standoffs for the guards, both of which are somewhere in the junk pile.

Ventilation is in place. The quick connect works as intended. The unit stands 15 inches when knocked down, and 30 when erected. The make717 trike has a box 22 inches deep, so the laser should fit. Because the laser has two pieces now, it should have a carrier to organize them. And maybe carry some tools.

7 Oct 16[edit | edit source]

The DO list is getting very short:

  • Still need plastic for the door, but the MakerBot keeps pooping out on the print.
  • Applied power for the first time. It would be nice to say that everything works as expected, but no. The BeagleBone did not power up. Everything else did. Including the laser. Surprise! So there is some troubleshooting to do. Emergency stop is functional, so let's assume the DriveBoard is working and it just needs some configuring, both mechanical and firmware-wise.
  • Should put some kind of overload protection in the AC circuit. Why isn't there a fuse or breaker in the design?
  • Bruce trotted out some LED tube lights, and one will go inside the case.
  • It would be a good idea to bump the case out one inch front-to-back. The honeycomb touches the case at home, and at 5.75". By expanding the case, the laser should be able to travel an honest six inches. And there will be room for fixtures that index on the outer frame of the honeycomb. So there are six case parts that need to be re-cut, and eight threaded rods.
  • There are light leaks that need to be addressed. Maybe with 3D printed plugs.

8 Oct 16[edit | edit source]

Spent a lovely evening wrestling with stupid. Adjusted the 5V power to spec. The BeagleBone doesn't care. The power LED lights, but no boot. In the [sparse] notes for DriverBoard building, there is a modification for the reset pin to the atmega. Since there were no other obvious faults with the build, why not apply it? 30 minutes and no joy. Now the obvious culprit would be a fault in the other DriveBoard connections, since BeagleBone is touchy about power levels at boot time. If you look at the pictures in the LaserSaur manual, they don't install full headers for the BeagelBone. Instead, they use four 4-pin headers. Why not? Desoldering 88 pins is an act of sheer masochism. And pointless; the BeagleBone still won't boot.

10 Oct 16[edit | edit source]

Removed the atmega from the DriveBoard. Success! BeagleBone wakes right up. So maybe, maybe, maybe the mega needs a jumper on auto-reset. Nope. But if the BeagleBone is drawing power from the USB port (it was), and the auto-reset jumper is in place, LaserSaur can flash the atmega, which is now done. And then the repercussions of progress:

  • The steppers grind as soon as power is applied. That's a wiring problem. Maybe a configuration problem, too.
  • The steppers are active even though the BeagleBone is not functional. That's poor form for a "safe" device.
  • With the firmware now active, the laser still turns on as soon as the Estop is reset. Is that a configuration problem, or is the laser controller not functioning as expected? It's another undocumented component. Its one-sheet setup shows 12V 2A power to the board, and a connection at a plug marked TTL. TTL should be 0-5V PWM, with 0V turning the laser OFF. So if we pull the TTL cable, no laser, right? Wrong. But if we short the TTL pins, the laser turns off. This suggests that TTL floats at 5V, a bad default. Still if we configure the DriveBoard to pull it to ground, it should work just fine.
  • All of this is just wasted time, because the BeagleBoard died. It gives one sad flash when power is applied, then nothing. Probably from a short while probing the connections. That's the only reasonable explanation, gleaned from the internet. Easy to do, impossible to fix.

So everything comes to a halt while a new BeagleBone is delivered. Meanwhile, there's plastic to mount...

17 Oct 16[edit | edit source]

Some pictures while we wait for a new BeagleBone.

20 Oct 16 AM[edit | edit source]

The LaserCube is taking its baby steps. At this point, it is wired. Schematics need to be updated accordingly.


  • The BeagleBone White was not a good fit with the current DriveBoard. Black works without any fuss.
  • The Nanotec SMC11 stepper drivers apparently are not worth the effort required to secure them. Chinese units off eBay cost about the same, and run out of the box, no problems. The spec sheet for the motors calls for 12V, .4A per winding. We are driving them at 24V, which is fine as long as the current rating is not exceeded. The lowest setting on the new drivers is .5A per winding, but the motors aren’t complaining. The Chinese drivers are not pin-compatible with the Gekko drivers designed into the board, but cabling them off-board solved that problem.
  • The laser control is hinky. It calls for 0-5V PWM on the trigger pins. WHITE is 0-5V and BLUE is return. Unplug that, and the laser turns on.
    • The DriveBoard offers a connector with the following pinout:
    • Pin 1 - 5V
    • Pin 2 - WP, which is connected to the interlocks. This is the theoretical safety circuit, disabling the laser on Estop or Door events.
    • Pin 3 - 5V connected to Pin 1.
    • Pin 4 - TH, connected to PWM on Arduino pin D6.
    • Pin 5 - AUX, connected to PWM on Arduino D5. D5 has a breakout pin on the DriveBoard, and shares its ground with some kind of crystal circuit. I assume this is the clock for the Arduino. The LaserSaur manual says don’t wire this to the laser. Opinions?
    • Pin 6 - WP connected to Pin 2.
    • Pin 7 - GND
    • Pin 8 - GND connected to Pin 7.
  • What should work is Pin 6 => Blue, Pin 4 => White. This assumes that the PWM circuit sources 5V and that the interlocks pull the signal to ground. In this configuration, the laser does not fire when asked. It does fire once during homing. Is that because the limit event happened? If that’s what allows the laser to fire, the logic needs to be inverted or ignored.
  • The axes need to be configured for steps/mm.
  • Somewhere soft limits need to be set. Each axis should do 152.4mm. Homing offsets the axes by 5mm, so subtract that from the total allowed movement.

The laser has been focused. It has teethed on scrap paper. It has an impressive useful range - a very parallel beam. A little slow, maybe, but it is just 2 watts. Should have the vent and air assist turned on before anybody does a lot of burning.

20 Oct 16 PM[edit | edit source]

The new case parts are finished. The case could be closed if the laser trigger worked. Fires briefly on power up, and during X-axis home. Then nothing.

Also, even after configuring the motors, they don't work as expected. They home briskly, but do not respond to move commands. And the controller complains that the specified moves are out of bounds. No, not a limit hit. Before moving, it advises that the moves are constrained to the work area. Neat, if there were some way of defining the work area.

Turned this over to Nate for configuration.

25 Oct 16[edit | edit source]

Rigged a tell-tale to the laser driver. One LED connected to the interlock, which lights when the laser is disabled. One LED to the TH line, which should light when the laser is triggered. The results are interesting.

The disable light behaves thusly:.

Action State
Power On OFF
Door Closed OFF
Door Open ON
Homing OFF
Home switch triggered ON
Offset seek OFF
Motion OFF
Limit plug pulled ON
Chiller plug pulled ON

This suggests that all the limit switches are functioning, and the interlock circuit is good. Given that, and the fact that the motors can home at all, is prima facie proof that the motors are correctly wired and configured. So why no jog or move? More importantly, why no trigger on TH?

Time to consult the user group.

30 Oct 16[edit | edit source]

Several users offered suggestions, and finally a new front end app, DriveBoardApp. It looks good, but won't update the firmware. Many hours of tinkering, and still no closer to running the laser.

31 Oct 16[edit | edit source]

Sometimes, you just have to start over.

After a morning of no results, the SSD card was reformatted and reloaded with the LaserSaur files. This gives the project fresh Ubuntu, LasaurApp, Driveboard firmware. Some configuring was required, and that was done through SSH. Lasaur comes up on connecting to the BeagleBone, and it compiles and flashes firmware as it should.

And the laser fires. When it should.

That leaves a pile of minor housekeeping issues:

  • Close up the Cube case.
  • Knurl the Z axis knob.
  • Wire the lights inside the case.
  • Decide whether the auxiliaries should be switched, or run as soon as power is supplied.
  • Calibrate X and Y so squares are, and circles look like circles, not jellybeans.
  • Get soft limits in place.
  • Replace the busted guard on the a panel.

And some future improvements:

  • Move to DriveBoardApp when that's working properly. Better interface, more troubleshooting support, easier to configure - all good things.
  • Document the final configuration, so it can be maintained.
  • Establish feed and speed charts.
  • Build some fixtures for the traveling projects.


2 Nov 16[edit | edit source]

Last look at the LaserSaur configuration.

3 Nov 16[edit | edit source]

After a very hostile response from the LaserSaur forum regarding configuration issues, it became obvious that LaserSaur is a dead end. Make 717 has a smoothieBoard so, problem solved.

It took 10 hours to rewire the system and configure(!) it for operation. After 10 hours, smoothie was at least as functional as the LaserSaur, which had had the benefit of 6 days of tinkering.

Using Pronterface as a frontend. Not a great fit, really a frontend for 3D printers.

5 Nov 16[edit | edit source]

Downloaded and installed bCNC, the recommended interface for lasers. Better fit than Pronterface, but still more general than a laser controller should be.

Interlocks and emergency stop wired. The interlock cuts 12V power and leaves everything else working. Emergency stop kills 12V and 24V, so the laser and motors are disabled. 5V is left running for logic. That does leave smoothie running, so you might cycle estop and find the motors still moving.

That was a problem with Lasersaur, too. Is there a reasonable way to deal with it? Killing 5V at the smoothie causes a bad shutdown that hashes the startup routine. There is a kill switch, and suggests that it be connected to the Estop, but there’s a catch: if it is active when you boot, flashing firmware fouls up. And if you leave it activated for 2 seconds, it deactivates itself (according to the documentation). Looks like a mismatch between intention and implementation.

So, the short list:

  • Home switches, need to get them working.
  • Homing routine is futzed. Needs to home X to min, Y to max. Offsets need to be established, and activated.
  • Acceleration and max speeds need to be configured.
  • Some sort of limiting needs to be implemented to protect against damage to the tooling.
  • Test laser function.
  • Label wiring.
  • Manual, schematics, warning labels.
  • Training.
  • A dedicated computer or a web-based interface.
  • Adapted projects and fixturing as needed.
  • Speed and Feed charts.
  • GCode generator - maybe a plugin for Inkscape.
  • Fire extinguisher.

6 Nov 16[edit | edit source]

The laser spent the day at Barnes & Noble Mini Maker Faire. That allowed some time to tinker with the laser firing circuit.

These issues were uncovered:

  • The PWM pin connected to TH is unresponsive. Is this a software issue? firmware? wiring?
  • Rigging an idiot light to the PWM pin verifies no signal on the pin. PWM ignores G1, S, M3. Also ignores fire ### and fire stop. Yes the laser section of config is set to true.
  • Loaded a 1x1" square gCode file. On first run, it makes a 1x1" cut. On subsequent runs, the "square" is 2" wide and 1" high. Odd. Re-ran config, and that seems to have settled it down.
  • If the Mac host goes to sleep, it hoses up bCNC - can't reconnect, can't reboot the Smoothie. Requires a full stop of the system, including unmounting the SD card, unplugging USB, rebooting LaserCube, killing Python (bCNC won't shut down from the interface).

Further experience reinforces the suspicion that bCNC is not the right interface. Next candidate: VisiCut.

7 Nov 16[edit | edit source]


smoothie has a web interface. But it needs to be connected to a network. With auto addressing on, the smoothie is invisible to the DNS server. Just manually configure it, right? That would require a MAC address. How do you read the MAC address? hook it to the network. Or a serial terminal. Is there a serial terminal for OSX? not one that runs out of the box. Who has time to compile and install source code?

There is an improved web interface, which might be useful if it had a functional website from which to download the files.

How about an interface that can talk over USB? VisiCut looks good, but has a few shortcomings. Like no driver for smoothie. They claim they have one, but it's not accessible on the site or in the download package. Oops! Plus it wants to meticulously define materials and machines for a fab shop, which is nonsense if the laser won't fire. Next candidate...

GCode plugin for Inkscape? Does Inkscape know how to control a laser?

LaserWeb promises a web interface. The installation is complex, and depends on Chrome to function, so the first job is to install the browser. Then there is a Node installation, which is a Java runtime that glues the interface to the network. Then just invoke Node from Terminal, open Chrome and dial in the node server, and connect to smoothie. Don't forget to run configuration on the first session, and enter the PIN to unlock the user controls.

After that, the whole pile will likely latch up.

So reboot the Mac, reflash the smoothie, remount the smoothie, open Terminal and fire up Node, yadda yadda yadda. This is not the portable system the project was supposed to create. It is very dependent on toys and nerd habits. It's fragile. And not at all accessible for a new user.

Still won't fire the laser.

8 Nov 16[edit | edit source]


Put a GRBL on it and call it done. Five hours to convert from smoothie to Arduino Uno. 20 minutes to configure. Everything works as expected, except there are configuration options regarding homing that require a recompiled GRBL sketch. And just like that, Arduino can't compile for an Uno. At least that's not a GRBL problem per se.

Oh, and apologies to the smoothieboard developers; the failure to home was a wiring problem. So it's only half a failure.


9 Nov 16[edit | edit source]

So blame Apple for the GRBL compile failure: Arduino 1.6 doesn't work under El Capitan. The Arduino community offers elaborate work-arounds, none of which got the compiler going. But version 1.0 runs just fine under Lion.

The strength of GRBL is configuration. There are 31 settings reachable through the exposed interface. There is another pile of compile-time switches in the source. This machine required 26 run-time settings and 6 compile-time switches; neither smoothieboard nor LaserSaur offer that kind of granularity.

Pursuit of function uncovered some features of GRBL that are under-publicized. It has soft limits. The GRBL implementation requires a homing routine, and an accurate definition of axis length. It then parses any move and throws an alarm if that move would violate travel limits. LaserSaur support got really hostile when queried on how to implement soft limits, so that problem remained unsolved and LaserSaur was replaced with smoothieboard. smoothie has a long series of threads about how they cannot implement soft limits because "its complicated" -- better not to try than fail. Did these developers remove GRBL code? or did they just not parse the config.h file?

Moreover, GRBL has a proper door interlock programmed in. LaserSaur implemented this in hard logic, one of the features that made it attractive for a laser. But when connected to the solid state laser this project is using, it fired the laser randomly. smoothie throws up its hands and says "do that as an external circuit" which leaves the controller in an undefined state. Under GRBL, the door switch acts as a feed hold, pausing motion and laser until the door is closed again. And there is a programmable pause before resuming work. This is all in the compile-time configuration.

GRBL still requires an external emergency stop circuit for compliance with OSHA regulations, but does clearly anticipate killing the logic as part of the shutdown. LaserSaur implemented this more-or-less correctly, but it was also linked to the laser trigger, so on startup and homing the laser fired briefly. Probably a transient voltage or ground state in the circuit; the laser fires IF power is applied AND [TH pin is open OR NOT 0V]. smoothie has a kill button, but it is poorly documented and did not work in the LaserCube implementation. From the documentation, it's an NO momentary switch that stops the board. Press and hold for 2 seconds to resume the board. The external circuit for emergency stop is supposed to close this contact. Well and good, except that a compliant Emergency Stop button is "push on, twist and pull to reset", not a momentary action. And its NC, not NO, so that it fails safely. So in a typical scenario, smoothie fouls up, the Stop is pushed, 2 seconds pass and smoothie resumes whatever it was doing. This left the machine in an undefined state, and frequently during testing, the smoothie was halted with Estop and on resetting the button, smoothie was still moving motors.

Maybe makers will tolerate this slop, but this laser is exposed to untrained public, inexperienced operators, and harried instructors. It must be fail-safe. So LaserCube has a belt-and-suspenders approach to safety. Door interlocks do a feed hold. Estop kills power to laser and motor power, but leaves power to the logic circuits. The button has a separate contact wired to the reset/abort pin on the Arduino running GRBL. As a last resort, there is a power switch/circuit breaker in easy reach of the operator. During development, power for the Arduino is supplied from USB, so yanking that plug kills GRBL.

On to happier issues.

It was on the "must have" list that the LaserCube host its own interface. LaserSaur did that with a BeagleBone. smoothie might have done that, but since its network config never took, it was not tested. So can this be layered on top of GRBL? Probably yes.

This builds on GRBL by adding a Raspberry Pi. The Pi hosts a web site and mediates communications. Handles as many GRBLs as it has USB ports. Can attach through Ethernet or WiFi. The user only needs to point a browser at it. Converts SVG files to gCode.

What more could you want?

13 Nov 16[edit | edit source]

Nate built a GRBLWeb image on an SD card, and provided a Raspberry Pi to configure. Just a few glitches: the published instructions apply to an older build of the software, so there was the usual fumbling with support boards to get to things that should have been explained up front.

For those who wish follow this path:

  1. What the instructions should say is IF you loaded the image for Rasberry Pi v2, THEN you need to log on as root/debian because it uses the debian build instead of raspbian ELSE log on as pi/raspian.
  2. Edit rc.local by invoking nano /etc/rc.local. Comment out the server you don’t want - GRBL uses GRBLWeb. Write the file (^O), exit (^X) and reboot.
  3. Edit the baud rate to match your GRBL build: IF GRBL .9 invoke nano /home/pi/grblweb/config.js and change the baud rate to 115200 ELSE leave it at 9600. Write the file (^O), exit (^X) and reboot.
  4. There is blah blah about editing config.txt to get more power through the USB ports, but our image had no such file.

And of course, it would not connect to a DNS server. This because GRBL was not connected, so no big deal.


  • Working area is 137mm X 137mm.
  • The LaserCube can cut at speeds up to 600mm/min.
  • Cutting range 20-100% power.
  • It focuses at 75mm.
  • APT laser needs to be kept cooking at 10% power or it skips the first part of lines. This give a handy beam for positioning, though.

The feed/speed chart is built. Some surprises here - the solid state laser can't cut acrylic. It labors cutting wood. But it loves paper and card stock. And it does engraving on some fairly sophisticated materials: slate, whiteboard masonite, anodized aluminum, wood. Not glass or acrylic.

14 Nov 16[edit | edit source]

At make717 today, it only took about ten minutes to move the laser, power GRBL from 5V (because Pi can’t supply enough juice on USB) and cable everything to the network. Then GRBLWeb popped up and ran the laser. Not a bad interface.

Now the CAM tool provided is another issue. jscut is obviously a path generator for Shapeoko, and doesn’t know a laser from its elbow. That’s too bad because it’s integrated into GRBLWeb. For now, massaging the gcode gets our library demo projects going. But it’s clearly an issue to be resolved so that casual users can design and build without stopping to learn gCode or linux commands (see next).

The developer of jscut says, if you want to run a laser, use LaserSaur. Big help. There is an automated tool to jigger the code, to-laser, but it involves a unix pipe. Not 13-year-old friendly. Or 50-year-old friendly, for that matter.

So now the workflow is Inkscape => jscut => to-laser => GRBLWeb => GRBL. Not at all complex. In the field, with 20 screaming kids hovering about. Hell is a place you build yourself.

16 Nov 16[edit | edit source]

As experience with LaserCube grows, certain things become known. These are reflected in new, verified specifications. These are posted at the top of the page so the casual user can find them. The maker declares the official "birthday" of LaserCube to be 11 November 16, Veterans Day.

20 Nov 16[edit | edit source]

Added guard over power supplies and changed the 1-contact Emergency Stop button to a 2-contact model. For the uninitiated, one set of contacts is NC, switching 120VAC through a solid state relay. The second set is NO, and grounds the kill pin on GRBL. This satisfies all OSHA regulations for safety; it disables high voltages and allows an orderly shutdown of the machine.

23 Nov 16[edit | edit source]

Added a Pi-Top to the mix. The project goal is to use a single Raspberry Pi to host GRBLWeb, and to run the browser client. That will allow for a self-contained traveling laser/controller/design tool.

27 Nov 16[edit | edit source]

A normally open (NO) switch does not conduct until it is activated. Putting a magnet next to a magnetic reed switch will activate it. So why is the contact on a burglar alarm switch that does not conduct when activated labeled NO? This makes the GRBL instructions technically correct, if you use alarm switches for your door interlock. But if you buy any other switch marked NO, the circuit will be inverted and will not work. Stupid is contagious.

Anyway, wiring is done.

29 Nov 16[edit | edit source]

LaserCube is set up with two Raspberry Pi. GRBLWeb will not run on a Pi3, so for now a Pi2 is hanging on the side of the laser to do that job. The Pi-Top is built around a Pi3, and runs the client. Both Pi are cabled to the local network. That won't work for portable use, so a pocket router is in order. That's a lot of hardware for such a simple machine. Remember when we ran 'TrolCat off an Arduino connected through USB to a retired MacBook Pro?

1 Dec 16[edit | edit source]

Software for making gCode: looks like the simplest open source tool available. It parses PNG and generates gCode. Since it is open source, it has accumulated a layer of stupid. The LaserCube version peels back as much stupid as possible. Version 0.0 makes clumsy code, but it works. Will it run on a Pi? Time will tell. Lots of dependencies to be resolved: NumPi, SciPy, PIL, TKint.

Under the hood, the script gropes along until it finds a pixel representing an edge or a vertex. It then follows that edge until it exceeds the tolerance for a line or it finds another vertex. Either event causes the script to store the result in a list.

At write time, traverses the list and generates G1 code. It has no understanding of G0 or G2/G3. It mimics G0 by assigning a rapid feed rate to traverses. It also does, in the original script, a Z move before these traverses. It mimics M2/M3 by generating a boatload of G1 segments. And every G1 has a feed rate. That's clumsy code. Now somebody will argue that's appropriate for an Arduino-class controller, but GRBL is so much smarter than that.

The version these LaserCube mods are based on advertises itself as laser ready, but uses M106 to trigger the laser. Nope. GRBL expects M3, a spindle command. In version 0.9x, GRBL uses a PWM pin for spindle, so we may vary the intensity of the laser. This is utterly rational; so the first LaserCube mod roots out M106 and uses M3/M5 instead. The Z moves go away - LaserCube has no Z. And the pauses coded in to wait for M106 are now redundant; out they go.

Now there are text boxes all over the screen for settings, but the gCode output routine ignores them and hard codes feeds. That will need to be fixed. And since this is intended as a teaching tool, all the choices for input/output formats are redundant. Bye, Excelon files. Bye, DXF. Also, wants to send code directly to a machine. But we have a tool for that. Bye bye Send button.

Version 0.0 code runs on LaserCube. It disagrees about where 0,0 is. It double traces outlines. It is a bear to fix feed and speed - all those hundreds of F commands. But this is progress.

And if you open the door, the program pauses as it should. But does not resume. Need to look into that...

20 Jan 17[edit | edit source]

The LaserCube had its debut at Cabin Fever Expo 13-15 Jan 17.

Currently, the software stack looks like this: Inkscape => J Tech Photonics Laser Tool Extension => XYZBots GRBLWeb => GRBL.

Inkscape creates vector art. Version 0.92 has extensions for generating gCode, but they are targeted at conventional CNC and dificult to wrestle into compliance with a laser.

The J Tech extension simplifies the use of the gCode extensions down to one dialog box. It needed a small tweak for compatibility with GRBL; the original script ( appends an M18 code (disable motors) which causes an error in GRBL 0.9j. Also, since XYZWeb doesn't notify when GRBL has executed a program, an M30 (end of program) seemed appropriate.

The resulting gCode runs cleanly on GRBL. But GRBLWeb has some small glitches to be aware of. The door interlock on GRBL is supposed to suspend execution and then resume it after a reset. The command to reset the door is "~". But you can't send that command with GRBLWeb while it is paused. So, open the door and the project is scrap. Because it will need to be reset (CRTL-X) and re-homed ($H) and then the gCode reloaded. Oops! GRBLWeb won't load the same file twice. So first another file has to be loaded, then the desired file re-opened. Not pretty.

All of this would be problematic, except GRBL 1.1 has been released. This is still beta, but is supposed to be more amenable to lasers. It is claimed that the new version fixes the door problem. It is claimed that the new version adjusts power to the laser as the motors change speed to follow a toolpath. Sounds promising. A caution: GRBL communications have been restructured, and currently there are four interfaces that have adapted to the change, though none perfectly.

GRBLWeb is not on the list:

  • Grbl-Panel
  • UGS Platform Nightly Build
  • bCNC
  • PicSender

So, to gain the benefit of GRBL 1.1, the software stack changes: Inkscape => J Tech Photonics Laser Tool Extension => something from the list => GRBL. This actually simplifies the hardware; currently, GRBL on an Arduino Uno talks to a Raspberry Pi 2 which hosts GRBLWeb. The GRBLWeb server is cabled to a router. A Pi-Top (Pi 3) is cabled to the same router, and runs GRBLWeb in a browser. A MacBook handles Inkscape, and is also connected to the router so that files can be passed over the network.

With the new GRBL, the Arduino can be directly connected to the MacBook, at least until the intricacies of mounting one of the listed interfaces on the Pi-Top can be worked out. Not as make-isk, but a lot simpler to troubleshoot as GRBL 1.1 grows up.

There are minor issues for LaserCube, to be solved before it goes visiting at our local Libraries:

  • It is really slow on cutting, so maybe engraving projects are a better bet. It cut at 50mm/min. It engraves at 500mm/min.
  • TrueType fonts render as double outlines. The convention is to use stroke fonts, which are created from a single line. Inkscape has an extension to typeset such fonts, but it's cumbersome.
  • LaserCube needs a focusing ruler.
  • There is some fixturing to be done, to ease the engraving process.