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.berna...@gmail.com> wrote: > On Thu, Jun 16, 2016 at 10:22 PM, Wayne Stambaugh <stambau...@gmail.com> > 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.marcanto...@cz-dynamic.it <mailto:l.marcanto...@cz-dynamic.it>> >> 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@lists.launchpad.net >> > <mailto:kicad-developers@lists.launchpad.net> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> > >> > >> > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~kicad-developers >> > Post to : kicad-developers@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> > >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp