Mail Archives: geda-user/2015/08/17/18:06:53
> A lot of this doesn't make sense. I'm hearing 2 things.
As a bit of background, consider that the original footprint "file"
allowed more than one footprint, and we use the same information for
cut buffers and "save buffer to file" stuff. Each pcb, paste buffer,
and file has its own local coordinate system, and cutting and pasting
translates between those coordinate systems.
> 1) If the 0,0 origin coordinates are an absolute position from the
Keep in mind the difference between a footprint and an element.
A footprint is a pattern in a library.
An element is a specified instance of a footprint along with other
information.
So it makes no sense to talk about the "origin" of a footprint - it's
in a library, it's just a pattern, the only magic about the origin is
that it's the mathematical 0,0 point that other things in the
footprint are measured from.
When you paste a footprint onto a pcb it becomes an element. At that
point, the 0,0 of the footprint is mapped to wherever the crosshair
is, and becomes the "location" of the element.
> But that doesn't happen when you import schematics to the PCB.
Actually it does if you use gsch2pcb. The File->Import method
relocates every element so that they're not all up in the corner.
> The diamond shape origin is in the center of this 805 component - no
> matter where this component is randomly placed onto the PCB grid.
> The component origin cannot be linked to absolute PCB coordinates.
The element's internal measurements are all relative to the element's
origin, as if it had its own local coordinate system. We do this just
to keep the internal logic easier. We *used* to keep the internal
coordinates absolute, and had to recalculate the position of every
pin, pad, and silk every time you moved the element.
> 2) I thought I heard that the origin written to the footprint file,
> happens to be the absolute position of the cursor when captured into
> the buffer.
When you're editing a footprint via pcb, at one point you "cut
selected objects to buffer". At that moment, the location of the
crosshair becomes the 0,0 point for the coordinate system that the cut
buffer uses. If you paste the buffer as-is, you'll notice that the
"ghost" image before you click is relative to the crosshair in the
same way it was relative to when you cut it.
When you convert a buffer to a footprint, the footprint is created
relative to the 0,0 of the buffer, of course. The *net* result is
that the location of the crosshair when you initially cut it becomes
the origin of the footprint.
> How and why would anyone create parts at 0,0 in the extreme upper
> left corner of a PCB?
Again, elements vs footprints. A footprint should have a reasonable
0,0 point and should be stored with a 0,0 in the Element[] coordinate
slot.
Once on a pcb, it's not a footprint, it's an element, and the
"location" information in the Element[] coordinate slot is used to
keep track of its location.
> I am guessing that the origin
> coordinates written to the footprint file, are related to relative
> coordinates based on a local origin and the cursor position.
If you happen to have something other than 0,0 in the footprint file,
when you paste that footprint onto the pcb, it will be pasted away
from the crosshair by that amount. *After* it's pasted, that
coordinate will be updated to be the new location of the element.
> BUT - and this is the kicker - it does not seem to matter if you
> have an non-zero offset in your footprint file.
That would make sense, since the coordinates in the footprint file
only have a real meaning after you place it on a pcb.
It's possible to have more than one Element[] in a footprint file, but
we discourage that ;-)
- Raw text -