We’ve had an issue where there’s a shift about halfway through an engrave. Moving material in the bed makes it seem like it’s in the same spot on the bed. This made me concerned about my hardware. However, there’s a circle in the engrave, and there’s a cut that follows that circle and the cut seems to have no shift, so it seems it’s in the software. This is a graphic a friend is engraving. The file has a .png in an svg. I’ve done a few engraves on my machine in the past in the same location without a shift, so maybe this came about through an update?
If you are seeing something unusual in just one file, that’s the first place to look. But if you see it happen in other engraved files in the same area of the bed, then it’s probably mechanical.
Can you please take a photo of the ribbon cable and post it here?
1 Like
Thanks for your help!
Nothing is abraded on the cable thankfully. I’m running a different version of this file now, with a different setup to try and test. Instead of embedding a png in the SVG, this time we’ve pasted pixels directly into Illustrator from Photoshop. That’s how I’ve been doing it for engraves without issue. It’s not mechanical because cuts have no shift.
I’m not concerned about abrasions, I want to see if it’s twisted.
Nope. It’s normal and it moves smoothly with the head. The altered file did it again, but this time not across the entire area. The previous engraves had the shift horizontally across the entire engrave. This time it only seemed to happen in one small spot. So the error is either in the file—for some reason it’s minimized when the file isn’t embedded from a PNG—or the error is in parsing the file in the Glowforge Web UI. I suppose it could also be related to whatever code it uses (gcode?) to run the machine itself.
I’ll check it out the next time I do an engrave of my own. I’ve seen that people have had issues with PNGs that have been flipped in the past, so I’m just asking around to see if anyone has had something similar so I know if there’s some process to avoid. 
Inspect your drive belts thoroughly. I suspect there’s a small spec of debris in one of the grooves of the cog belts. Air duster or an old toothbrush might help dislodge the debris. Also an inspection mirror or utilizing the camera on a smart phone to “see around” corners/angles might also help.
1 Like
I don’t know of anything in the software that could cause what you’re describing, but if you want to share the file or a few screen shots of the results it might be possible to eliminate it as a possibility.
I’ll give the hardware another look, but cuts over the same area the shift occurs have been absolutely perfect.
They’re always tweaking the web UI, so who knows what is introduced. I’ve done my share of working on hardware and developing software, and it’s not hardware related.
In the first image you can see the shift. My friend had the cut setting too low because he accidentally set the power to one. So in the second two you can see how the faint cut line continues the circle how it should be cut. Luckily he had the circle on there so we could actually see the cut line would have been correct. The subsequent engrave had the same error at about the same position on the bed, but the final version that worked almost perfectly had it in a different spot, but one that might have made sense with what the file does, which is what leads me to believe it’s an issue in parsing the file or at least something in the SVG that produced this.
After comparing cutout edges and marking them up, the errors in the first two piece have the error in the same part. Those were embedded PNG files. The final file had the piece pasted in from Photoshop had the error in a different spot and didn’t shift the whole print. If debris were causing it in the same spot in two prints, I don’t see why it would’ve shifted for the third and not between each one. And the cut lines for all of them were where they should have been which would also rule out debris. It’s certainly a strange issue. I’m pretty confident hardware isn’t an issue, especially after double checking this. The final file was rotated to a simpler part of the design, and we calculated for that when checking the cutoffs. So it repeated with similar files in the same spot, and a different file did it in a different location and to a lesser degree.
1 Like
OK, so I just started doing a different file with an engrave. I thought it came out a bit spotty on the first one. It turns out this time, the UI set my engrave to draft photo. OK, so I set it to SD Graphic and set it to go again and the shift happened again. Now I’m doing an HD graphic and it’s past the same point without an issue. Is there something going on with SD graphic engraves?
HD Graphic is fine, although strangely the depth of the curved sections of the background of the keyboard is better in the SD engrave so I guess I’ll be experimenting with manual settings.
I think, based on pure conjecture, that your machine has an intermittent hardware fault. Maybe debris on a rail, a loose screw, something catching on something else, misaligned belt, weak motor driver, etc. There are many possible causes, but I don’t think you’ve found a software bug that causes occasional missed steps only on your machine.
2 Likes
@chris1 @Tom_A I respectfully disagree. For one thing, the graphic starts off offset, then corrects itself. I know this because the cut lines have no skips and the part after the skip is correct. So somehow every time it would have to get messed up again after it would be seemingly correct on the last step. For another thing, it only affects SD engraves set to Medium Maple Ply. I too have only used SD until this issue cropped up—though I may have only ever used it on Medium Maple Hardwood in the past.
However, the final thing that leads me to believe this is software related is that it seems to happen in a similar position on the engrave, scaled by the size of the final file. So I compared their ratios. They’re not exactly the same, but I found something even more peculiar.
If you take the height to the error in whatever units you want, and divide it by the total height in the same units you’ll get a ratio. The larger cut’s ratio is .314285714286 the smaller cut is .285714285714. Obviously, the 6 would match too but it’s rounded in the first one. I would find it rather odd that an intermittent hardware error would result in cuts that have an error, not exactly spaced apart, but that are somehow offset from the same number. This is a calculated error. And I’m not saying it’s just on my machine. I’m asking if anyone else has had this issue. I don’t think every single owner is on this forum. It can be a combo of things, sure, but the fact that this occurs in this way seems software related.
I have changed the SD settings to 340 lpi instead of 270 and that error is gone. However, a second cut in the process—the screen of the laptop—set to 270 but 49% power instead of the default full worked. I am running just the screen now at basically the default settings and it’s fine. I’m going to make one more of these from the base file, and try just setting everything to manual vs leaving it on proofgrade.
Well. I can’t argue with that.
2 Likes
Yeah, it’s really odd.
So I set the file to run with SD Graphic changed to manual settings but left alone. It printed perfectly fine. So then I ran the same file and left the SD Graphic set as-is and it’s shifted over already.
The shifts are too perfect for something physical to be causing it (unless it happened every single time). That said, this shift is in a different spot. But this file is an iteration so I’m not sure if the ratio is bound to overall size, or if it’s slightly positional or related to order of cuts. Either way, getting that number is quite strange. When this one is done, I’ll try to calculate a ratio and see if another part of the sequence is produced.
Something to remember about skipped steps is that once you lose them there’s nothing to get them back except “calibration” (that is, finding the head logo at startup). This is because it is an “open loop” control system.
One of the things that makes this confusing is that everything is “correct” in a relative to itself after losing the steps and we’re apt to decide that the “correct” bit is the majority portion, but in actually a very common difficulty with engraved designs near the right edge is to lose steps very early in the process. So the actually correct bit is the stuff at the bottom that looks shifted right, but really it is the rest that is shifted left.
I’m not saying this is what is happening here. I haven’t examined the photos carefully they, but it’s something to keep in mind while diagnosing.
The other interesting implication of this is that if you do two prints in a row. The second is more likely to “succeed” by being consistent with itself because the whole thing is shifted left (no longer goes far enough right).
So what seems like settings change may actually be sequence.
Make sense?
2 Likes
Oh yes, that definitely makes sense. I’ve been trying to rule out mechanical issues and figure out which is correct (the start or the end). I can’t really figure out a way to do so. I suppose I could run the cut first and see where the rest lies. I need to build a foam block for the window when I use the 'forge as it’s 90 with mosquitoes out and my studio needs its A/C cleaned and more insulation so I’m done for the day.
I am cutting in the center for the most part. Though I am cutting is close to the bottom, but nowhere near the right as this laptop is about 3" wide. Lately, my GF calibrates more frequently, however I don’t think it did it between most of these cuts today. But it did calibrate near the last two. I think it was before both but it might have been between. So I suppose it could be an issue of it calibrating, running an ok version, and then starting over messed up. But repeated decimal thing seems odd as it’s persisted through restarts on different days and different files.
Getting those exact matching sequences across restarts, files, and locations on the bed seems to be a strange coincidence. I do know that so far, I haven’t been able to reproduce without it being set to SD Graphic proofgrade so that’s another thing I am surprised about. And I believe I did run two manual cuts in a row.
The measurements I’ve compared are below. Depending upon my measurement on the final cut, it matches the sequence. I thought it was about 20.5mm but it repeats the sequence at 21mm.
There is another error from the first file that also matches the pattern but the initial digits are different. So the repeating portion seems to be 142857 which can’t be reduced to a simpler fraction than 142857/100000. Perhaps I’m finding patterns where they don’t exist, that is definitely possible. I just find it to be a strange coincidence that this number comes up over and over, and it’s not a fraction that can be reduced and as it’s a ratio, it seems it would be hard to be a simple error in measurement or something location-based in the hardware as the size of the pieces are constant but the errors show up in different locations that fit that repeating sequence in their ratios.
Friend’s Disney file: 8.75" tall
Error 1: 2.75/8.75 = .314285714286
Error 2: 2.125/8.75 = .242857142857
The engrave for error 2 was even rotated 180 degrees from the first error.
MacBook Pro File: 98mm tall
Error 1: 28/98 = .285714285714
Error 2: 21/98 = .214285714286
What this means, I have no idea. But on the plus side, I’ve at least found a way to fix it. So if anyone comes across this issue with an SD Graphic engrave, just set it to manual and leave it alone. So far that seems to work. I will report back if that changes.
And thank you all for your help!
You might look into connectivity issues as well… it should really only be calibrating (where the head homes under the lid camera) on your initial boot up, unless you are losing wifi connectivity, in which case it will recalibrate. It will also “calibrate” after each job session, but that is only the lens calibration in the head (the clicking that you hear after the job has moved back to the back-left of the machine).
I’d doubt it as it’s only 12 feet from the router and nothing else seems to disconnect. But I can’t rule that out. It usually only does it if I’ve had the machine on for a bit without running a cut. Perhaps it has a low power mode on a timer? It doesn’t seem to drop any connection in the UI. Wouldn’t the web app say it’s offline?