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=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding;
	bh=iJpKJmiZJ7tkXNPEa+p9T4jkZRamzNGv8wYonge5dWQ=;
	b=RnL3a7yyNKKRUf2UN3O+RGsrFs1ZKIivGgK+PzjYtIpUXmlKkcc56DAYEcM8gbPf97
	0zXc2ZVu6zq6AQxCCl1wVC1Zx/qNFFL7pTDbJS3/xFnP6e3Fd9oxXEbrJnF7Q7HjUHzT
	UGnCewqJ/GAAMaLnRN+q6yxkfYnuWzSifAiQn5d7XXerkuUI01L/T1/Q+0pyjVDAI4Uv
	ajYIFlGeEMkhEa1+sUwmsUayt6dOtUc/avvrOwaV50BazeZxpK3tR+6ptCgaeVXdrTu0
	JAdmSscI5YFof2e2r006Asm4mxSTLLNQVHz8ZPP2hiX/QXsLxwsaVHudf7DbkQ1LrYwx
	dEng==
X-Received:	by 10.194.216.100 with SMTP id op4mr15589249wjc.85.1450820443251;
	Tue, 22 Dec 2015 13:40:43 -0800 (PST)
Date:	Tue, 22 Dec 2015 22:40:41 +0100
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Prop ... Structure? (Clearance calculation)
Message-Id:	<20151222224041.45deaf70fe414a8c4cc3888f@gmail.com>
In-Reply-To:	<CAJXU7q8kTP6NqozYJm+MC_j7GqVXWJctznZx-VzmJiB4z6A4dw@mail.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>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
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

> > Only real problems I could find is copper overlap and clearance. What pcb really lack is different clearance between different nets. Implementing stuff like selection of clearance and trace width from net attributes or similar should be straight forward although their may be a lot of arguing about best method to implement.

> How PCB works this out, is by bloating individual net elements, and
> checking to see if by enlarging the track by the minimum DRC
> clearance, whether or not it changes the netlist connectivity. (E.g.
> if this track were fatter by 0.5mm, would it change the netlist ->
> clearance must be <0.5mm).
> 
> Actually working out the minimum distance would take some more
> creative algorithms I think - although should not be overwhelmingly
> different.

Something within clearance distance as now should be good enough.

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.

> Regarding net-classes and clearances... this has LONG been on my
> wishlist... I would love if you wanted to implement it.

net-classes should be strait forward as soon as clearance calculation work which is probably already do and it is known which objects are connected to the net:
  1. Find which object is connected to each net or the opposite direction find which net all objects are connected to.
  2. Read net class or clearance attribute for each net and set clearance to this value.

If algorithm is slow I guess multi threading would be good so that moving object do not slow down but I also guess it may add development time and in such case it is more important get it done without than nothing.

> The case I'd have was PSUs, where you might have line-side connected
> nets, and secondary-side connected nets. You would then specify a
> clearance between the groups (derived from the regulatory rules).

For PSUs there there may be problem with responsibility so I guess it could be a good idea to add a note calculations are not realiable in case somebody get killed because they trusted pcb make calculations correct. The law is different between countries and I am not competent in this area.

> For me:
> Step 1 is figure out how to specify the driving data.
> Step 2 is add this to the internal data model
> Step 3 is provide ways to load (and possibly save) the data
> Step 4 is provide a DRC check to test against the data
> Step 5 is update / tweak online DRC checks to show / enforce clearance
> requirements during actual tracking

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.

> 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?

- Raw text -