kicad-developers team mailing list archive

[Thiadmer Riemersma <thiadmer.riemersma@xxxxxxxxx>]

My company makes VisualPlace, which is used to prepare production files for
hand or machine assembly. (Don't worry about the shameless plug, it is a
free program.)

Standard IPC-7351 describes the "normal" orientation of the components on
the PCB. It is equivalent to IEC 61188-7 "Level A". These standards also
say that pin 1 is the cathode on diodes and the plus pole on polarized
capacitors (for example).

EIA-481 defines how components are packaged in tape. There are three
problems with this standard: 1) it is a moving target and different
versions conflict with each other, 2) it is ambiguous for less common
shapes, such as 4-pin or 6-pin PLCC LED packages, and 3) there is a lack of
commitment from the component manufacturers to implement it. However, for
the discussion of the component position file, EIA-481 is irrelevant.

There is no prevalent standard for the format of the position file. There
is IPC-2531 "Standard Recipe File Format", but hardly anyone supports it.
Different EDA programs give different names to the fields, but this has in
my experience never been a problem.

The position of pin 1 (from which the orientation of the component can be
established) is in fact not a problem of the file format. The orientation
is in the component position file and there is a good, established standard
on how that orientation should be interpreted (IPC-7351).

But... if a footprint in the library is drawn in a way that does not comply
with IPC-7351 (regarding is normal orientation), the wrong rotation is
written in the component position file. For example, version 3 of KiCad
defined pin 1 on a diode as the anode and this has led to diodes and LEDs
being mounted in reverse on boards that we had assembled.

Having the position of pin 1 also in the component position file can help
catch some of those situations. But, two notes: 1) the IPC-D-356 netlist
file also maps pin numbers to coordinates, so modifying the component
position file only adds to convenience (one less file to hand to the
assembly house), and 2) it does not help you against the example that I
gave (of the diode that maps pin 1 to the anode and pin 2 to the cathode).

Regards,
Thiadmer Riemersma

On Mon, Jun 20, 2016 at 6:57 AM, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>
wrote:

> On Thu, Jun 16, 2016 at 10:22 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
>
>> My preference is to define a reference position parameter for the
>> footprint this way it could be any position the user chooses.  There may
>> be reasons to use values other than pin 1 or the center of the
>> footprint.  That one part that never seems to auto insert correctly
>> comes to mind.  If you've done enough AI, you know what I'm talking
>> about.  If the reference position is not defined, the center of the
>> footprint is used.
>>
>>
> I'll need some coaching on what various columns in centroid files mean.
> In most centroid files I've seen there is only a "PosX, PosY" but some
> have "RefX,RefY,CenterX,CenterY,PadX,PadY".
>
> Now is it "RefX,RefY" which correspond to "PosX,PosY" or is it
> "CenterX,CenterY"? Presumably the other coordinate specifies
> the true centroid location as opposed to the footprint's nominal
> location, but this still doesn't help us unambiguously determine
> the Reference Pin Orientation.
>
> Anyway, if I read you correctly, the "Reference Position" parameter
> would require a change in the PCB file format since it would be
> an offset relative to the footprint's nominal position. If we're going
> to make a change to the PCB file format itself I think we'd need to
> be very clear on what's written by the Position Export and how we
> determine what columns will be written and how to respond to
> missing data (Reference Pin).
>
> - Cirilo
>
>
>> On 6/16/2016 3:14 AM, Cirilo Bernardo wrote:
>> > I will look into this; we can name any unreserved footprint property as
>> > "RefPin" (do we translate it?) and if the pin exists then we can
>> generate
>> > the PinX PinY values in the centroid. The issue now is when do we output
>> > PinX, PinY columns and how do we handle the case where a user may
>> > have forgotten to explicitly define the RefPin on some parts?
>> >
>> > - Cirilo
>> >
>> >
>> > On Thu, Jun 16, 2016 at 4:13 PM, Lorenzo Marcantonio
>> > <l.marcantonio@xxxxxxxxxxxxx <mailto:l.marcantonio@xxxxxxxxxxxxx>>
>> wrote:
>> >
>> >     On Wed, Jun 15, 2016 at 07:12:50PM +0300, Eldar Khayrullin wrote:
>> >     > It will be good if it will be selectable as option
>> >
>> >     Not an option, make it explicitly *select* the pin 1 for
>> orientation, it
>> >     will save troubles!
>> >
>> >     Adding it to the footprint properties would be the easiest IMHO
>> >
>> >     --
>> >     Lorenzo Marcantonio
>> >     CZ Srl - Parma
>> >
>> >     _______________________________________________
>> >     Mailing list: https://launchpad.net/~kicad-developers
>> >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> >     Unsubscribe : https://launchpad.net/~kicad-developers
>> >     More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>