The speed of the laser head is going to vary based on the motion plan I think - it will need to slow down more for travel along the Y axis due to the need to stop the weight of the gantry as well as the head, so depending on which direction the head is approaching the particular circle it intends to cut, you’re likely to see more slowing.
Don’ think you’re going to be able to do anything about that aspect of it. You might just need to slow it down some more to power through the ones that it isn’t cutting through.
Okay, I just ran that print - a bit smaller to fit on the chip - no changes to it except for changing the cut order on the circles to make them cut first, and I used my standard settings for that chip of 380/58.
All the circles cut out fine. What might have happened is - if you let the outsides of the squares cut first, the pieces might have shifted, and that might have caused some of the circles to not cut all the way through. You want to anchor it down as flat as possible for the little circles.
So you might want to try moving those to the top if you haven’t already done it.
Having said that - running that file caused one of the most frightening displays of travel speed on the part of the head movement that I’ve seen. It was shaking the table from the vibrations it caused. There is something wonky with the file - maybe because of the various conversions it went through, or maybe something in how it was created, I don’t know. If I could interpret the code for it I’d look for some kind of acceleration code in there…but not my bailiwick. Never seen it before. But that wasn’t normal movement.
I’d re-create the file from scratch rather than let that continue. But if you want to use that one, moving the holes to the top of the thumbnail column will let it cut through.
Thanks for the test. The holes were set to cut first, which is why they were set to a different color from the squares.
When you say there was a lot of shaking, was that with a speed setting that you had used before that did not cause such a ruckus? Was the rapid shaking movement during the cut or the translation between cuts?
It was the head movement while travelling from cut to cut. We can’t do anything to affect that, it’s something in their algorithm, but it looks like something impacted it somehow. I’ve never seen it before, and it’s not doing it now on another file that I’m running, so I have to think there’s something in that particular file that it doesn’t like.
Something weird in this file for sure. Maybe the Inkscape SVG step? I think it is recommended to use Plain SVG from inkscape. Not sure if that’s the problem though.
48 circles on top of each other in the upper left corner.
I erased the corner circles and the lower two rows of shapes, replicated the top row two times, and saved that back as an SVG.
I have an hour left on a three-hour engrave, which I will then have to flip for a second three-hour engrave on the back, so I won’t be able to test my version until this evening. Feel free to try my version below in the meantime.
(I also added lines for the top row, so they would cut out completely as well, but made them a different color so that they could be ignored if they were left out for a specific reason.)
I ran the original shared SVG file same as Jules without any edits other than scaling down to fit a piece of paper.
Had zero issues with it running.
I’m actually surprised how efficient the motion plan/head movement is on this one. Yes, it zips 'round those circles like a neurotic dog chasing its tail, but nothing out of the ordinary that I can see.
I shot a video which is currently uploading, it’s got about 10 minutes to go so I’m gonna grab lunch and will share the vid once it’s done.
I’m laughing out loud watching that… yes, it’s amazing the machine we have at out disposal but, what amused me most, was the number of times the head traveled across an uncut area that it could have just cut along the way…
Nope! I could have sworn it had a different motion plan when I ran it, and it was rocketing around to get to the circles. It didn’t just follow along doing them all in a row like that.
Thanks for your patience. I’ve researched quite a bit and believe that your Glowforge is working properly. I’m moving this discussion to Beyond the Manual in case you’d like to continue to talk about settings or other solutions.
So variable travel speed for identical objects (the circles) is normal? Some cuts are slow enough to cut all the way through the material and some speed up by various amounts, delivering variable amounts of cutting power to the material. For objects that are all the same color and in the same object grouping in the GFUI, this does not sound like expected behavior… can you provide more information on how to get consistent power delivered to the target material if all cut lines are in the same grouping?
Vee may not see your reply now that it’s been moved to BtM. You may need to make a new post in Problems and Support. Have you run across a simpler file of circles that reproduces the different speeds? If so, that may help the quickly diagnose what is going on.
As some of the others have stated, my gut is that it was something with your file, or the cut settings causing the issue.
When you look at the picture the exact same holes aren’t cut in each of the three. The only way that’s going to happen is if it’s in the file, or the settings set for the features/how the GFUI is interpreting the file.
IF it was an issue with the laser hardware, (alignment or power delivery) you would notice an issue on the left vs the right as the head changes distance from the 90* mirror.
It’d be nice if the GF post-processor would figure this out on its’ own by default and give the option for User Override (relying on the user set path direction) perhaps they can “Add it to the Hopper.”
If there were two identical circles in the exact same place, it would travel around the circle 2x and thus cut all the way through more reliably? It is interesting that the laser isn’t modulated for sharp direction changes like a right angle moving from x-travel to y-travel. The mechanism for change of direction seems to necessitate the head slowing down then speeding back up but the laser score function over-burns in the tight corner during that transition. It’s definitely a software thing…
