I’ve got a commissioned job to run and GF’s stupid buffer issues are standing in my way.
I have a hand drawn trout I’m trying to scan in using Trace. It’s not that complex IMO, but I guess the GF can’t handle it so I’m getting errors when trying to engrave and cutout.
It doesn’t look that complex to me. But I haven’t done anything that large. Can you scan or take a photo of it and bring it into Illustrator? Then you could trace around it for the cutpath and export the SVG.
Try lowering the LPI to 195. If that doesn’t do it, you might need to split it, or scale it down a little.
Complexity doesn’t matter when engraving, just the total time, which is roughly proportional to the area times the LPI divided by the speed in inches per minute.
Has anyone checked to see if this computed total time is indeed proportional to the time the GFUI reports? If so, knowing that proportionality constant would be useful for those doing engrave-only jobs to assess whether the job will choke or not.
The file downloaded to the ~100 MB buffer in the GF is just waveforms sampled at 10kHz. So the size limit is just on total job time.
When engraving the time is the time to scan the area at the specified LPI and speed plus the time to accelerate and decelerate at the ends of the sweep. For a large / slow engrave they will be relatively small.
Calculating the turnaround time is probably a bit involved because you need to know the acceleration. Looks like they don’t use constant acceleration, so you need to know jerk as well. I.e. looks like S shaped velocity profile rather than trapezoidal.
Yes, the higher derivatives of velocity will make a difference in total time, but I’m thinking your formula would give a starting point for selecting a workable LPI for a given area and speed, if the proportionality constant is known.
There is no proportionality constant once you convert zooms into inches per minute.
Area in square inches times LPI divided by speed in inches per minute gives time in minutes.
Yes, I understand that. I am assuming the proportionality constant would account for a “generic” additional time due to accel/decel. Yes, I know it depends on many factors. Unless the additional time for accel/decel is insignificant, it would improve forecasting total run times.
An additive correction factor, based on area, speed, and LPI might be a better correction than a multiplicative scale factor.
Yes you would need to add turn around time, which is proportional to the number of lines and a function of speed, acceleration and jerk.
I could probably come up with an equation.
I think that would be tremendously helpful to be able to compute a ballpark LPI needed for a job to run successfully!
Can I? Yes. Should I have to? No. I know this is a known issue, but it’s killing the magic.
I’m capable of doing that, but are all of the parents who bought the GF because of the promise of automagically throwing your kids artwork in and engraving it on something else capable of that?
Not an option. Commissioned work with specific size requirements.
I think I’m grumpy. 
Edit: obviously I am, because I forgot to mention that lowering to 270 LPI was enough to get it to work with no apparent quality issues. You’d think the GFUI would be smart enough to warn me that my LPI setting was too high, or recognize that I’ve chosen PG veneer, which doesn’t seem to benefit a whole lot from a much higher LPI setting.
Sometime “soon” (starting to sound like Tesla here 
) they will be able to handle larger, longer, jobs. Unfortunately “soon” isn’t now.
Grumpy is totally OK 
I’m glad you were able to solve it.
I appreciate your feedback and have captured it for the rest of the team.
I’m so sorry for the inconvenience.
