X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Wed, 23 Jul 2014 19:04:22 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] Eagle .dru file definitions, anyone? In-Reply-To: <53CFCB9F.2050802@sonic.net> Message-ID: References: <53CF33CA DOT 802 AT sonic DOT net> <53CFCB9F DOT 2050802 AT sonic DOT net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 23 Jul 2014, Dave Curtis wrote: > On 07/22/2014 09:11 PM, gedau AT igor2 DOT repo DOT hu wrote: >> >> >> On Tue, 22 Jul 2014, Dave Curtis wrote: >> >>> Has anyone seen a description of the Eagle .dru (design rule) file? >>> >>> I notice that a lot of fab houses publish Eagle .dru files for their >>> process, and it might be a quick/easy project to create a .dru to PCB >>> design rule translator for most of the common/meaningful rules. >>> >>> It's a plain text file with a bunch of names and values, so it >>> wouldn't exactly be rocket science to reverse engineer, but I thought >>> someone might have run across a document on it. I haven't been able >>> to snag anything with Google. >> >> If it's that simple, we could write a script that creates/replaces the >> DRC part of a pcb save. Could you attach some examples? >> > > oshpark publishes their rules here: > https://oshpark.com/LaenPCBOrder.dru > > if you google for 'dru' you get more hits of fab house dru files than about > anything else. > > I don't really think it makes sense to modify the drc part of PCB's save, as > the two sets of design rule specs probably don't line up really well. But > maybe a "load rules from dru file" menu selection would be good -- it could > read a .dru file and pick out the pieces that make sense, then just go forward > with PCB in the normal way. There are two different things here: 1. how much the pcb drc and the information in a dru can be matched up; dru seems to be much more detailed. Extending PCB (feature-wise) to support more of these details probably would be a large effort. Finding out how to convert the information from the dru to PCB drc setup in a way that a drc-accepted PCB design won't voilate the dru seems to be easier. Of course because of the less detailed drc in PCB this also means a drc-accepted design won't exploit all possible limits. 2. once we have such PCB drc settings derived from the dru, we need to apply them to a design. Your suggestion is that it should happen within PCB; my suggestion was to have a separate script. At the end the two solutions would produce roughly the same effect, only the UI would differ: the design you are working on in PCB is the same thing that the design saved in the file. There is only one set of drc there. If you make pcb directly manipulate the in-core representation of the drc settings, they will be saved in the PCB file on the next save. Which is the same thing as if you have a script that modifes the saved file and the next time you load it in PCB it already has the new drc rules. At the end the drc section of the design is changed to match the dru. Unless you meant a second set of drc rules existing only while PCB is running and never saved, or direct support for dru on top of drc... But these are both the hard way mentioned in point 1. The file format seems to be simple. If someone collects the rules how to convert these values to pcb drc values, I can easily write a script that manipulates pcb saves. By rules I expect things like "PCB's drc somesetting should be equal to min(dru.x, dru.y, dru.z)." My fab house doesn't have dru, so it's not a feature I really need, so I wouldn't invest my own time in figuring the matching nor would I try to implement a more integrated solution, but can volunteer to write a small script. Regards, Tibor