DSUB connectors exist within a mechanical context that is often just as important as making the pin connections. I argue that the reference point of a DSUB should be the center for mounting purposes rather than the center of pin 1. I had to fix this with two offsets which were:
I’m asking not for a centered footprint or any footprint to be designed for me, rather for a design philosophy change around what the spatial reference is for connectors of this type. I suppose you could add additional footprints centered in this way instead of changing how things are done. I have worked with DSUBs to the point of nausea (translated) and this is the way IMHO.
I also don’t like that pin 1 is the anchor point of a footprint. Flipping and rotating is difficult and useless around that pin, and I have done that often with THT footprints. Most often the center could be found easily.
At the moment the official library convention F7.2 Footprint anchor should placed at the location of Pin-1 - Library Conventions | KiCad EDA (for the official KiCad libraries) requires pin 1. I don’t know why. THT components aren’t assembled with the same machines than SMD components, so I understand why the center of the component isn’t the requirement, but I don’t know why pin 1 would be better.
I will try to do that. I would just go ahead now but my mind rebels about creating yet another login that I have to keep track of. Maybe more caffeine will break that logjam. Thanks.
What is the objection to using pin1 as the anchor point? I can see that for a DSUB connector the connector center represents the cable location along X and Y axes, but I am pretty happy with the anchor being at pin 1 for a 14 pin SOIC for example.
I note that IC datasheets are very inconsistent in the way footprints and packages are dimensioned. And I also have been inconsistent in that way with my own footprints. So it must be your fault.
I can’t rotate the footprint without it being totally misplaced. A generic pin header connector is symmetric along both axis, it could be rotated to change the footprint’s pad/pin order, but when the anchor is in the pad 1, it must be placed again after rotating.
I just don’t see any reason to have the anchor in pad 1, let alone a good one.
Perhaps it depends upon the way the designer thinks. IMHO the center of an SOIC is sort of a useless point aside from your rotation consideration. If pin 1 is located, then you have one significant location established. Also; let’s say we have a 16 pin IC. The IC pin pitch and your design grid are both 0.05 inches. If you place the IC center on your 0.05 inch grid, the pins will now be between the grids.
I do not mean to make too much of this. In practice, IC pin pitch is effectively “all over the map” and it is doubtful that you could design many reasonable boards while keeping all pins of the board on any sort of grid larger than 0.01 mm. So this gets back to more “depending upon how the designer thinks.”
I had some similar discussion with my neighbor WRT something mechanical and installing a dishwasher; center point location versus a corner.
Please understand that I do not have any strong opinions on this…
I suppose it is just a consistency thing… consistently being consistent rather than consistently being inconsistent.
Most footprints have a pin 1. The centre of a footprint can become debatable.
Where in the centre of a vertically mounted DSub compared to a horizontally mounted DSub?
Likewise a TO220 package, or a TO220 package with a folded centre leg. One package, three references, and none on a pin?
Never mind the librarians going hysterical, I’ll go hysterical!
It may be that the reference position THT footprints is for historical reasons, and kept in an attempt to keep consistent.
I think I like the origin of a part at the center of pin one.
It makes it easier to design the footprints themselves, because you can just place the first pin at (0, 0).
I do not care much for what happens to a footprint when you rotate it. When you rotate a footprint, or flip it to the other side then you also certainly have to move it, and also re-connect all wires.
And also, I much prefer a footprint to be completely off, then “just a little bit”. (For example not exactly centered). If the difference is small, then you may introduce subtle errors in your PCB without noticing it. If the difference is big, then it’s so obvious you can’t miss it.
When I use THT parts with a 2.54mm spacing, then i always put them on a 2.54mm grid. Maintaining this “vero board compatibility” has been useful in several occasion while making modifications to prototypes. (I know, DB connectors do not align on a 2.54mm grid anyway)
I do very much appreciate the consistency that the KLC brings If those rules change then this would create a lot of library headaches, and library maintenance is not a very fun part to begin with for people working on KiCad.
A relatively simple solution / workaround is to make a personal library for those DB footprints and modify them to your personal preferences.
While I can see this as a frustration source I personally don’t see as a big problem. There is a workaround available in V6. If you move the footprint before rotating it, it will grab either at the pin (1 or other closest one) or at the center of the footprint.
And having the library following a rule and then changing the rule is a significant change. I’d rather see the change in the KiCad’s code, so that direct rotation of the footprint works the same as moving a footprint (when you have footprint selected and then you hit M for move KiCad will grab the footprint at different point, with regards where the cursor is).
(With KiCad’s default settings) you can hover over a footprint, then press m for move.
The cursor then warps to the center of the footprint and is attached to the cursor. After that you can press r for rotate or f for flip and the center of the footprint stays the same as long as you do not move the mouse. Pressing [Enter] ends the move, so you do not even have to touch the mouse during the whole operation.
Just be careful not to bump your mouse.
One of my favorite jokes to get my PC out of screen saver mode when I had visitors was to make a very elaborate fist and hit my desk with it. This always caused the mouse to move a bit, my PC recognized this and went back from screensaver to normal desktop mode. The elaborate fist making and desk hitting has to be a bit of a show to distract people from the idea that the mouse could be moving. I have surprised several people this way.
In my case, the Atmega328 in a leaded part has inch spacing, but the crystal has metric spacing.
I edited the crystal from pin 1 anchor to center part anchor. This let me place the center of the crystal on the center of the two Atmega328 pins and have KiCad work the magic on the trace lengths.
Hi,
While I appreciate various suggestions for ways to to this within the existing methods, I think some people may miss the point I’m trying to make: in considering parts that have an external real-world interface to mechanical assemblies the use of pin 1 as a positioning anchor is just something that needs to be changed. While I could say that about many part classes I picked the DSUB because it is a particularly good example of how the existing convention serves the user community sub-optimally.
There is no general purpose mechanical CAD package that I know of that would automatically assign a pin 1 as a centroid, and if you are designing to fit an existing blueprint what you are likely to get is coordinates that relate to the mounting holes if anything.
I think people seem to think that I care about rotation in particular. I don’t actually but rotation is a clear example of one of the ways in which this convention delivers a poor result.
This is why I used the word philosophy. I don’t actually need a fix because I can just put a dozen numbers on a post-it note and solve all my DSUB positioning needs without asking anybody. Although I will constantly have to police the work to make sure the arbitrary numbers don’t change accidentally.
I wrote this post as a service to the user community, not myself so much, because I can see that this problem is actively not being considered or this decision would not have been left as it is. Perhaps there were bigger fish to fry when the developers were establishing these conventions. But the convention needs to be changed in my opinion as a user.
As far as the objections about the libraries, I stand by the statement that making this change for the DSUB type will cause more happiness than sadness, even taking into account the inconvenience that may attend a few users of DSUBS who get surprised. (That statement was made in my posting to the feature request github site.) I’ve suffered through using these parts for decades, starting with a point in time where I had to cut the DSUB holes in sheet aluminum myself.
This should cause the person who mentioned Vero boards to smile
I think that’s all I have to say except that I am a huge fanboy of this package and I’m grateful as hell that it exists.
From what I’ve found on this and other civil internet forums it sometimes takes a lot of words and letters to get your point across. The cause being different cultural backgrounds, different mother languages, and different level of English language knowledge.
With that said, I really appreciate your last post and I thank you for the extra effort. Before it, I mainly saw it as a complaint which could be solved by changing KiCad UI. Now I see your point and I acknowledge it. You have a point.
But I imagine that librarians will be really careful to change such a fundamental rule in KLC for a couple of reasons:
How do we update existing footprints
What is the criteria for THT footprint to put the anchor in the center.
If we put an anchor in the center, where in the center do we put it? With vertical DSUBs it is easy, in the middle of the rows of pins and at the center pin. But what about horizontal DSUBs?
The fundamental rules should be simple with as little (or even better none) exceptions.
And with limited manpower, I imagine that your issue will stay unaddressed unless somebody figures out a sensible answer at least to my considerations (and I’ve made them from the top of my head, I imagine there are more)
Are the trace lengths critical for this part of your design? I know that trace lengths can be critical with high speed data, but I have never paid attention to it for what I do.
@jmk gave 1-2 examples of footprints for which using a center point as the anchor makes no apparent sense. So apparently there is a need for both methods, and it sounds like too much to expect footprint librarians to always define the best anchor points. I do not see any good way around this disagreement other than making your own footprint that is anchored where you want. Fortunately it is usually not difficult to start with a standard library footprint and edit it to make your own. I almost entirely use my own footprints.
Yep,
Click your edit part icon
Find the part
Open it
Click the anchor place icon
Place the anchor point
Save as into personal library…all up: 40 seconds, worst case a minute?
Probably get 20 done in the time it takes to read this thread, depending on how much you fed your mouse for its last meal.
