CircuitData Material Database V1 released

We are pleased to announce that we have released version 1 of the Material Database that will be compatible with the CircuitData standard. The project and it's documentation is stored under the github repository for CircuitData.org . You can find the project here:

https://github.com/CircuitData/circuitdatamaterials

At the moment we retrieve data from one source, COMMODITY.LIVE, but the project are open to accept any number of sources. The CircuitData board will be the approval instance for any new sources, addition to code and change requests.

14replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Great work, this will be really interesting:)

    Reply Like
  • This could be a very useful database. Thanks...

    I do have some comments on the current implementation:

    1) The circuitdata_version property is defined as a string. It should be a number, in order to better facilitate version control in a reader implementation.

    2) The ipc_slash_sheet property is specified as an array of integers. How would one know if these slash sheets refer to IPC-4101 or to some other IPC standard (such as 4103)?

    3) The material_attributes property is an array of attribute objects, where each attribute object consists of a name and an array of values, and each value object consists of a value (string) and a value_type (string). So far so good.

    As far as I can see, the value_type is nearly always null, and therefore basically useless. It might make better sense to make the value_type a property of the attribute object, and then make the material_attribute_values property an array of values (of the type specified by value_type). It should not be permitted to set the value_type to null.

    4) The ipc_slash_sheet property is specified as an array of integers. Sometimes this returns a single integer in the value object. However, in many cases what I get back is a JSON string which looks something like this:

    "[\"21\", \"98\", \"99\", \"101\"]" 

    which without the escaped characters and string delimiting quotes would be:

    ["21", "98", "99", "101"]

    Since this is passed as a JSON string it does not parse into an array of integers. As I understand the structure, this format is incorrect and not consistent with the documentation or with JSON conventions.

    Reply Like 1
  • Bruce McKibben Hi Bruce. Thanks for the valuable feedback. Working on an update to the DB and will have your feedback in mind doing so. I will update the forum when I have it ready.


    Thx, Fredrik

    Reply Like
  • Hi Bruce,

    You showed in EKN almost 2 weeks ago that the CircuitData Material database was quite slow when you searched for a specific material. As agreed in EKN I have checked how this works from our side, and you are right, it is slow. But only until next update. We are in process to make some changes that soon will speed up the searching. I will keep you and the forum posted when we have made the changes.

    Regards Jan   

    Reply Like
  • Jan Pedersen Will anything be done concerning my specific implementation comments (posted on this thread a month ago)?

    Reply Like
  • Bruce McKibben I can go through your comments together with Fredrik on Monday. Will reply in detail after that.

    Reply Like 1
  • Hi All

    I have walked through the comments Bruce McKibben  and also discussed with Andreas Lydersen I have the following comments and I am still open for comments and discussions:

    1. Agreed. We will make the version number a number type float with one decimal.

    2. At the moment we are not storing the IPC Standar,  just the slash sheet number. Would it make sense to introduce a separate column for this on the material attribute level? I am ok with updating the table and also the products stored in COMMODITY.LIVE. Jan Pedersen would you agree on the approach? Would it be correct to assume that all the slash sheets would be part of one IPC standard? 

    3. In order to keep the Database flexible, all attribute_values are represented as strings. The value_type will tell each system how they should treat the value. To maintain the flexibility I also think that having the value_type at the value level increases the flexibility. 

    4. I will look into this and fix it.

    Reply Like 1
  • Fredrik Holst I will also populate all the value_types .... that is my bad.

    Reply Like
  • Fredrik Holst  material slash sheets also needs the related standard. As Bruce says we have today 3-4 standards and will get more with printed electronics. 

    Reply Like
  • Some followup on my comments...

    2. I am familiar with there being slash sheets in IPC-4101 (the most common), IPC-4103 (for high-speed materials) and IPC-420x (for flex materials). It is conceivable that a material may fit the slash sheets for more than one of these standards, so the potential for confusion certainly exists. But I don't know what the best solution is. Perhaps the current slash sheet field should only contain 4101 slash sheets, while slash sheets from other standards should either have their own fields or be handled with comments. My familiarity with materials is not extensive enough to give good input here.

    3. From an implementation perspective (on the reader/user side of the api), it doesn't make sense to me that an attribute can have multiple values of differing types. If the structure is that an attribute may have multiple values (as is the case now), I would expect all of the values for that attribute to be of the same type. It then makes more sense to me to link the type with the attribute name, and then have an array of the available values. It works for me that all of the values in the array are strings (that may need to be converted to another type for interpretation), but I can't think of any examples where an attribute will have multiple values of varying types. That kind of "flexibility" is a nightmare to interpret.

    Reply Like
  • Bruce McKibben  as far as I know, materials cannot have slash heets from more than one standard.  So that one will not cause confusion.

    Reply Like
  • Jan Pedersen Are we saying One Material can only have one IPC Standard? If so, adding the IPC Standard to the Material Columns should serve the purpose and the slash Sheets can be kept at the attribute level. Agreed?

    Reply Like
  • Fredrik Holst Yes I think that is correct.

    Reply Like
  • If there are no objections I will add the column IPC_STANDARD to Material Model. This will then be collected as part of the material definition. I will update documentation accordingly

    Reply Like 1
reply to topic
Like1 Follow
  • 1 Likes
  • 3 mths agoLast active
  • 14Replies
  • 308Views
  • 5 Following