That frame turned out very nicely!
I am curious about something. From your description, I am surmising that all of the engraving was a single operation. Is that correct?
I am wondering if the laser head travelled the full width of the frame when it was doing the middle portion? Or did it do short passes engraving first one edge and then the other?
it did full passes across the whole frame. all the etched portions were combined in Illustrator.
Very interesting how some folks are having long calibration issues and some are not. Thru the many PRUs and the unit we used at makerfaire that was not something we have experienced. The current issue are failures without errors. i.e. upload a file or use one that is already in the design library, and it just churns at ‘preparing your file…’ Then minutes to an hour later just fail with a generic error. It does not do this with every file (which is more confusing/frustrating) So I am not sure what or why it’s doing it.
But ultimately, since they are all the same machine (production units) and we are all using the same interface to control it (da cloud) I wonder why it affects some people more than others?
That suggests that the print could be made more efficient if you separated it into 4 engrave operations: top, bottom, left side, right side.
Since the middle would not have any “engraving” the time would be decreased, and thus the volume of stepper motor data would be decreased.
This would let you increase the LPI to get the quality you want, and split it into smaller sections so you could run in multiple steps if the higher density still is too large of a print to run as one job.
but wouldn’t there be overlap (or gap) between the halves? if a design element stretches all the way across? i understand the concept tho.
need to consider this for my next design. thanks.
I would split it so the top and bottom would be full width. The sides would be just the narrow parts between the top and bottom.
Alignment of individual parts of a single design file are very good. There shouldn’t be any gaps.
If you were designing with vector shapes in AI, I think you can draw a line to cut shapes into separate pieces. Do that across the full width at the top and bottom of the opening. Then make the parts of each section a different color so they show as 4 operations in the GFUI.
For raster images, there is this recommendation for large engraves, tiling multiple images to form a single whole.
One variable as a common denominator i can think of would be connectivity, right? Wouldn’t a spotty connection give results like that?
Hard to imagine that that many people would have broadband issues that didn’t also manifest across their experience like streaming though…
Possibly. But one of the very first questions I asked GF was the unit tolerances for absolutely garbage wireless/internet. They said it was not an issue. Furthermore, at makerfaire we were in a zone that had 100s (even 1000s) for broadcasting SSIDs. And the issue then was the UI was slow on the material detection and starting an op. (A hotspot competing with 1,000s of other cellular devices)
shrug
Since the glowforge is marketed more as an appliance (blackbox) and there is no ‘admin’ page that shows you signal strength or error rates. This is going to be hard for the end users to figure out. Which means an onslaught of support emails. I guess they are going to have to decide if they want to open the kimono so folks that are able to help themselves can do some baseline troubleshooting or be prepared to receive an email about every single issue. Which at this point is the stance they picked.
Yeah, now that you mention it, does seem the conditions at the faire would have been an extreme test of that.
The best way to diagnose it would be to hack into the the serial port and camera images like @scott.wiederhold has, but unfortunately (for us, not him) his machine is well behaved and doesn’t exhibit these problems.
Glowforge are no help because they never say what causes any of the problems we see day in day out, so everybody is left guessing. They just either say send the machine back or it seems to be working now and close the issue.
Not true.
Mine has exhibited the calibration problem where it makes the Y move to the middle, and then repeatedly bangs up against the left side.
My unit sees nothing wrong. It happily sends the picture with the gantry showing in the middle, and showing the head all the way to the left. And it dutifully follows the commands that it receives telling it drive the head to the left, continuing to bang against the stop.
I have not grabbed a lid camera picture when it is doing this. But…
The common situation I have noticed whenever it does this is that I have a previously cut piece of material on the bed that has a square cut out of of it.
Maybe I can recreate it, and see what I can capture.
Garbage internet can be defined in different ways though (and I know you know all of this - probably more than me lol). I’m not a network engineer by any means but I can think of:
My iphone 6s sitting on top of the Glowforge where the wireless receiver is has a 79% signal versus a 69% signal for the Glowforge as indicated in my router administration screen (Netgear Genie only gives % - not db).
Garbage in the sense of on the edge of coverage range (How does it cope with that) ridiculously slow (<256Kbit/s) crazy high latency (Cellular hotspots).
Before Makerfaire, I reconfigured our PRU to the hotspot we where going to use and moved the hotspot into the garage. The unit is on the second floor in the house so 120ft ‘as the crow flies’ thru 4 walls and a floor. Our garage is standalone and concrete. Surprisingly it worked. Slowly but it worked.
Random thought. A smaller Glowforge with a hotspot built-in. Glowforge Mobile.
Latency would have an effect on calibration since it needs to repeatedly do:
Lid cam pictures are ~400KB, and the resulting PULS files are typically around 20KB or less depending on how far it has to move. Figure about 10KB per second of commanded motion.
Latency can play merry hob with data transfers on a weak signal.
You are probably aware of this, but spelling it out for those less knowledgeable. Each of those files get broken into a whole bunch of chunks (called packets), each roughly 1.5K in size. Any one of those can get corrupted or lost along the way. TCP (the networking protocol that http/https runs on top of) will guarantee that (as it appears to the application) all of the packets get there, and assembled in the correct order–or the entire transfer is failed. But that process includes a series of back-and-forth handshakes and acknowledgements. This can cause a large transfer to be delayed by significant amounts of time.
Games work around this by using the UDP protocol (upon which TCP is built) and handling dropped and out-of-order packets. This allows them to never have to wait for the guarantees that TCP provide. Netflix and other streaming services work around this by using Buffering and Forward Error Correction.
Edited to add: This is not a suggestion that the Glowforge should use the techniques games or Netflix use. TCP is great for file transfer…just setting expectations and fostering understanding of what goes on.
No disagreement there. I just believe that the bulk of the homing problems cannot be explained by a weak signal.
If you have a tolerable web browsing experience via the connection (good enough to post on this forum about the problem), there should be no problem using the Glowforge over it.
Most of the homing process is the Glowforge waiting on the cloud for the motion file after it has uploaded the lid cam image. This seems to take an average of about 5 seconds, and is independent of the quality of the Internet connection. (A poor connection would certainly affect the upload and download times - which can be seen in the logs on the device itself - but would have no affect on the cloud’s processing time).
I have a decent amount of experience with embedded WiFi. Most chipsets for anything other than brand-name computers and phones are pretty crappy. If your iPhone works great in the basement, that’s because the richest company in the world has poured countless hours of the best wireless experts around into antenna design, handoff, band selection, working around all the little nuances of 802.11, etc. A chip antenna on a single board computer with WiFi built into the chipset along with an FM radio and smoothie maker is likely to fall off the network if you look at it wrong. I don’t know where the Glowforge falls on this spectrum, though. I think it has an Intel something or other. I have not disassembled mine.
Seems like the virtual machines in the cloud are actually less powerful than the ARM chip in the machine!
Have you looked at what the camera sees when the head is under it? Does it block everything else out or does it still see the corners of the bed?
When you say the last thing cut was a rectangle is the material still in the machine or do we think the cloud is failing to get a new image and is processing the last picture it took of the material over and over again?
Believe he is saying that the S/W is misinterpreting a black cutout in material left on the bed as the head itself. So the the S/W thinks the head is in the wrong place and moves it in the wrong direction hitting the side. I have experienced this and can easily repeat it. Put the material in a certain location and I will get head banging during calibration. Remove it, I don’t. No problem otherwise.
That’s not to say everyone is experiencing the same thing. Lots of reasons why the S/W would lose track of the head and calibrate incorrectly. Shadows from overhead lights, or the sun coming in a window for example. Lots of reasons why the calibration might fail in other ways that have nothing to do with those examples.