How much data is transferred while lasercutting?

If I have a medium size cut, for example, a laptop engraving, how much data is transferred during that process? I know there is really no exact information that can be given, but I am curious.

The engraving that I am thinking of is the one on the Macbook in the homepage video.

I will be demoing the laser cutter to people that are interested (such as FIRST Robotics kids as I am a mentor, friends, family, and co-workers). This means I may not have Wi-Fi, but a decent cell connection. I just want to know if its in the small range, 1-50 MB or larger range 200-500 MB. I imagine that it is small, but would like a little more information if possible.


oh its going to be small. maybe in the megabytes range, but Im thinking kilobytes range is going to be more accurate

I would be careful about speculating. I think the size may vary widely depending upon the type of work you are doing. While even a complex vector cut pattern might be tiny, if you are doing a large raster engraving with grey scale levels (assuming that is possible) the size must be much closer to the original raster size. All that information has to get sent down eventually in order to do high resolution engraving.

Looking for a worst case, imagine a 10" x 10" engraving with 256 levels of grey and a positioning accuracy of 1k dpi (per Dan Confused on this DPI thing/I Need another vocabulary lesson) you end up with raw size of 100MB. I have to assume there will be some kind of compression, but even so, the machine still has get a lot of move-to-x-y-and-then-burn commands.

I would love to hear a more precise number or way to estimate, maybe @dan can help?

Here is what @dan stated back in September:

This probably isn’t a big help. Hopefully with the beta testing starting, we can get a more accurate estimate. :grin:

1 Like

I guess what I am not sure of is what form is the data? I understand that it is not gcode so I guess it is lower level than that. If you think of it as a computer language would it be assembly language or perhaps machine code? Another metaphore might be what level on the OSI stack is it? Layer 3? Layer 1?

Just curious

This doesnt really fall outside of the regular in the OSI model. Its gonna be layer 7. They probably have a proprietary format that is going to be similar to gcode in function. Its obviously going to be compressed, and as mentioned before (which I failed to take into account in my original post), raster prints are going to be larger than vector prints.

However, they havent mentioned how/where this is going to be translated. It is possible to use a simple color image to give commands for raster printing, which could be decoded by the firmware on board. Each color channel could represent a different function: Intensity, duration, focus. This would be pretty cool, because you could SEE whats going on like the predator. It is also fairly unlikely they will do it this way, but something along those lines for raster. I think it would be cool to have a visualizer for this data at some point though. kind of like a spectrum analyzer for audio.

vector will be a lot easier as it is just point to point with a change from the intensity/speed/focus of one point to the next.

dont bank on anything in this post. its just me tossing out random ideas.

1 Like

Interesting, I was not considering an alternate to gcode, meaning the use of a home brewed higher language. Do you feel the data will be high enough to represent a vector as such and there will be a interpretor inside the GF? This high level would be created by firmware?

Even a lower level than that.


Thanks rpegg!

So from what @Dan said it is like layer 1 of the OSI model? Just groups of electrons coming down the wire…?

It would still be layer 7. They are sending a compressed package of information down over an internet connection, which is TCP/IP. Its basically a file transfer. OSI layer 1 is the physical hardware layer, like network cards, cables, etc. For anything to run on something like that, it would be very basic, almost like a lightbulb, and wouldnt be worth the trouble. What the service online will apparently be sending is the information in waveform to turn the stepper motors on and off (waveforms as stated above), and will look something like this:

This information will be compressed into a file(s) and sent down to the glowforge over an internet connection.

It seems they are trying to drastically reduce the amount of components necessary in the construction of the glowforge, which is why they are doing all the heavy lifting on the server side. They have already stated they will not have an RJ-45 jack on the glowforge, just wireless. So basically all they will need is something on board to manage the wifi connection, receive the files, capture and transmit the images from the camera, and run the motors/laser tube. This could all be accomplished with an aduino which is what inventables is using to run their xcarve. Dan is friends with the guys from x-carve and has built a good portion of glowforge in a similar manner, so it would make sense that they do it this way.

1 Like

Correct, it’s basically compressed waveforms, so we can keep the local processing as simple, fast, and low-cost as possible.


Thanks, that is what I was looking for. I know speculating is essentially pointless, but I was hopeful for a few examples. I don’t think I will be using my phone that much, but there are definitely instances where it might be used all day and I wouldn’t want to have to spend so much extra on data. 100MB at a worst case (without compression) doesn’t seem that bad.

I am like going to be doing larger cuts with smaller engravings which should hopefully be under the 20-30 MB range, and from what everyone is saying, sounds like it might even be far less.

Thanks @dan!

Thanks @joe – didn’t find this when I searched.

Thank you so much for making it more clear to me! :smiley:

1 Like

“waveforms” sort of threw me, they sound so analog, but sequences of ones and zeros for a stepper are waveforms. This means that for vector cutting the system will be extremely efficient, and with even a small on board cache a lot of stuff will be independent of the connection.

1 Like

The fact that the digital bits represent an analog waveform is only relevant to this discussion because it means they compress extremely well.

1 Like

I just had a thought… there is some fault tolerance and bit checking done and doesn’t just accept the waveform as is, right? Someone with a poor connection or some interference couldn’t end up with a bizarre command thrown in and a line cut accross the material that shouldn’t be there, right?

Nah. I’m sure the control info is still sent through standard data packets that have redundant error checking.

1 Like