I don’t necessarily think it’s an assumption, honestly. I think it’s people trying to be helpful, and the only area they can really help with is checking some of the frequent user-error things that can happen. I mean, if the options are just ignoring everyone who posts a problem until staff can look at it or asking if it might be x, y, and z, is it better if people just ignore it?
It’s all good. GF hasn’t responded yet. Frequently users chip in before they can with something that ends up closing the ticket faster (because we are an awesome group like that). I’m willing to troubleshoot as much as we can, either with random guesses or official assistance.
Most of the time I’ve posted: It’s PICNIC error (Problem in chair, not in computer), an unaccounted for variable (humidity) and just once was it a GF issue.
I don’t think anyone’s assuming that. We’re simply offering ideas and that might help, which she can act on without having to wait for support to weigh in. You’re correct - not all GF problems are user created or easily resolved at home. Sometimes there’s a problem with the machine that can only be resolved via the support team.
Though I will say that in my experience with the PRU and since, easily 9 out of 10 of the issues that caused me to file support requests were due to issues on my end (like wonky files, wifi issues, browser issues). When other users offer ideas, there’s no blame intended - we’re simply trying to pass along what has worked for us, and hopefully lessen the learning curve for others.
So, for the sake of science, and because this piece is already waste…
Put everything on ignore except the willow tree.
I’ve not moved the material. I’ve not reloaded the file. But the tree is now printing an inch to the right. Not where it should be, and not close… but closer.
I’m trying a reboot to see if it will go closer.
I’m not suggesting that GF should have responded or anything else. Merely stating that SOMETIMES the problem is with gf. Doesn’t seem like saying that should be a leap.
I’ve had several problems with software. A file worked and now it doesn’t, alignment off (now), etc. Troubleshooting on our end and chasing your tail (typically what happens for me) isn’t the only answer…that was my ONLY point. SOMETIMES gf needs to fix something.
So 1 file, and you hit print one time to execute the steps you outlined above? Not run an operation, ignore, run the next and so on? Meaning you didn’t open the lid, the head may have moved accidentally, etc.
What I’m getting at is that it looks like it thought the head was somewhere other than where it was. Did you watch it the whole time? Hear any odd noises like it got hung up momentarily, or ran into something?
Good question. No, I wasn’t watching the entire time, but the door (to that room) was open. I didn’t hear any funny noises.
1 file, 1 print, all execution steps in one go, no ignores the first time around.
The boat looked like it was going fine. I walked away, came back in a minute and the tree (which was another executable step) was off to the left. Then the next two steps were off to the left.
There was nothing for the head to run into (except the edges of the glowforge itself).
The reboot has the tree printing closer now than before. It’s essentially on track, and the amount off I would put down to known alignment issues.
Given what you said about the head… and I’ve opened the door twice to stop the print, and when it reprints it recalibrates… I’m wondering if the issue is with the calibration. It’s gotten closer each time I’ve restarted it. It’s not ‘on track’ yet, but it’s closer. (Or I’m taking shots in the dark)
If it is the calibration, I don’t know how to anticipate or plan for this… as it happened mid-print.
If you know the exact time that the bad print happened, record it here, so that when support sees the ticket they can go back and look at the metrics…I’m guessing around 1:30 - 2:15 CST on January 31st. Is that close?
It was still printing the tree and hand when I made the first post… so, right then.
Jan 31, 11:46 AM (PST is my time zone?)
It lost steps somewhere. Whether that was from hitting a physical stop somewhere, maybe the ribbon going to the head along the gantry isn’t laying correctly, maybe it’s possessed (least likely) - either way, the head wasn’t where it thought it was which is why the power cycle got it within spec. It totally renewed the home point and now knows where it is.
But HOW do you troubleshoot for possession??? I thought holy water was bad for the electronics!?!
Correct. Unfortunately in most of our experience, it’s not and it can be resolved faster through peer assistance than waiting for Support.
Sadly, I’m out of time till this evening to run the whole print… unless I dared to leave it to burn while I’m not home. (which, I’m not, not even with simple proofgrade stuff, …cause talk about fire and brimstone…)
So, I’ll run it again this evening and see if it prints correctly.
I just tried running this job very small on some scrap. There are issues…
The print head did some very weird things when it tried to engrave the first image:
it was doing a weird double-back movement (this was the sailboat):
Everything else seems uniformly misaligned, so I’m gonna go ahead and say it is an issue with the embedded bitmaps, although I don’t have any insight as to why.
I did a trace on them, removed a few stray lines, and merged all the overlapping text. Re-saved, and it ran fine.
tiny, but aligned.
I wish I could tell you why.
Here is my revised version of your file.
Rotated or resized in Inkscape or the GFUI? (If the source file was crated in Corel then ignore this suggestion as CDR saves them as native embedded artifacts not tagged originals with alteration attributes in the SVG.)
Oh, that’s right, I have seen people mention issues with rotated bitmaps. I thought it was just a jagged-line issue. I have never experienced it with Illustrator.
@lizabeta can you confirm which design software(s) you used?
All other issues aside, I would recommend that you do your cuts last.
Even with proof grade, if there is any warp to the material, then the cut may cause it to shift slightly and that can cause alignment or inconsistent quality issues.
(Obviously, that isn’t the issue here as other’s have deduced… but once the real problem is addressed, re-ordering operations will make for a more consistent result!)
The OP did have the cuts listed as the final step (but she stopped before she got there). I also ran the cut operation last (although I did not re-organize the color scheme to make the cut-strp automatically land as the last step.)
One more note:
When I went to run something else after this, my alignment was way off. I canceled the print immediately, and noticed that the head did not move all the way back into its corner where it lives.
shut off the power, centered the head, and powered back up. After calibrating, the head returned home in the normal fashion.
@jbv super fine work here! Respect in the house!