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=message-id:date:from:subject:to:in-reply-to:mime-version
	:content-disposition:content-transfer-encoding;
	bh=HkSs+P4+ysjCp1/DPAAMVQoqx4NMZLLfvPEW7xOwfoQ=;
	b=SuIpO5jqerU0D53gPv7VgtsuntJMO/YR2hb7FmeX7H365uh/XcT+1LYP/Su0yTZL7+
	oozNJkuGVF8YVzRnuEQ2Z9VWM+sr9yIYZASKT3KozJ0+e92ySuoPsB7zMwbMAoL3ZWWf
	oKuhh6E50f5xbb+u0lKkNsZzybph6rhW9iPaGsmsgDKwcWEzKALyagoVkjDePWkNr4zG
	DpEzkUDHFB6G22KurtjY+AtV8CC6eEMUAjm++3e/nlz0QxdvwinD083ruIWAbZ4Epl4p
	dStShRqW9zT/F/GuwR+esDelZBw8avOexr2r5v87PDKDmfm+Y2scjO+ww9i/zYrIGBtm
	POwg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:message-id:date:from:subject:to:in-reply-to
	:mime-version:content-disposition:content-transfer-encoding;
	bh=HkSs+P4+ysjCp1/DPAAMVQoqx4NMZLLfvPEW7xOwfoQ=;
	b=Y00423RjwpflkvYkzytCOF9HguUeiuInWkTCzeE0mDu3flSwIV03YjAFfA24DylRbq
	CG5lsNYK5FRwAI9I3ekbVyRiP0SYP72PD0qXYb+unpFYzdSjdeLyyOOPP0exmnFDb2Zx
	EdYsgBImuyNhjD/3TwX7hUPNF4dN1BQOpoJKpYyUEHI0xii6UFs3HFAwfkyf4KdvEWAN
	Uba9QRqxAU+FZzbdN2jR+yBJGUaVot4K5VQ66U7YAPDggEzrEWn6J/0UwUYPE9TKElCO
	yple+BFu79PLTzaLuOyygyUitmpkQlEopEj4nO4pioPIzCHNbm2Wt3ksJZCVSeGgNiAF
	ip3w==
X-Gm-Message-State:	ABUngvcFWfZypqIwGkwlV6OgaU6GXK5MJ+I/j4zrqwXqebjFJvE2QXxa8255ttWlGgtO0A==
X-Received:	by 10.98.81.129 with SMTP id f123mr26235730pfb.36.1477360628805;
	Mon, 24 Oct 2016 18:57:08 -0700 (PDT)
Message-ID:	<580ebbf3.6bf5420a.ad13f.8d3a@mx.google.com>
X-Google-Original-Message-ID:	<1477360623 DOT 14116 DOT 19 AT zotlet.(none)>
Date:	Tue, 25 Oct 2016 14:57:03 +1300
From:	"Lilith Bryant (dark141 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] PCB rotation in xy (pick&place) file
To:	geda-user AT delorie DOT com
In-Reply-To:	<619287bf-4944-e9de-3b66-8914df2f9f88@mcmahill.net> (from
	geda-user AT delorie DOT com on Tue Oct 25 14:06:01 2016)
X-Mailer:	Balsa 2.5.1-79-g9697477
MIME-Version:	1.0
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u9P1vEpj026676
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

>  > On 2016-10-07 09:43:52 PM, michalwd1979 (michalwd1979 AT o2 DOT pl) [via 
> geda-user AT delorie DOT com] wrote:
>  >> Hello,   I need to provide pick&place file for a board that has some
>  >> elements rotated by 45 degrees. It turns out that pcb outputs only 
> 0, 90,
>  >> 180 and 270 degrees in the "rotation" filed of xy file. Is that
>  >> means that 45deg rotated elements are not supported by the exporter?
>  >> I've checked bom.c code and there is a "xy-fixed-rotation"
>  >> attribute, that does not seems to documented anywhere. Is that let me
>  >> manually enter any rotation for an element? Also code of xyToAngle() 
> suggest
>  >> that it supports only 0,90,etc degrees - what about arbitrary rotated
>  >> element?   Best regards,  Michael Widlok
>  >>
> 
> On 10/7/2016 6:02 AM, Lilith Bryant (dark141 AT gmail DOT com) [via 
> geda-user AT delorie DOT com] wrote:
> > Correct.  It exists (as a last resort) to get the nominated value into the
> > xy file.  Because the angle determination isn't very smart, and probably
> > can't ever be made smart enough.  Yes, in particular non-90'd rotations
> are
> > not handled automatically at all.
> >
> > There's also another undoc'ed attribute "xy-centre" which if you set to
> "origin"
> > changes the location written into the xy file to be the element's actual
> origin
> > rather than the element's "pad/pin centre of mass".  Which is needed for
> > BGAs/PGAs with missing corner pins.
> >
> 
> as the author of the 'not very smart' rotation code, I can confirm that 
> it is indeed limited although I'd characterize it as working with 
> limited/insufficient information!  I agree that it really can't be made 
> to handle other rotations because the information you'd need just isn't 
> available to the code.
> 
> The basic issue is that at the time (perhaps still currently), when you 
> rotate a footprint in PCB, the file stores a footprint which is a 
> rotated version of the original.  This is in contrast to storing the 
> original footprint along with a rotation to be applied when it is 
> placed.  The implication is that we really didn't have a mechanism to 
> keep track of rotation and so the approach I took was to basically look 
> at what quadrant pin #1 sits in with some code to try to do something 
> other than choke if pin #1 sits at the origin.  Oh, also, same issue 
> applies to origin.  At the time (perhaps still currently) we didn't have 
> something which definitively said what the origin of a footprint was so 
> I coded up the center of mass (assuming identical mass per pin).
> 
> I always wished for an approach which stored footprints unmodified, 
> along with some sort of pointer back to where it came from for footprint 
> updating, and then for each instance store rotation, refdes, refdes silk 
> rotation/offset from nominal, etc.  It seems that would have made the 
> rotation and origin for the x-y file be a non-issue or at least pushed 
> it to an issue with proper footprint creation.

For all it's limitations, I do actually like the "not very smart" scheme.  Since
my last round of changes to match IPC-73whatver, it does get it right a 
surprising amount of the time.   IPC-73whatever pretty much specifies what 
our "not very smart" code actually does.  i.e. assumes pin 1 is in one of the 
quadrants.   (BTW I did end up having to use slightly rotated quadrants, to
cope with multi pin components with pin 1 in the exact top-centre location,
e.g. some QFPs. - So the exact top-centre location falls into the "top-left-ish" 
quadrant)

Though perhaps if I did boards with 30/45 degree components, or single pin 
components I'd be less inclined to like it.

But anyway, since we do have element attributes, can't we just extend my 
little xy-fixed-rotation hack? (ok maybe rename it to something saner)   i.e. 
have the rotation functions go look for an "xy-fixed-rotation" attribute, and
go add N degrees to the value?   

If such an attribute is not found then use the existing code to guess an initial 
value,  which works most of the time, since the initial footprints are never 
initially rotated by non-90 amounts.

And presumably attributes can already be usefully added to footprint files?  
Though can't say I've ever tried it...   

If we had these two things running, wouldn't that cover pretty much 
everything needed? (except annotating the existing footprint libraries)

Lilith

- Raw text -