Mail Archives: geda-user/2014/07/23/13:04:50
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
- Raw text -