I was thinking about making a drop-in replacement controller board for the Glowforge so that it could run LightBurn Software and was looking for some hardware information. I found Scott’s Github Wiki with the amazing teardown and other info, which led me to this OpenGlow forum.
I have some questions about the general ideas of this project:
The OpenGlow board is using Trinamic drivers (yay!) and a Linux SOM - the same one that appears to be inside the original GF Controller.
Why use the same SOM family and not a cheaper processor/ SOM?
How many GlowForge users do we think would actually be comfortable doing a controller swap?
Based on the case that a decent chunk of GF users outside this community might not be comfortable with getting their hands dirty in this way, why not make a new firmware for the existing controller, since you’re already developing for the exact SOM that’s on there? This might have a much wider reach.
I make the Cohesion3D boards which drop right in to replace the limiting stock controller boards in a number of the cheaper Chinese laser cutters like the K40, so I’ve got experience with PCB Design, production, and the needs of customers in this space, but implementing a Linux system onto a board is going to be new to me (haven’t had to do that yet, but it seems necessary in order to be able to talk to the camera, drive a touchscreen, and handle comms via network/ USB gadget if needed), and I’m not much of a programmer/ firmware developer at the levels needed for a project like this.
I’d appreciate any feedback, from my reading it seems like there’s a nice group of people here.
I have. I work with the LightBurn developer on a few things. I may have seen you on the LightBurn FB group - no profile pic and Thunder Laser?
These are my opinions, not speaking for LightBurn here: If the controller is going to present itself as a GRBL device and act similarly (meaning job streaming via USB cable/ COM Port), it should be possible for LightBurn to support it directly - meaning all the live jogging and direct running. Otherwise, if the GRBL stuff is more under the hood, it might still be possible to save gCode from LightBurn that runs on the OpenGlow board. I’m not clear if there’s going to be some interface layer like a website or other control program.
When Scott talks about this, is that the answer to my question about why it might not be possible to run a 3rd party firmware on the stock controller?
Do we know if the USB ports on the stock board usable at all?
If no, that meaning the interface would have to be over network and new protocols would have to be written - so that complicates things.
If yes, or if the replacement OpenGlow board allows taking gCode commands over a COM Port, that makes things as simple as possible from the perspective of LightBurn supporting this.
And then there’s all the questions about how things like the camera get interfaced - since LightBurn can use a camera for scanning artwork placed on the bed and work piece alignment, but it is currently for a camera plugged into the USB port of the computer - so it again depends on how the camera is presented, and whether it’s possible to get that to be as a typical Camera USB device.
Yep, that’s me with the Thunder Laser and no profile pic. I visit the new LB forum and the old FB LB forum daily just to keep track of events there. My laser is in the garage and it is a bit cold to be working there for the next week so I haven’t been very laser active. I was a GF founding backer but bailed 18 months ago when it became apparent that they had a lot more issues than acknowledged publicly. I follow here once or twice a month out of general interest and have no real technical GF knowledge. Hopefully Scott will respond to your questions. It would be nice to see some cooperation between Scott’s and Lightburn’s groups.
First, the development of a drop in replacement was driven by necessity. When I was doing my reverse engineering work, I had an unfortunate incident where a probe slipped and sent 12VDC into one of the iMX IO ports. That was the end of my factory board. Rather than give up, I decided to carry on by designing a drop-in replacement - which was always something that I had planned to do, anyway. The “incident” just accelerated my timeline.
Second, the choice to use a processor in the same family as the one used by Glowforge was in the interest of compatibility. I figured that it would be a more attractive option to replace the system board if people still had the option to continue to use it with Glowforge’s web interface. This would be made easier by using the same general platform as the original design. To be sure, a board could be made with much cheaper hardware (I already have a Raspberry Pi Zero version in the works), though it would be a challenge to make that work with the GFUI.
Probably not many. The vast majority of the new owners appear to be more on the artistic side, and less technically savvy than early adopters. I think many of them will be very wary of taking a screw driver to their multi-thousand dollar device. (Look how many times people have asked what the “blue thing” is)
Indeed, much of what I’ve already cranked out will work with little modification on the factory board. The problem is getting a custom firmware image onto that factory board.
The factory firmware has a function that allows you to load an image onto the device via the same interface used to connect the device to your WLAN. The firmware image you upload has to be signed using Glowforge’s keys, so you can’t use it to upload a custom image of your own (Dan said a means to have them sign 3rd party images was “in the hopper”, but I wouldn’t hold my breath).
There is USB serial port access to the factory board’s console, which would allow the signing requirement to be bypassed. While I have provided instructions on how to access that without breaking out a screwdriver, Dan has said that the parts for that port were no longer going to be populated at the factory. Meaning, if you have a later production version, you would need to break out a soldering iron along with a screw driver (and likely need a hot air re-work station as the serial to USB chip is not one you could solder by hand otherwise).
So… Given that there are significant barriers to getting custom firmware on a factory board, why not make a replacement board that has better features than the original?
The stock board has an On-The-Go USB port that doubles as the factory programming interface. So, you can use it as a regular USB port with a simple adapter. I’m not sure if the factory firmware includes the driver for it. The OpenGlow has the same port.
The OpenGlow does support this, and also supports it over a TCP port. The aim is to make it Grbl compatible.
The camera interface is difficult. They chose a camera that is not directly supported by the video hardware on the iMX (typical Glowforge). That being said, a driver to make images from the camera available via a USB interface could probably be made to work.
They are OmniVision OV5648 cameras. They are Bayer Sensors using SBGGR10. This is a format that is not supported by the iMX6 hardware (you have to decode it in software).
It connects over the MIPI CSI2 peripheral interface on the iMX6. The interface only supports one camera at a time, hence the need for the multiplexer connected to the MIPI bus on both the factory and OpenGlow boards.
Neither do they. It’s astounding that GF’s crack team of developers just figured out how to pause the current job, nearly 2 years after initial release… One can only imagine what wonders will spring from their fertile minds during the next 30 years.
It’s actually had the capability to pause all along. It does it when it overheats.
What took them 2 years was to allow the big button to trigger that same pausing code.
My guess is they are trickling out little things like this (that are frequently requested) at a slow pace on purpose. It distracts from the fact that the big features that were originally promised have yet to materialize, and gives the impression of continued progress.
My guess is that they are devoting most of their engineer’s time to new products trying to sustain or create revenue growth in anticipation of an IPO. Dan’s book on startups made it clear that selling out is usually the end goal.
Interesting to take a look at the YouTube videos that they’ve uploaded recently. Bits and pieces of old ones rearranged. Also interesting to see that they have disabled YouTube comments and likes/dislikes.
