Call me cheap, but I’ve been trying to figure out how to yield a board very close to 1 square inch, but without crossing over the line into the next $2.50 increment. It’s been a head-scratcher to figure out why the coordinates didn’t match the design in Eagle. Here’s what I’ve found…
The main culprit was text using proportional font instead of vector font, and Eagle definitely isn’t WYSIWYG for non-vector fonts (and never has been, IME). They looked fine on-screen, but were way outside the board outline in the Gerber data.
There does seem to be a bug in the X-axis calculation - specifically, the minimum X coordinate. In my testing, where the actual Gerber data files have the smallest X coordinate at 0.0101, the bot reports it as 0.
For Sparky, a good example of this is my job “Ref Tag 2d 2/1”, which includes an Excel spreadsheet that summarizes things.
My way to get around that second problem is to use a negative X offset in the CAM processing step. I’ve found that an offset of -0.15inch still creates perfectly functional gerbers but decreases the DRC bot’s size calculations to what I expect.
I can also confirm what appears to be a bug in the X Min calculation.
As others have noted, Eagle outputs Gerber data offset from 0,0 (around 0.175 for my particular design). While the BatchPCB bot calcs the Y Min correctly, X Min is always 0 and thus BatchPCB thinks the board is slightly wider than it should (just enough to push it to the next square inch).
Have verified with Viewmate and visual inspection of the Gerber files that no data is at X coordinate zero. Used kgutwin1’s negative offset’s hack to work around it, but that seems like the wrong long term answer.
Be great if SFE could peek at the X Min bot code and check for problems (the design causing me problems is mame-1 for reference).
An an aside, does anyone know how to get Eagle to not to offset the data in the first place?
open up the cam processor. select the rs274x device. you will notice a small group of two boxes labeled “offset” with the edit boxes labeled X and Y.
The padded offset seems to be the same in x and y for me. the additional is .0423 in both x and y. setting both offsets to -.0423inch in cam does what you would expect. though for some odd reason it converted my x and y offsets to mm even though I entered them in inches.
I recall seeing somewhere (cadsoft forum?) that this is 1/2 the width of the expected router kerf (85 mil?).
Note also that the board outline has a slight negative offset in x and y. If you are including the board outline, the bot will pick that up.
The problem is the required CAM offsets appear slightly different from design to design so you cannot just plug in and save values. Different designs have needed offsets of -0.15 up to -0.18 to compensate (though X/Y appear to be the same).
This could all be due to the dimension rectangle not orienting to 0,0 by default and me being unable to move it exactly there with the mouse (since the CTRL-key “snap to grid” doesn’t work with lines). There is probably a command line method to do this, but I have not figured it out yet.
TSPRAP:
My board would never show up as the correct size until I found this post. I did the offset at -0.0423inch and BatchPCB got it right!!
Please tell me how to do this. I tried to, but am obviously not understanding correctly. I see a box labeled Offset in the CAM processor which appears to be the thing, but there is one per layer. So I’d have to enter the offset 7 times? Surely, that isn’t right. And how do you determine what offset to put in? Do you figure it out from how much the bot is in error or something?
It is too bad about the offset being different for each board, or we could just adjust the CAM job definition and leave it.
I see a box labeled Offset in the CAM processor which appears to be the thing, but there is one per layer. So I’d have to enter the offset 7 times? Surely, that isn’t right.
Of course its right-- this is Eagle we are talking about after all. :wink:
1- Create gerbers with default 0,0 offset
2- Open gerbers in ViewMate (free download-- google it)
3- Use ViewMate to determine how far the lower-left of your design is offset from 0,0 (I have found the horiz/vert offset is typically the same or close enough to use the same value).
4- Open the CAM processor, insert the corresponding negative coordinates in every layer and create new gerbers.
5- Verify the second set using ViewMate.
Viewmate will also show you what the silkscreen text looks like (which is really good since Eagle is not even close to WYSIWYG). When you submit to SFE, the size will be correct.
I see a box labeled Offset in the CAM processor which appears to be the thing, but there is one per layer. So I’d have to enter the offset 7 times? Surely, that isn’t right.
Of course its right-- this is Eagle we are talking about after all. :wink:
Thanks. That wasn’t obvious to me. One problem, though. Viewmate appears to be Windows-only. The closest thing I’ve been able to find for Linux is gerbv, which isn’t exactly feature-rich, AFAICT.
If I understood the actual problem a bit better, I could possibly write a batch tool which reads the gerbers, performs the adjustments, and spits out a corrected file. A bit awkward, but no more so than opening up a GUI app just to perform such an operation on a file. It would require a bit of reading on the Gerber file format, but I think I’m up to it.
Sorry-- didn’t realize about the ViewMate/Linux requirement.
Based on my experience, you can use 0.15 as a starting offset and that will get you close. All my offsets have been in the 0.15-0.18 range. Alternate technique:
1- Generate at 0,0 and submit to SFE
2- SFE will display the width/height it calculates
3- Figure out the actual width in Eagle
4- Set offset to Eagle_width-SFE_width
5- Regenerate gerber and resubmit. You will be right on.
The problem with this technique is that you are doing it blind. SFE will email a confirmation image which helps. Mind you, I have never deliberately set the negative offset really large to purposely chop the design and find out what happens (does it generate an error).
With respect to doing it via a program, it looks doable. Assuming you have the board diminsion on your component silkscreen layer (which is always good idea), you should be able to look at the .plc file. Looks to me like you find the smallest X and Y values, negate them and that will be the offset.
Vraz:
With respect to doing it via a program, it looks doable. Assuming you have the board diminsion on your component silkscreen layer (which is always good idea), you should be able to look at the .plc file. Looks to me like you find the smallest X and Y values, negate them and that will be the offset.
Almost. One must also take into account the size and shape of the apertures, I presume. But, yeah, that is the basic plan. I’ll have to have a stab at it. I already have a shell script that I use to zip the 7 files up. I could rewrite that and add the offset functionality.
How do you put the board dimension on the component silkscreen layer? When I run silk_gen.ulp, it copies the tplace and tname layers into the resulting tsilk layer, but anything that I explicitly put in to a layer such as tname or tplace does not get put there. I could explicitly draw a dimension line using tsilk, but that would get wiped out the next time I run silk_gen.ulp.
How do you put the board dimension on the component silkscreen layer? When I run silk_gen.ulp, it copies the tplace and tname layers into the resulting tsilk layer, but anything that I explicitly put in to a layer such as tname or tplace does not get put there.
The version of SFE-silk_gen I use came from Pryankster (documented w/link in the following thread):
It will copy the dimension layer to _tsink along with the component outlines/names. It also has a couple other optimizations for SFE board generation. Has worked great for me.
The only thing it doesn’t do is remove silkscreen data outside the dimension rectangle. You have to do that by hand else the SFE auto-sizer will use that in its calculation. Comes into play with certain connectors which partially hang off the board.
I see a box labeled Offset in the CAM processor which appears to be the thing, but there is one per layer. So I’d have to enter the offset 7 times? Surely, that isn’t right.
If you can live with using a fixed offset (e.g. -0.15), you can put the offset in 7 times, then do a Save-As (I called mine SFE-Special-X.cam). Thereafter you can re-use the saved job. If you don't want a fixed offset, you could make some different jobs with different offsets (e.g. SFE-Special-18.cam; saved with -0.18 offsets).