Mail Archives: geda-user/2016/10/24/21:09:07
> 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.
-Dan
- Raw text -