X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=Ca0tzycdFi2OseOm4wI1eTdn8XuAaLZeLAW42YDhmkU=;
	b=eGVLLpYLs5QwDukBnR0gCfLZJKoMpL64iaTfRxhCK7FTnIUSY2CHrOVymK3tFNDSEE
	+W4pipBsLGYn/nYMb0pnYV+QDrfpASKKdlKem34GHCRy+F3bKFw4nBLJW12ln8JRv5a1
	hDtqsX7z/RgTg+iHr4sOW/U7SqgjZar6jS9U9EJg0z7fXruy/yudYBUYRDUgb/Mwkewh
	wUvtGezVpXssUIopV7siJHP01YFwYWvfvGsvFmICBECM77XbCTsNOSac5AA8t8PbpMCF
	YfcAOYRmm0QvZzoiz3tkf+cF9IoKC0JKb4i4LXw5FIgGH5lq0rhIjESJBxzgcWiD7/5E
	5W5g==
MIME-Version:	1.0
X-Received:	by 10.182.245.167 with SMTP id xp7mr6551314obc.63.1450821734333;
	Tue, 22 Dec 2015 14:02:14 -0800 (PST)
In-Reply-To:	<20151222224041.45deaf70fe414a8c4cc3888f@gmail.com>
References:	<CAOFvGD6OiYxcGkOiQRVnvXW3TLs42bt7PE5Ot9s09hsukYicKA AT mail DOT gmail DOT com>
	<20151221030451 DOT 02399163eb3e40f21c622c41 AT gmail DOT com>
	<CAOP4iL1PTdeCZdT+SthHwQtaxC4x06MbBQmxRcK3DZyQ-jfw=Q AT mail DOT gmail DOT com>
	<20151221203331 DOT 20837 DOT qmail AT stuge DOT se>
	<CAJXU7q_XOJStJXhD547xW-+XROkBhctmMAWB-jm0cez5UvgZ7w AT mail DOT gmail DOT com>
	<CAOP4iL1ri4UMeYr01Af-AH005DkLboKO72nGao+ByGmqA51W-A AT mail DOT gmail DOT com>
	<20151222002012 DOT a88d7fe32a9336855eccd1d0 AT gmail DOT com>
	<CAJXU7q9dU=z5KZmgsh+Vau4zZNfEh4Awr5xdzL=6xhimLYVNLw AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512220421160 DOT 9035 AT igor2priv>
	<201512220412 DOT tBM4CJxb018546 AT envy DOT delorie DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512220528100 DOT 9035 AT igor2priv>
	<CAJXU7q89cBkSZZfaS5p2CSDeJRTGCzNs+bNBjL8_KYQ=o7gi=Q AT mail DOT gmail DOT com>
	<20151222153828 DOT 28d3996c10f3182c5efc780a AT gmail DOT com>
	<CAJXU7q826wCc69qaQ71Y=Yqrnxg-044GD4ZSViCYSmf1SMiNNw AT mail DOT gmail DOT com>
	<20151222204233 DOT 0ccc392762ac3ee53ed6bad0 AT gmail DOT com>
	<CAJXU7q8kTP6NqozYJm+MC_j7GqVXWJctznZx-VzmJiB4z6A4dw AT mail DOT gmail DOT com>
	<20151222224041 DOT 45deaf70fe414a8c4cc3888f AT gmail DOT com>
Date:	Tue, 22 Dec 2015 22:02:14 +0000
Message-ID:	<CAJXU7q8pAStTq6yTq6wOP4=MWBGfURP_KvdEYv-npLmRBmPufA@mail.gmail.com>
Subject:	Re: [geda-user] Prop ... Structure? (Clearance calculation)
From:	"Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA User Mailing List <geda-user AT delorie DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id tBMM2IYs017665
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

> Then there is the problem is there is an unconnected object within distance but I guess it could worked around if not already done by at least temporary assign all objects to a net.

I "think" this works ok, but I'm on a Win7 box with no PCB right now
to check... OK, no wait - I did install PCB (remember it also ports to
Win32 if you like masochism)...


So - it "nearly" works.. two tracks violating DRC clearance, on a
board with no netlist - no DRC results.
Throw down a via, and touch it to one of those tracks - and we see 1x
DRC violations - "Copper areas too close".

Bug - one I'm sure could be fixed. We're probably just not iterating
over all of the non "PV" type objects as potential DRC check
start-points. (DRC draws a distinction between the in-layer objects
like lines, arcs, polygons etc.. and the "PV" type objects (pin, via),
which can traverse layers..

> Step 1 may would be really good but a net attribute would be a good start. Then is the question if attribute should specify clearance value or voltage. It would also be possible to use units like this: clearance = "0.3mm" , "25mil", "250Vac", "45Vdc" and it would be possible to later add functionality to automatically assign the net clearance attribute from pin values.

For design intent, voltage is important - but ideally, specify it in a
more semantic way.

Aside: I could write voltage=250V with the correct AP210 primitives,
but it would probably take a page worth of boilerplate to define the
SI unit quantities, specify tolerances, define the property of the
object, instancing an instance of the property, mapping it onto the
object owning the property, assigning it a value etc...
I'm mocking STEP and its complexity - this genuinely is an almost fair
representation of how it defines properties... but there is a reason
why they do it this way. (Not entirely sure I know the reason though
;)).

Ultimately, PCB should not work from voltages. This is the same reason
I don't want to derive computed outlines from content on the "outline"
layer - once you've implemented an algorithm, you're stuck with it.

By all means, add attributes such as voltage, and have helper actions
to operate on those (and perhaps produce clearance attributes).


The safe option is to specify pairwise clearances between nets, (or
groups of nets). This way, the designer can set, and/or check them.
Regulatory requirements aren't always exact based upon voltages...
often they are arbitrary distances if the voltage is in range a<V<=b.
The distance will almost certainly ALSO depend on the environmental
class, PCB coating technology, isolation requirement (double insulated
/ functional / ....).

Whilst you could throw in a calculator for such things - your
calculator would never be the normative standard reference. There is
one online here... http://www.creepage.com/
Looks like they got permission from the IEC to use the required
standard data. Note the disclaimer "Consult with IEC 60950 for all
final design decisions" etc...


>> Let me know if I can be of any help if you decide to proceed. Its been
>> a while since I braved PCB's DRC code, but I was at one point familiar
>> with it.
>>
>> Peter
>
> Can you figure which objects belong to which net?

Give me an example of what you mean, and I will try...

Do you mean like the "f" action to highlight connected objects?

You'd start with that code, but seed it with a first object you know
is in the netlist for a given net. (I hacked that some while back to
add the green / purple coloring distinction between whether the object
_IS_ connected, or _SHOULD BE_ connected to a given starting point.
(Got burnt by a design error overlooked by that distinction being
missing before!).

I'll warn you that the code is fairly horrid. I think it lives in
"find.c", with the dragons.

Peter

- Raw text -