I was doing a simple 5 box gradient patch. Drew it in Inkscape, then exported as PNG, attached.
It configured it with two copies of the attached file (and have not tried scaling it down to many fewer pixels), one at a medium speed and one at a very low speed. The low speed one seems to push it over the edge into failure. Will test again in a moment.
The GF front end fails to prepare this file. Times out.
That seems surprising.
Vector & Rastered SVG.zip (2.9 KB)
The attached file seems to have two SVGs. Without seeing the PNG, my guess is that you rasterized and exported at a very large size/DPI. What’s the file size and the pixel dimensions for your PNG?
I mean at low speed you’re probably hitting the 3.5ish hour limit, yeah?
This is the message I get after converting your file to pdf and uploading it.
I know the original vector SVG won’t work. Never tried it.
I tried the PNG directly. Same issue. Same issue with the rasterized SVG.
No warning on either. Just took forever to prepare design, then failed with error.
I don’t think so. Processing a single copy of the PNG file at about 5" wide took ~9 minutes at a speed of 500. At a speed of 100, that should “only” take 45 minutes, right?
As the filename implies, it is the original vector SVG and a rasterized copy.
The PNG was attached; 1290x500 or so. Even scaled down to ~400xwhatever, it still fails to prepare if the speed is set to 100.
Confirmed; it is the speed setting that causes the failure, regardless of PNG size.
If I set the speed to 100 (this was just a test, not saying that is a reasonable thing to do ), it fails to prepare with a “print size” error.
To be clear:
- add scaled PNG attached here
- set speed to 100
- set power to variable
- click print
… spin spin spin … PRINT SIZE ERROR.
Those error messages are not from the original vector file. They are from the raster file. You have at least 13 squares piled on top of each other ( at least thats what I counted).
The PNG is what is generating the “PRINT SIZE” error. There can’t be piled squares in a PNG.
Engrave speed of “100” is equivalent to about 4 inches per minute. Speed of 500 is equivalent to 151 inches per minute.
Whoah. It isn’t linear?
OK. that changes everything.
What are the units?
By strictly math: Assuming a ~3 hour buffer and the physical size of the print being 5.4"w x ~1"h, you’d have to set the LPI down to ~133lpi in order to get the print to run at 100 speed.
In real life testing, 125 LPI and lower works.
I don’t get it. Never had an “old unit” UI so I have no idea what the old unit to new unit conversion means.
What are the units of the “speed” parameter, then? Arbitrary? And seemingly non-linear?
I.e. if I have an engrave that is, say, 100mm long by 10 rows (i.e. 1m total, minus corners) then what would be the time to traverse at the different speeds?
You just have to calculate it backwards… spreadsheet only calcs one way as it is. “Old units” were Inches per Minute. Plug in an inches per minute value (old unit) and you’ll see what the corresponding “new arbitrary value” is.
In the strict mathematical sense it is linear function of speed but it has an arbitrary offset as well as a scale. To convert back to inches per minute use these formulae.
ipm = 4 + (cut - 100) * 153 / 400
ipm = 4 + (engrave - 100) * 331 / 900
I’m not saying this is the case here, but the PNG file format does allow layers and they can end up stacked. Adobe Fireworks was my go-to editor for years and uses layered PNGs as it’s default file type to this day.
But nothing else (that I know of) will really modify those layered PNGs. It was basically Fireworks injecting some code into the PNG file, that it could then read back and interpret as layers.
I don’t disagree (although Photoshop will read/write layered PNGs), was trying to distinguish between possible/impossible. Backing out slowly…