Custom Materials

The custom section is part of the open_trade_transfer_package object and consists of two subsections: colors and materials. CircuitData further defines the materials section as having three subsections: dielectrics, soldermasks, and stiffeners. This definition requires wrapping the content of the materials section in a printed_circuits_fabrication_data element.

From an implementation perspective, this structure is problematic for a couple of reasons:

  • By using the same element name for entirely different purposes, a reader would need to know where in the structure it encounters this element in order to process the correct kind of object.
  • Having three different kinds of very similar objects to describe the different materials is both unnecessarily complex, and limiting (to only those three kinds of materials).

I would like to propose that the materials section be an array of objects, and that for CircuitData a single material object be defined. This object could be defined within the CircuitData schema as follows:

Object name: printed_circuits_material

Object elements:

  • style (string): dielectric, soldermask, stiffener (expandable to other types as needed)
  • name (string): descriptive name of material
  • manufacturer (string): manufacturer name
  • link (string): URL to datasheet or other reference
  • accept_equivalent (boolean): if true then equivalent material may be used
  • IPC standard (string): IPC standard reference (IPC-SM-840, IPC-4101, IPC-4103 or IPC-4204)
  • IPC class (string): IPC class or slash sheet (T or H for IPC-SM-840, or slash sheet number)
  • properties (array of string): a collection of properties which are true if present or false if not. Properties can include: halogen_free, ul, rw_en45545_2_2013, rw_nf_f_16_101, rw_uni_cei_11170_3, rw_nfpa_30 (expandable to other properties as needed).
  • tg_min, tg_range_from, tg_range_to (number): glass transition temperature in degrees Celsius
  • td_min, td_range_from, td_range_to (number): decomposition temperature in degrees Celsius
  • remark (string): additional info where necessary

References to materials within a printed_circuits_fabrication_data would need only to reference the name property of the material. The material definition can then easily be retrieved from the array without needing to know the material style.

23replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Bruce,

    Material specification is one of the areas where we have seen a weakness and need to develop further.  I like your comments and would like to initiate  an advisory group to work on this. I would suggest that you and Andreas is part of that group.

    I would also welcome other users to comment on this issue!

    Reply Like
  • Hi Bruce and Jan,

    I agree that this should be made more simple and versatile. One issue with the way you suggest we treat the IPC stuff is that one material often are compliant with several sheets. Another potensial issue is to mix the sheet numbers that are integers, with the SM-840 T or H, which are strings. 

    Also, if we make a properties element, couldn't Tg and Td be part of that?

    Reply Like
  • This section, MATERIALS, we need to agree on what parameters on materials that are 
     esensial to have with us in the beginning. Typically will be for impedance calculations.  But then the question is whether we should have a definition of materials that are accurate at the level of available prepreg thicknesses and core thicknesses.  I'm thinking of a first level where we do not go down to all physical available types, but keep this somewhat limited.
    I am sure the question will pop up if there should be som db to pick Material type, prepreg- and  Core-type, prepreg- and Core- thickness,  in case this will be HUGE.

    Reply Like
  • John Steinar Johnsen  I interpret the materials section as defining material types. IMHO, available thicknesses (and other dimensions) is beyond the scope of this definition. Required thicknesses for a product should be specified in the stackup section. Available dimensions for a capability will be a nightmare to manage due to continuous market changes.

    Andreas Lydersen True, it is not a good idea to mix strings and integers. On that basis, perhaps the SM-840 class should be a property: e.g. SM-840-H could mean class H if present or class T if not. And in the same manner a Flexible property could be used in combination to specify classes FT and FH. Tg and Td should not be properties since these are number values which do not fit into an array of strings.

    Reply Like
  • I think this could be really good. We need to think through how this can used in various scenarios where you would want to transfer information on a material, e.g.:

    • As part of a specification
    • As part of a profile
    • As part of a capability, as in "what materials can we supply"
    • In a public API: "What materials are out there to choose from"
    • etc.

    We are hoping that we could use this to publish a CircuitData community driven material database.

    I think the best way forward is to try out the changes that would be necessary in the schema, and then test that as a separate branch. If you agree Bruce McKibben , I could start his.

    Reply Like
  • I'm thinking that we are lacking a "group" here. Main type of dielectrics e.g. shouldn't be set in the "name" part of the structure. Like FR1 to 4, CEM1 and CEM3, the different types of metal core, paper, etc. Most specifications are defined by this, and as this is put in the "name" part, it could not be used to match against a material library where the name is populated by a real material name.

    So then the top structure would look like:

    - Type (dielectric/soldermask/etc)

    - Group (FR4, CEM3, etc)

    - Name (The actual name of the material)

    - Manufacturer/Brand

    Agree? Bruce McKibben  and John Steinar Johnsen

    Reply Like
  • Andreas Lydersen For the purpose of product description or requirements profiles, I am not sure how useful the "Group" would be. I don't see it having much value for other material types than dielectrics. And for many boards, the customer is satisfied with only specifying "FR-4" or "FR-4 High-Tg" or similar. Seldom do I see a board requiring a specific manufacturer/product number of FR-4 materials or CEM or whatever. (That, after all, is one of the main reasons for using IPC-4101 slash sheets.)

    If, however, your goal is to build a database of all available materials, then some kind of grouping or material family classification could be helpful for searching. But I consider such a database tobe an ambitious undertaking, both to build and to maintain.

    Reply Like 1
  • A suggested group setup would be a list - this is my preliminary suggestion ("enum" are the choices" and "enum_description" is the description of the choices that needs further explaination:

     "enum": ["FR1", "FR2", "FR3", "FR4", "FR5", "FR6", "G-10", "G-11", "CEM-1", "CEM-2", "CEM-3", "CEM-4", "CEM-5", "ceramic", "polyimide", "aramid", "acrylic", "LCP", "PEN", "PET", "LPISM", "DFISM", "LDISM"],
    "enum_description": {
                  "LCP": "Liquid Crystal Polymer",
                  "PEN": "SMD Film capacitor using a stacked and naked construction with metallized Polyethylene Naphtalate",
                  "PET": "Stabilized PET film",
                  "LPISM": "Liquid PhotoImagable Solder Mask",
                  "DFISM": "Dry Film photoImagable Solder Mask",
                  "LDISM": "Laser Direct Imaging Solder Mask"

    I think this would be useful in the cases where you just want to describe a group in the specification, and how this can be matched up against a material. 

    John Steinar Johnsen  and Jan Pedersen : Could you go through the list and make suggestions?

    Another thing I've added to materials is a boolean that states if the material is suitable for flexible boards or not.

    On the IPC part, I've added a tag called "ipc_shash_sheet" that replaces the old "ipc_4101_sheet", "ipc_4103_sheet" and "ipc_4204_sheet". This has all the slash sheets listed as "enums" so that you can select from a list, in the following syntax: "4101/101" etc.

    Reply Like
  • Bruce McKibben  I need to get you opinion on how to structure the materials under OTTP. Ideally, I would like to have a structure that is something similar to this:

    - ottp
        - custom
            - materials
                - circuitdata (or "printed_circuits_fabrication_data" but I think just "circuitdata" is easier)
                    - "name_of_material"
                        - actual material object

    By doing it this way, it would be easy for systems to look up a material (you wouldn't have to run through all materials to find the one that is referenced) , and the name of the material can be set at the "material" in the "dielectric" and "soldermask" elements in the specifications. 

    First of all - do you agree to this structure?

    Second, this raises a question about the "version" tag. Should it be placed inside each material? or under the "circuitdata" element?

    Reply Like
  • Another thing that I found in the current version is the element "coverlay". Isn't this just a solder mask for flexible boards? If this is so - can't we just remove it? Jan Pedersen  John Steinar Johnsen

    Reply Like
  • I've written an article to describe the setup if this is approved. Please read through and comment Bruce  , Jan Pedersen  and John Steinar Johnsen  or anyone else who wants to look into this. You can find the article here.

    Reply Like 1
  • Until now we have only discussed dielectric materials, but a PCB exists of dielectric materials, conductive materials, surface finish materials and printed materials such as soldermask, peelable mask, kapton tape, and legend. All are in principle materials. And, if we structure it this way from the start we have the freedom to add new technologies (some existing /old and some new) like Thick film circuits, Thin film circuits, BGA substrates, Printed Electronics, 3D printed circuits, Wafer circuits and other semiconductor technologies. 

    If we treat conductive layers as materials this will give us the freedom to build any structure without being restricted by how we build PCBs today. 

    And, there is in reality nothing called flexible conductive layers - it is only a conductive material sandwiched between flexible dielectric materials. We can actually delete "Flexible Conductive layers". 

    Reply Like 1
  • Jan Pedersen 
    A Rigid-Flex can consist of several rigid and flexible sections. We must come up with a way to describe the different sections that may have different stackup and materials. Sample A: Section 1: Rigid 6 layers / Section 2: Flex layers 3 and 4 / Section 3: Flex layers 3 and 4 with support below layer 4.
    Sample B: Unsymmetrical, Left / Right structure.

    Sample A and B, below.

    Reply Like 1
  • Andreas / Bruce,

    Please comment if we have open issues here.



    Reply Like
  • In my opinion, the array structure for sections as specified in version 1.0 is complex and confusing. The structure specifies dividing the board into a geometrical array of regions, and then assigning each section to one or more regions, and then specifying that each layer is found in one or more sections.

    As I mentioned at the EKN seminar last month, it is not intuitively clear how this array geometry would map to a non-orthogonal board (such as my example of a round board with 5 arms). 

    I think it would be better to simply define sections with a name and a description (perhaps referring to a section identifier in a drawing. Since CircuitData has no direct relationship to the geometry of the board, it is also not really necessary for the sections to refer to their physical placement.

    With reference to sample A and sample B above (@john_steinar_johnsen), I would rather define them as follows:

    Sample A would have 3 sections which might be named rigid, flex and stiffener

    Sample B could also have 3 sections (rigid, flex and split), where flex consists of the flex layers with an air gap, and split consists of the two 6-layer rigid stackups with an air gap between them. However (depending on the geometry) it might also make sense to define 4 sections (rigid, flex, upper and lower) where upper would be the upper 6 rigid layers, an air gap and the flex layers, and lower would be just the lower 6 rigid layers.

    A couple more comments:

    The area (mm2) of a section should not be required, as this data may not always be available.

    The sections really only have meaning for rigid-flex boards. Boards which are entirely flex or entirely rigid will seldom have a need for more than one section. In such cases, it would be cleaner if sections were not required elements in the circuit data language. This would require 2 assumptions: 1) If no sections are defined, then the board has only one section, which encompasses all defined layers (even though a layer may not have 100% coverage). 2) If no sections are defined for a layer, then that layer appears in ALL sections.

    Reply Like 1
  • I would also greatly appreciate if the keyword "circuitdata" were NOT used in the custom|materials part of the structure. I believe it would be better to use something like "circuitdatamatl" or "cdmatl") in order to clearly differentiate between very different objects (which use different schemas).

    Reply Like 1
  • Thanks Bruce. So,  basically all your first comments goes on the use of sections. And you request sections not to be "required".  I will bring this up in the CD board - and i think this change do not need a new version of the language if we agree to it. 

    The area for each selection is available in some CAD softwares, but obviously not all, and should not be required.

    For your suggestion to keywords used - Andreas Lydersen, do you have a comment? 

    Reply Like
  • Jan Pedersen This week I am looking at the entire structure in detail. I will most likely have a few more comments soon...

    Reply Like
  • Bruce McKibben  Materials are listed like this:

      "open_trade_transfer_package": {
        "custom": {
          "materials": {
            "circuitdata": {
              "osp": {
                "function": "final_finish",
                "version": 1.0,
                "group": "osp"

    This means that you'll only find materials there (under "open_trade_transfer_package" -> "custom" -> "materials". What would be the benefit of renaming the tag to something else? And if we did, shouldn't we also rename profiles?

    Reply Like
  • Bruce McKibben and Jan Pedersen  About the sections part, I think what you say makes a lot of sense, Bruce. I have a couple of concerns though:

    The reason for having a mandatory section and also a mandatory mm2 tag is to know the size of the board. If we take that away, we need to put it somewhere else.

    Having "in_x" and "in_y" is confusing on boards that have special layouts. I think having some sort of geometry would be very useful for applications that would like to generate a graphical representation of the board, but is should not be mandatory. How about we just make them both not mandatory?

    Reply Like
  • Andreas Lydersen and Bruce McKibben I support to keep both sections and mm2 in CD but not mandatory. It is useful for some but not for all. 

    Reply Like
  • Jan Pedersen Works for me

    Reply Like
  • Andreas Lydersen The size parameters in the Metrics object should be sufficient for knowing the board size (for pricing purposes) in cases where mm2 is omitted

    Reply Like
reply to topic
Like1 Follow
  • Status Started
  • 3 wk agoLast active
  • 23Replies
  • 317Views
  • 4 Following