Gerbv

Anyone using Gerbv as a Gerber viewer? I'm having a problem where a few dr ill locations in a drill file look out of location. I seem to have narrowe d the problem to the use of trailing zero suppression. I can verify the dr ill file (which contains only line feeds it appears, so not so easy to view ) has a few entries with the trailing zero suppressed. In Gerbv these are all being interpreted as if zero suppression were off. In fact, it tells m e when it translates automatically, it is using no zero suppression. If I manually turn on trailing zero suppression it so munges the drill file that no drill show up on the screen at all and if I click the zoom to extents b utton it takes me far off the board and shows me a small area with no visib le features.

Is this broken in Gerbv? I'm going to ask the fab house to turn off zero s uppression and see if that fixes the problem at my end.

Rick C.

Reply to
gnuarm.deletethisbit
Loading thread data ...

Wow, I'm kind of mystified. Without decimals, you have to specify how many digits are left and right of the implied decimal point.

On GERBER files, for the photoplotting, it is traditional to suppress LEADING zeroes, and there is a format specifier line, which should look something like :

%FSLAX24Y24*% This means there are 2 decimals left of the implied point, and 4 to the right. So, X12345Y123456 means X=1.2345 and Y=12.3456

But, looking at some of my drill files, there does't seem to be a format specifier line! I always thought there was one. All I have in it is : M72 M48

And, then, gives the drill sizes, selects the first tool and starts with the coordinates. I'm amazed this works without a format specifier. The Excellon format does allow for a format line, which can look like : INCH,LZ

which means units are inches, and leading zeroes are INCLUDED. You might try adding this below the M48 line and see if GERBV works better. (METRIC and TZ are the other options)

Jon

Reply to
Jon Elson

w
t

g
t

That seems to have done the trick. Thanks.

I recall a decade or two ago the IPC tried to develop a standard that would incorporate all the PWB design data into a single file to eliminate many o f the problems we encounter in interpreting the file formats as well as inc lude much more information that has to be conveyed in text files now. But it seems no one was interested in actually bothering to use such a beast. The PWB industry sucks!

Rick C.

Reply to
gnuarm.deletethisbit

Glad it helped.

That would erase much (or at least some) of the proprietary nature of EDA software - NO surprise the EDA vendors did not want it.

Yes, it is a "tired" old industry, with very little innovation in the last ** 20 ** years! I'm still using Protel 99SE, and have seen very little that improves on it. It does look like KiCAD might be catching up, but as long as I can still get Protel 99 to run on a VM, I'm happy.

Jon

Reply to
Jon Elson

d

I don't see how that is true. I don't think the software vendors would aba ndon their internal formats, just the communications between the design sid e and the fabrication/assembly side.

I was a bit disappointed with an assembly house the other day. It had been nearly a week since I gave them the PO after they had found parts and quot ed. With the present allocation it is important to grab the parts you find as soon as you can. They had not even started to buy parts because the da ta hadn't been entered into their ERP system. If it takes that long to ent er the data for 35 parts, I think something is wrong with the system!

I'm still running Eudora for email. I've yet to see any reason to change.

Rick C.

Reply to
gnuarm.deletethisbit

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.