Lateral Shifting artwork during engrave


#1

Recently started seeing this error - I’ve seen it 3 times now with this project (chits for a board game).

The engraving artwork seems to shift to the left at some point, but then it comes back? Note that the print is printing bottom-to-top, and the CUT is happening after the engrave, so the error is not affecting the cut line, and the engraving “comes back” to the correct place after some time, correctly printing the rest of the design.

Notice also that the top row of pieces isn’t showing the same error, it’s not in the artwork, and there’s nothing in the bed the laser head is running into, as far as I can tell. I’ve got some magnets holding the piece down that have never interfered with other prints before, so it’s nearly certain it’s not that, and also probably not that the material is shifting itself.

It does, however, seem to be a horizontal band of area that is shifted, so something interfering with the heads positions, maybe something in the gears. I’m cleaning it out and running some lines tests now to see if I can get more info.

Ideas?

UPDATE: I ran the same row of chits again in a different part of the bed (closer to the top/backside of the machine) and got a tiny bit of this error to repeat, though this time, only on a few lines (340LPI) seemed to go off the rails.

So I ran vertical & horizontal lines that span the bed to test (both engrave and score) on some draftboard and didn’t see the error anywhere. But then I got to looking closer, and realized, “hey, I’m not getting really good edges on these vertical lines…”

Nothing really went off the rails like in the other engraves, but the edges of this vertical line are really jagged, not in an nominal sort of way, I think?

I checked to make sure the table feels stable, like maybe the back-and-forth of the head might create rocking leading to those edges, but it’s well-stationed, and I don’t think that’s it. It also doesn’t explain the previous off the rails errors with the chits.

I also checked the gears and belt for any debris while cleaning the inside, and found nothing that might cause this (but I’m no specialist).

UPDATE 2: Powered up the machine last night and tried to run some more chits. It’s a two-step process, where I flip over the chits and engrave the opposite side, as well. This is the same project, just the other side of the chits:

I’m not going to win any photography medals for these, that’s for sure. Still, in this picture, the two on the right side printed correctly in a different run, the 4 on the left are from a run that glitched out the same as the front. It’s hard to see, but the numbers almost look doubled-up, like two copies of the number not properly overlaid. Note that there is no doubling of the shapes in Illustrator. Also, even though these glitch-print versions “doubled-up” in some areas, the overall engrave is actually lighter than the properly printed chits to the right (using the same settings, of course).

OK, but, here’s the big hint: The other side of these chits experience a similar graphical anomaly in roughly the same areas. Maybe like that horizontal band of area in the bed is experiencing some problem?

UPDATE 3: Tried to run a different print today - here’s the GFUI image:

When it started printing, I noticed right away that the visual errors was happening again, and so I cancelled the print after it had “developed” the error enough to be visible. Here’s the result:

As you can see, the error I’m seeing on both the chits above and on everything else seems to be worse on the left-bottom(front) of the bed. This coincides with what I was seeing with the chits - most of the unsuccessful prints, to the best of my memory, were being printed in this area of the bed (though not all).

I ran the print one more time to get a picture of those first lines, which shows why it’s so obvious the error is happening immediately:

The obvious thing to see here is that it’s making the first engrave lines of 2 different images (or something) at the same time. During a healthy engrave, the lines are parallel and build from the bottom up, where these are staggered and seemingly incongruous. Like the laser is being scattered. I dunno. I just cleaned the lens between the two error reports, so not that either.


#2

When you do your chits, are the defects always in the same place?

The GF uses stepper motors. I don’t know if it has position encoders to tell it if a stepper didn’t step. Usually steppers are “open loop”, which means if they lose position they can’t get it back later because the system doesn’t know it lost position.


#3

No. The defects happen both in different parts of the design, and different parts of the bed. Recently, the defects are more frequently on the lower (front) side, but I’ve also been using that area more often simply by coincidence.

As you can see from those first two pictures, the head did end up resuming it’s proper position, after being off for about 300-400 lines.


#5

Well I’ve got a CNC mill and a 3D printer that use steppers, and once they lose counts (mis-step) they never come back. So the fact that only some areas are showing the offset suggests to me that the problem isn’t with the positioning system. The laser is doing what it’s being told to do.

Have you tried a power cycle? It’s not a very satisfying solution (because you have no idea why it fixes the problem), but it’s always worth a shot when nothing else seems to work…


#6

On the verticals, a few things can occur there - fast speeds can degrade the edges, like you’ve seen. The laser also has to pierce the surface of the material on each pass, which can lead to variation. One common practice is to run an outline score on the engraves themselves to clean the edges.

As for the initial problem you posted about, the offset. That is definitely unusual. If the head loses steps, it doesn’t get them back and the remainder of the engrave will be off the same number of steps. However, once it started a new graphic, you likely wouldn’t be able to tell that it was off because the whole thing would be offset. With the cuts done after, all of the cuts would be off though.

How was this setup? Did you lay it all out in design software (Inkscape, Illustrator, etc? Or make copies in the UI?


#7

One thing to note if you’re experiencing the lost steps trying to reach the right edge (usually near the front) problem, you won’t experience it again to the same degree until you turn the machine off and then back on. The reason is that everything is shifted left by that amount so they’re consistent and you can’t reach far enough right to hit whatever you hit anymore. But once you recalibrate, it’ll start to the right again.


#8

I’m not sure I’m familiar with what a proper “power cycle” might be, but I’ve rebooted the machine, and had it off for a day without impact on this error.


#9

I like the idea of the outline scored to clean up edges, hadn’t thought of that yet, but to be honest, I’ve never really had rough edges like this before, at least, not of PG.

I lay out the whole SVG design in Illustrator on a properly sized artboard according to all the careful instruction of @Jules. I have made copies in the AI and seen this error as well, but usually it happens when the artwork is laid out like seen in illustrator, with no UI copying.


#10

Interesting. I hadn’t thought too much about the “off-ness” translating into “total off-ness” throughout, and thus not creating errors - the errors I am having are more like some kind of graphical glitch, because it corrects itself later. But I do notice that sometimes the UI is way more off than other times, not sure if that’s related (for these, I do a 2-step engrave, flipping the chits in their cuts to engrave the backsides. In the UI, I use “ignore” and then after flipping them, that engrave should be in the right place. Sometimes the UI is waaaay off, but the engrave still nails it. )

I may have said this earlier, but just to be clear, this is not a problem with the artwork, as several rows of the chits print fine.


#11

Posted a second update in the post, putting this in the comments to let people know.


#12

Don’t think it’s a problem with the artwork either but one way for me to guarantee I’m wrong is to provide absolutes such as “this is not”. Pretty sure support folks will roll their eyes every time.


#13

Thanks for letting us know about this and for providing the details.

I’m looking into it and will be in touch when I have more information.


#14

Thanks! Let me know if I can do any more useful tests. I haven’t been running the machine recently, busy week so I still need to do more research.


#15

Posted another update after testing another project.


#17

Thank you for your patience and for the update. I have determined that your unit has an issue that we can’t solve remotely. I’ll be in touch via email to sort out the details.

I’m sorry for the bad news.


#18