Add Diode Outline packages

[ii8]

Is there a better way to have various versions of placement and docu layers for the same package? I've just made separate packages here for unidirectional and bidirectional diodes but I wonder if there is a better/preferred way.

[rnestler]

@ubruhin Maybe you can answer the question:

Is there a better way to have various versions of placement and docu layers for the same package? I've just made separate packages here for unidirectional and bidirectional diodes but I wonder if there is a better/preferred way.

[ubruhin]

Awesome, thanks for the contribution @ii8! 🎉

I'll try to review the PR in detail soon.

I've just made separate packages here for unidirectional and bidirectional diodes but I wonder if there is a better/preferred way.

Sounds good to me - since the 3D models will be different, it makes sense to create separate packages 👍

[ubruhin]

Finally I reviewed this PR, sorry for the long delay.

This is really fantastic work @ii8! The packages are conforming to our library conventions, their dimensions are correct and they look nice 👍

The only thing which doesn't follow IPC-7351 is the naming. The suggested naming pattern is:

But unfortunately I'm confused about whether the nominal or the maximum height should be specified. These IPC diode package names seem to be used very rarely, I've found almost no references in the Internet. And the few references I've found are sometimes specifying the nominal total height, sometimes the nominal body height, and sometimes the maximum height 😭

With nominal body height:

• DIOM5436X215 / DIONM5436X215
• DIOM7959X215 / DIONM7959X215
• DIOM5226X230 / DIONM5226X230
• DIOM5226X280 / DIONM5226X280

With nominal total height:

• DIOM5436X230 / DIONM5436X230
• DIOM7959X230 / DIONM7959X230
• DIOM5226X240 / DIONM5226X240
• DIOM5226X295 / DIONM5226X295

With maximum height:

• DIOM5436X265 / DIONM5436X265
• DIOM7959X265 / DIONM7959X265
• DIOM5226X290 / DIONM5226X290
• DIOM5226X350 / DIONM5226X350

I'm really not sure how we should name them. If we're not sure which is correct, maybe the best is to keep the current naming. Any opinions welcome (cc @dbrgn), otherwise I'd merge this with the current naming.

[ii8]

Following standards is nice, but from a practical perspective I think these packages will be much easier to find if they have the names that are commonly used for them. I actually duplicated SOT23-5/6 in my local library because in the base library I found the SOT23-3 but didn't notice the 5 and 6 pin packages because their names are completely different.
Also it's a little annoying that you need a not libre at all, pay-walled standard to work on LibrePCB.
I don't have a strong opinion, it's just my thoughts.

[ubruhin]

Yeah I totally agree the naming is a mess, and IPC7351 is somehow annoying as it is not free, it sometimes completely reverts recommendations made in previous revisions, and the de-facto standard IPC7351C has never been released and we don't know if it will ever be.

But unfortunately there's no other/better/free standard. Also the commonly used names (like DO-214) are a mess as they are sometimes used wrongly by manufacturers, they appear in different standards with different dimensions, or manufacturer give them their own name although they are defined in a standard. So these names sometimes cause troubles and confusion as well.

The IPC naming at least has the advantage that it is expressive and consistent, while something like DO-214 is not expressive nor consistent at all. For example from the name DIOM5436X215 you know (with some experience) it is a molded polarized diode with dimension 5.4x3.6x2.15mm. Same applies to all the other IPC namings.

But as I wrote above, in this case I'd be fine with keeping the current naming as it's not clear what the correct IPC names would be 😭

[dbrgn]

But unfortunately I'm confused about whether the nominal or the maximum height should be specified.

Well, but that's the case for all land pattern names, right?

Intuitively, I'd use the nominal height. How do we handle it in other packages that we generate?

For DFN, we use the nominal height:

librepcb-parts-generator/generate_dfn.py

Line 85 in 3e792ac

height=fd(config.height_nominal),

However, we don't have a max height in that file.

For QFP we use nominal as well, even though the max height is available:

librepcb-parts-generator/generate_qfp.py

Line 110 in 3e792ac

fd(self.height_nom),

