Something I’ve noticed in the newer footprints is using a short/long line to denote polarity, this is confusing to my fab, and a 1pin dot has always been easy and straight foward so not sure why the short/long line started being used in place of something more widely recognized.
Also of someone inadvertently deletes one of the lines from the gerber file… there’s a 50/50 shot they get the polarity wrong instead of always catching that the dot polarity marker went missing.
This is due to ipc-7351
I should think not as IPC-7351 clearly shows components with dot polarity indicators.
As far as I can see they dont’ even specify such indicator for quad packages… opting for the dot there also.
Well, if your company requires strict adherence to such standards, so be it, but if you make your own symbols, you can do anything you want:
Obviously… the point that was at some point this changed for the worse for no apparent reason?
In this case it was only 25 boards, but I just ordered 1200 boards with the same part… thankfully they appear to be correct on that order.
Edit: hmmm, I don’t seem to find the correct thread, wait a minute…
Ok, here: DFN Placement Disaster
I can see in that thread you linked to that there was an issue opened on GitLab then (9 months ago) and it’s still active (not solved) 
I think it was made clear that this is not going to be “fixed” because they decided to stay close to existing standards, and the mentioned IPC document has been the best of the candidates.
Solution: create your own libraries, copy the KiCad defaults to them and modify them.
Oh. I didn’t spotted that in the issue discussion.
So the issue should be closed in GitLab if it’s not going to be fixed.
I’ve got nothing to do creating my own footprints / libraries (which I do anyway).
However inconsistency in the official KiCAD library is annoying, especially for new users.
Most of footprints are scripted anyway, so easy to keep the same standard or easy to fix if it was previously done with a different standard.
If there any “preferred” standard for silkscreen? Asking as I recently sent a few merge requests for footprints and 3d models. On footprints I based on similar already existing footprints, but perhaps they didn’t follow the standards as well.
Once I have done a mistake and I marked the pin 1 of 4-pin SMD diode bridge. Different manufacturers of compatible bridges show them differently in their datasheets, and frequently even not specify which pin is 1. The effect was we got 100 PCBs with that bridge mounded inversely.
We were very close to sending these boards to customers because, surprisingly, they worked.
This bridge was used in RS485 differential line protection and wrongly installed it only limited the output voltage what was not a problem for RS485 at short distances.
Now I use +,-,~,~ marking on that bridges.
I have never read any standard for it but we use short line at CrtYd rectangle corner (crossing through pin 1) since always (means - about 1990). At PCB we didn’t used any marking for polarity (for many years (before I moved to KiCad) we ordered PCBs without silkscreen). The polarity is visible in pdf documentation we send to contract manufacturer.
I think that silkscreen dot used to mark pin 1 can collide with footprint located next to. I am frequently limited with the space at PCB so in footprints I do CrtYd rectangles with no extra space inside and all what will be at PCB have to be inside it (I have never placed element references (R1,…) at PCB).
I really don’t like the polarity markings with dots and or * as they too often conflict with other footprints when you have tight placement. therefore I use the longer line to mark pin 1 on SO packages as well and for QFN, BGA and the likes I mark the corner where pin 1 is with a second silkscreen corner.
I had problems with all methods in the past so now I just use which I think looks best/most reliable but also make sure to inform the populator about the used syntax.
Silkscreen printing is optional … There is no standard for its placement … It’s like any of your personal entries on the board … The underlying file is bom …
A normal contract manufacturer never relies on screen printing. Machine vision works there for manual assembly, there is an assembly drawing
I understand that. It doesn’t mean we have to have the inconsistency in the official KiCAD library.
Yes a corner silkscreen mark inside the footprint courtyard would be even better than a dot, the 2 lines short and long is the worst of the 3 suggested ways so far though.
The short and long line don’t seem to have anything to do with the IPC spec though I haven’t seen anyone mentioning it even using that. So I am not sure why people keep saying that is why it was done that way when it seems that isn’t the case at all.
Small local PCB houses don’t have machine vision systems often enough. I’m sure they will as time goes on but, adoption is going to be slower. And there is value for manufacturers like where I work in using local houses over large out of state/region companies. I’m literally a 15min drive from the PCB house I use.
Then why isn’t it doing that… everywhere I see that IPC spec being used it certainly isn’t using a long/short line. Shrugs I dunno… I just brought this up as it seems like low hanging fruit honestly. the corner mark or dot are both fairly obvious as superior to the lines, as far as being visually unambiguous and avoiding human error. The line I can only see as useful for hand soldering perhaps…
And I do make my own footprints for a few things, like an oddball DFN OSC I use… that has a bold corner to its outline in my footprint.
I don’t know what kind of marking you are speaking about.
How does silkscreen help in this case? This is a picture that can be with errors, unlike an assembly drawing… Now is not the 19th century to collect on papers or layouts… for everyone else there is a pick and place document
Did you read the post in the other thread DFN Placement Disaster - #24 by Evan_Shultz (direct link to the post)? The situation is a little bit more complicated than that some public standard would tell everything.
I don’t defend that decision at all, but there just isn’t any better solution which would make everyone happy.
The users can try to vote for an issue and see if it makes any difference. I already gave a proposition in that forum thread which in my opinion would be a good compromise.