More thoughts about internet requirement

Lasergrbl doesn’t have any of the more complex functionality that Glowforge is promising. Camera based alignment, pass through support, double sided cutting etc. As @mad_macs says, re-implementing that functionality after losing access to the GF cloud software would take a long time.

Those features are more advanced than anything previously offered by any commercial manufacturer of consumer lasers. Even Glowforge with their stacks of money and PhDs haven’t been able to make them work after more than two years of development.

We are also relying on access to replacement tubes and other laser hardware. Not having access to compatible tubes would certainly put a damper on any DIY efforts to replace the software.

1 Like

sure although if something happened to the company in the next year or maybe two, i’m not sure it would matter (to stave off someone complaining about complainers: i don’t expect them to go anywhere, and i fully think they’ll deliver on most of their software promises; it doesn’t mean we shouldn’t be asking questions, though).


I know someone who builds high quality tubes. I’m going to have him look at mine when it arrives. He built them at MIT.


No but neither does GF!

The Glowforge firmware doesn’t take gcode or anything close to it. Dan posted a reply to a question some time ago that the cloud sends something closer to stepper motor waveforms to the firmware.

That’s pretty low level so yeah, when the open source folks get ahold of it, it’ll be a while before that route will do anything interesting. Probably the first thing people will figure out is how to run a completely different stack on it which we can also do by replacing electronics.

I think Glowforge will wait at least until the pre-orders are shipped until doing this since they’re worried about helping the competition too much. Though I doubt a firmware like this would help them much.


Here’s that post We’ll release a GPL-licensed firmware for Glowforge


Perhaps this will help people understand where I’m coming from.
Nothing technically contradicts statements made by Dan. He’s said that GCode isn’t “available” to end-users; you can’t send it GCode, it won’t accept it, etc. This doesn’t preclude it from being used in internal processes, however. Take that for what it’s worth.


G-code is a horrible archaic format. It’s is only popular because it is a standard. If you don’t want interoperability there are much better ways to represent a tool path and no good reason to use it for an internal data representation.


“GIF is a horrible archaic standard, let’s create PNG.”
“JPG is a horrible archaic standard, let’s create BPG.”
“GCode is a horrible archaic standard, let’s create STEP NC”

Not disagreeing, but the history of computing is fraught with uphill climbs to acceptance.


The issue with your graphical representation is that it shows a firmware on the right side which was designed specifically for non-cloud operation.

Dan never promised to build us a standalone firmware. He promised to release THE firmware which IS used by the Glowforge to us.

Which is what I see other people talking about when saying how much work will be needed to turn Glowbricks back into CrappyLaserWithExtraParts if the cloud goes away for some reason. Because they expect to only have the two parts in the Client Glowforge on the left in your diagram. So we would have to build the three parts from the cloud needed to transition to the piece on the right.


I don’t think that’s an issue, I intended to draw the representation like that. :slight_smile: It’s my personal interpretation of where I think the chips will fall where the lie.

No one can definitively argue about what the firmware will contain, because Dan hasn’t outlined it in detail. And I realize my diagram is missing some key details.

I willingly accept that my points about GCode may be completely wrong; maybe they’re using STEP-NC. Maybe they’re not. Realistically, it doesn’t matter… I’m only sticking with it for now because there’s horrible support for non-GCode by third-party software, and I assume they planned for possible obsolences.

Supposedly Glowforge is running Linux. If your definition of ‘firmware’ is inclusive of the operating system, like a Raspberry Pi, then all the diagram functionality can be included in software modules. If your definition of firmware is like a desktop mouse that gets updates from Logitech, then yes, crazy update nightmares are going to happen.

1 Like

I wonder about how well local software/firmware can work in this machine without physical limit switches.

Not to be a smartass – genuine question: what functionality do you think the firmware will give you?

The ability to control the steppers, laser, fans, cameras, etc. Not from a web browser, but from compiled code. It would also allow for a security audit. In other words: Nothing without additional work.

Do you think it will be a complete cloud-enabled Glowforge, complete with a functioning web server you point your browser to?

Of course not. Do I really sound that naive? I know exactly what @dan offered and didn’t offer.

Why on Earth would they open-source their entire web-based software stack for some other laser manufacturer to come along and take years of R&D from them, when they could liquidate it for cash if they (God forbid) had to file bankruptcy? Or where they could pivot it into other industries, like CNC?

Why on Earth are you implying that I suggested such a thing?

1 Like

To be clear, what I expect them to open-source is the “Client Glowforge” box in your diagram. That’s it. Nothing more, nothing less.

I wonder about how well local software/firmware can work in this machine without physical limit switches.

It’s got to have something to allow it to orient itself. Does it really not have limit switches? Does it use the camera instead?

If it uses the camera, that’s actually kinda cool. It would make it much more difficult for a custom firmware to make effective use of it without relying on a more powerful computer, but it saves a significant number of parts and additional wiring.

1 Like

Correct. The lid camera tells it where the head is when it sees the logo on it. Then it’s easy enough to calculate where the edges & corners are.


Probably easy to fit some limit switches and also easy to locate a logo in a camera image. Pick and place machines locate parts to great accuracy with a camera and OpenPNP does it I believe.


And just to add on this - it has accelerometers, so in theory the limit switch trigger could be marked by the sudden deceleration of the head movement during calibration. If the bed size wasn’t simply hard-coded to begin with.


I agree, but probably expect worse than what you do. :joy:


  • I expect very simplistic code indicating a list of GPIO pins: stepper motor control, PWM for laser output, fans enabled/disabled, PWM for the stage lighting, button state/lighting. Hopefully some readback indicating the engrave height, but I’m not holding my breath. And some way to read the accelerometer.
  • (assuming Linux) nothing real other than them saying it’s standard USB drivers for the overhead and near-view camera. So “use generic UVC drivers”.

Since it’s likely running on a freely-available-but-custom-configured Linux kernel – or a commercial distribution – I don’t foresee how any code they’re obligated to provide you (above what the distribution already provides) will aid in a security audit, unless you find stepper motor control a high-risk activity.

And before anyone starts linking in videos of an industrial motor being thrashed via errant commands, I’m well aware of it. I’ve done embedded programming for SCADA devices.

updated to say ‘bakend code’ instead of specifically motion control…