I'd go with IPC names, due to the reasons you listed ("The IPC naming at least has the advantage that it is expressive and consistent"). If we wanted to list alternative names in packages as well, we could extend the library format for a dedicated field (or put them in the keywords and/or description).

Ah, and regarding body height vs total height: I think it's pretty clear that "Body Width X Height" means "Body Width X Body Height".

[ubruhin]

I'd go with IPC names

Alright, thanks for that clear opinion - so let's do it this way 🙂

Intuitively, I'd use the nominal height. How do we handle it in other packages that we generate?

I'd go with nominal height as well, but not all standards define that value. For example JEDEC MO-152C only specifies the maximum height for SSOP, and that's the value our generator uses for the name.

Ah, and regarding body height vs total height: I think it's pretty clear that "Body Width X Height" means "Body Width X Body Height".

Here I disagree 🙈 I think the total height is much more important than the body height while the space between PCB and package body is not relevant for mechanical aspects of a PCB. At least some of our generators are using the total height as well. But in the end the difference is <0.3mm anyway so probably not worth to think too much about that...

So my suggestion would be to use the nominal total height, i.e.:

• AA: DIOM5436X230 / DIONM5436X230
• AB: DIOM7959X230 / DIONM7959X230
• AC: DIOM5226X240 / DIONM5226X240
• BA: DIOM5226X295 / DIONM5226X295

I think these packages will be much easier to find if they have the names that are commonly used for them.

For this reason, the name "DO-214x" (and ideally also "DO214x") should be added to the keywords to make the corresponding package showing up when searching for DO-214. Also I'd put the DO-214x into the description.

@ii8 Sorry about the inconveniences due to this discussion. Would you be willing to implement the new naming? Otherwise I could take over this task, just let me know.

[dbrgn]

Here I disagree 🙈 I think the total height is much more important than the body height while the space between PCB and package body is not relevant for mechanical aspects of a PCB.

Ah, I always assumed that for SMD parts the body is directly on top of the PCB, so body height and total height should be the same. But that probably depends on the actual part.

[ii8]

I can change the names but I have some questions.

• AA: DIOM5436X230 / DIONM5436X230
• AB: DIOM7959X230 / DIONM7959X230
• AC: DIOM5226X240 / DIONM5226X240
• BA: DIOM5226X295 / DIONM5226X295

You are using the total length here instead of the body length like the standard says, is that intentional?
Also, why are the numbers truncated? 5.25 becomes 52, that looks weird to me.
And are the units really supposed to be inconsistent? 0.1mm for the length and width but 0.01mm for the height.

[ubruhin]

You are using the total length here instead of the body length like the standard says, is that intentional?

Basically it's because I've found a few other references in the internet to these package names when using the total length, but none when using the body length. The total length is also more relevant for us and IMHO the standard is not clear enough about the term "body length". I mean, for a package like LQFP it's clear that only the mold is the body, but for a J-Lead package there's no space between leads and body so one could consider it as just a single body. But that's just my opinion 😉

The references I've found in the Internet:

• https://www.pcb-3d.com/wordpress/electric_type/diodes-molded-polarized-diom/
• https://www.ti.com/lit/df/tidrcc0/tidrcc0.pdf?ts=1691851084007&ref_url=https%253A%252F%252Fwww.google.com%252F
• https://gitlab.com/claudiunv/kicad-pcblib/-/tree/master/IPC7351-Least.pretty

I would understand if you prefer using the body length (without leads) but then I'd ask for @dbrgn's opinion as well 🙈

Also, why are the numbers truncated? 5.25 becomes 52, that looks weird to me.

This is documented here:

All Lead Span and Height numbers go two places past the decimal point and “include” trailing Zeros
All Lead Span and Body Sizes go two place before the decimal point and “remove” leading Zeros

[ii8]

This is documented here

I don't get it at all.
How does All Lead Span and Height numbers go two places past the decimal point and “include” trailing Zeros
mean the integer part of (the height in mm multiplied by 100)

