We’ll release a GPL-licensed firmware for Glowforge

Thanks that is GREAT to hear. I went back and forth on if I was going to outlay the money for this, but in the end I am glad I did, especially seeing that you are really looking out for the end user. Great job, cant wait for it to show up.

1 Like

This is fantastic news - congratulations!

Would you consider putting the hardware designs under some sort of open source escrow arrangement as well? So if something unfortunate did happen to the firm they would also be released?

Ben, it’s a great idea, but the cost of doing that in terms of time, maintenance (updating it with every design change), and overhead would come at the expense of development that will benefit everyone. We’ll keep it in mind but I don’t think it’s going to be likely.

Totally understand, I’ve used BOM, PLM and 2D/3D cad parts management software before and even with all of those it’s a nightmare at the best of times - once you’ve finished putting a rocket under the laser cutting industry how about disrupting them!

I think we’d all love a Github for CAD and BOMs that was maker and GPL friendly :smile:

1 Like

You should note that while open any firmware modifications void the warranty.

Good point @fablab_elpaso. Unfortunately it’s easy to toast your Glowforge when modifying firmware, so we can’t replace parts if that happens. (We toast parts all the time when we’re developing!)

Now why can’t you post those videos. I bet they are full of excitement?

Ha! OK, duly noted. If I catch a video of something going terribly awry I will share.

It’s usually at 2am when the cameras aren’t running, though.

3 Likes

@dan Is this something that would be hosted on github or the likes? Is the current firmware forked from something else? i.e. GRBL, TinyG or Smoothie? Or completely home grown? Lastly, you mention user flashable- Would that be via a special app? or thru something common like the Arduino IDE? And I assume they can be done via the USB port? not a ISP?

Sorry for all the technical questions. Kinda a nerdy that way.

Not at all. :wink: We haven’t decided on hosting or firmware flashing procedure yet. The device doesn’t handle G-code, that’s done in the cloud, so there’s no equivalent of TinyG. Our priority right now is getting the experience great so we won’t have firmware release details for a while.

Okay- That’s the statement that fascinates me the most. Typically CAM generates the gcode. Then the motion controller handles the cords. and does the low level stuff by instructing the steppers via step/dir.

I can understand the the CAM part is done in the cloud- But what instructional set is the onboard motion controller is using? The follow up question is what limitations where you hitting that made you guys ditch standard gcode?

1 Like

Bingo. We do both CAM and motion planning in the cloud. We just send the machine the actual waveforms to be fed to the motors (X, Y, each fan, focus, etc), laser, chiller, etc. There’s a bit of decompression and then the uP sprays the results at the right I/O lines.

Not being constrained by g-code opens some pretty cool doors in terms of what’s possible… much of that will be behind the scenes, though.

4 Likes

Interesting. So CAM & Motion Planning is done in the cloud. And the GF Controller receives a multi-channel waveform to control all the things? So- There is nothing on board that does the traditional step/dir generation onboard? (i.e. Mesa or PRU)… Just feeding in the actual pulse…that has been post processed remotely?

Exactly.

Whoa.

That basically means you have have something that as epic as a mesa- (or better) in the ‘cloud’ to drive all your machines.

Please tell me at some point you guys are going to talk more about that in detail. Because that’s pretty eff’ing awesome. Seriously. I’d have to say that’s the most understated feature of the GF (from an engineering aspect)

Mind Blown.

3 Likes

Funny Glowforge genesis story: I was going back and forth with Mark, our CTO, between closed-loop (servos, which I was advocating) and open-loop (steppers). He made a better case for steppers. Finally I said, “Well hell, if you want to go open loop, you don’t even need local control at all. Just put the damn motion controller in the server.” I didn’t actually realize what I’d suggested until Mark stared at me like I was from Mars for a while and it dawned on both of us just how powerful that could be.

I miss getting to work on the actual design… now I have to be all CEO-y. Catching up with you all is one of the highlights of my day. : )

11 Likes

With it running open loop, @dan, are there any concerns with the motors missing a step which would result in a shift in the rest of the print (e.g. an engraving that is 8.5" x 11" and half-way through, something causes the motor to miss a step)? I’m thinking if a motor missed a step, you’d have a bigger problem on your hand as that would mean something crashed, got in the way, or failed. From what I’ve seen posted from your team on here it looks like it’s not a big deal. I’m just bringing along the “baggage” from a reprap design that had undersized stepper motors running open loop and seeing a shift in my print. When I get this thing going on making those living hinges, I wouldn’t want the laser to be missing steps! Thanks a ton!

1 Like

CEO (Chief Emotional Officer)
Don’t cry, it’s ok…

1 Like

Yes - our solution to this is to not miss steps. : ) We had tons of bugs on this a while ago and beat them all out with heavy objects.

5 Likes

Missed steps are more of an issue with laser cutters than other gantry bots because soot tends to accumulate on the rails. The wheels need to ride pretty tight on the rails to avoid any wobble in the effector, so they get stuck really easily if there is any build up. Easy solution though: Keep your rails clean with a little soap + water. Don’t use any chlorinated cleaning solutions.