How much data is transferred while lasercutting?

@ihermit2, @takitus, this is why I’d like to see more information on what the internal buffer can hold - to determine if it’s something I can work with (or around) so I don’t have to babysit a paused print job while waiting for the WAN connection to restore. Every once in a while (remember Murphy’s Law), I can experience hours of downtime, and can’t walk away from the system until it’s done cutting.

I can just wait (that’s yet another thread!) and figure it out once the machine arrives, but I’d appreciate being able to start thinking now about what sort of jobs fit or don’t fit in the buffer.

Well unfortunately I cant be of much help there, but definitely understand your want to be prepared! Theyve laid out everything about the way the machine works and the role the cloud processing plays in it, but no numbers really. You could probably grab some motor waveforms that have been generated elsewhere and compress those down using standard compression methods to get an idea on filesize, but that wont do much good unless you know how big the internal memory is, and how they handle their jobs. They could chunk them to keep as much information stored in memory as compressed as possible, and only uncompress them when it gets to that part of the job. As I mentioned before a vector cut is going to take up a lot less space than a raster cut, so if you were to get an answer to that question or more than likely would have to be a list of sample jobs detailing which parts of the jobs were what size so you could get an idea of whats going on. I dont really think they are going to be able to provide an accurate estimate until they get everything nailed down for production, and even then I bet there will still be a lot of optimizations made once they are able to start gathering mass data and feedback.

1 Like

I’m not so much trying to get an accurate estimate, as just any kind of estimate at all. I’ve been struggling with ambiguous language like “most projects fit in the buffer” - that worries me, because flash memory is so cheap (for example, 16GB microSD cards are under $5 now) that I don’t follow why pause and resume during data connection loss is even being discussed.

my x-carve & 3d printer cant even be run without a computer hooked up to them… so I guess its a step in the right direction. who knows… maybe theyll try to find the upper end of the spectrum/sweet spot and hit that based on some of the beta tests

My 3D printers also require a computer to run them, but that’s because the toolpath data is computed locally. Then toolpath data is either loaded onto a buffer in the printer, or controlled real-time by my PC. In each case it’s just a matter of where the toolpath data is stored (PC or printer) but in either case the data is local - not over the WAN.

A Formlabs SLA printer has a build volume of roughly 7 gigapixels, and that machine uploads and buffers the entire print job - just saying…

I would pay for enough onboard storage so the GF could fully buffer the job, so when I push the start button I’ll know when it will finish. For all I know, GF has already thought of a biz model around that :wink:

1 Like

@gdmccormack, I get your concerns. We’ve never seen an actual job not fit in the buffer, though, so while it’s theoretically possible (you could layer bitmaps on top of each other until the cows come home) it’s not something I’m going to burn the team’s time investigating and try to characterize. Further, we’re going to improve compression up to and after we ship, so it’s a moving target.

Net-net, I would plan on making measurements yourself when you get your GF.

2 Likes

The GF site shows some pretty snazzy jobs, so if Dan has not seen a job that overflowed the buffer, as far as I am concerned this is totally a non-issue. I repeat my previous whine " concentrate on getting our machines out of the door"