and All Lead Span and Body Sizes go two place before the decimal point and “remove” leading Zeros
mean the integer part of (the width/length in mm multiplied by 10)?

Or is that not right? But it doesn't matter I'll just name them the way you wrote them.

I'm guessing this function isn't quite right though. It rounds instead of truncating and it ignores it's second argument:

https://github.com/LibrePCB/librepcb-parts-generator/blob/3e792ac619bb80b8be7543d546e2a7d892068095/common.py#L58C1-L65

[ubruhin]

I don't get it at all.

Ah sorry I missed to copy the third line:

All Chip Component Body Sizes are one place to each side of the decimal point

But here again the standard is not 100% clear IMO. Does "Body Sizes" include the height? What is meant which "chip component"? Does it apply to J-Lead bodies? I have no idea...

I'm guessing this function isn't quite right though. It rounds instead of truncating and it ignores it's second argument:

Arghh 😭 But again one more question arises, does IPC tell something about rounding vs. truncating? I am not aware of that... I'd find rounding more reasonable but in the DIOM* references I've found they all just truncated the decimals.

At least LibrePCB does not rely on names so no matter how we name them now, if we know better some day in future we can just rename them without any consequences 😉 By mentioning the JEDEC names in the description it is clear anyway what packages they represent.

[ii8]

Ah sorry I missed to copy the third line:

No problem I saw that line in the document you linked, but I thought it wasn't relevant to these packages because it says "chip component" like you mention. Even if it is, I don't know what it means anyway. What is "one place to each side of the decimal point" trying to describe? Does it mean floor(d * 10) mod 100 where d is the size in question? That would be kind of strange but I don't know how else to interpret it.

I pushed code btw, not sure if you noticed.

[dbrgn]

Some background information on IPC can be found here: https://www.pcblibraries.com/forum/ipc7351c-draft-or-release-date_topic1818_page1.html (3 pages)

In the end the standard is unclear in a lot of cases. That leads to naming inconsistencies between vendors.

I don't think LibrePCB must match the names of other vendors exactly. We just need a consistent system that we can follow. The name is just a bit of help to find the correct part, it's not its specification, so minor deviations are fine.

If we wanted some external knowledge about the naming, we could open a thread in the pcblibraries.com forum. Tom put a lot of time and effort into these draft documents, and he usually has good ideas on how to handle these cases.

(This gets a bit offtopic, but maybe we should "fork" the IPC6351C naming schema (which at the moment is essentially just the "PCB Footprint Expert naming schema") and make our own, with improved specs and guidelines on how to name things.)

[ubruhin]

No problem I saw that line in the document you linked, but I thought it wasn't relevant to these packages because it says "chip component" like you mention. Even if it is, I don't know what it means anyway. What is "one place to each side of the decimal point" trying to describe? Does it mean floor(d * 10) mod 100 where d is the size in question? That would be kind of strange but I don't know how else to interpret it.

I pushed code btw, not sure if you noticed.

I saw that the change in format_ipc_dimension() does rename some existing packages, thus the UUID cache needs to be updated as well. I took over this task in a separate pr: #107

By the way, I have now realized that pcblibraries.com provides a much more complete naming convention:

In this convention, the DIOM pattern looks much more consistent and clear than in the IPC7351B pattern:

I also installed their Footprint Expert software now and entered the values for DO-214AA. This generates the name DIOM540X360X265L115X208. However, I'm fine with keeping the IPC7351B names we already agreed on. We can still update them some time later once we decide to follow the Footprint Expert conventions for all our packages.

(This gets a bit offtopic, but maybe we should "fork" the IPC6351C naming schema (which at the moment is essentially just the "PCB Footprint Expert naming schema") and make our own, with improved specs and guidelines on how to name things.)

Maybe this would indeed make sense. It really is a mess to not have a clear, open, consistent convention for our packages... But yes that's offtopic here.

My suggestion: Let's get #107 merged, then rebase and merge this PR so we can finally finish this topic.

[ubruhin]

Rebased to incorporte the changes from #107 and #103 and to fix CI warnings. Output looks good to me 👍

Thanks @ii8!