Rethinking the "Part Library"
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Re: Rethinking the "Part Library"
Just some random thoughts
A number of the big component suppliers maintain cross reference coding
between identification groups like UNSPSC, (https://en.wikipedia.org/wiki/UNSPSC)
CPV (https://en.wikipedia.org/wiki/Common_Pr ... Vocabulary). [Using these might help with
maintaining translation] I wonder if
it might be worth approaching one or more of McMaster Carr, Farnell-Newark, RS...
and see if they would work with the FreeCAD.
I worked with one supplier in the early 2000's to make a local student components database, automatically linked
by identification groups + local supplier/manufacturer's part number.
NB, even within the 'English' speaking Universities/technology areas/courses there were differences in common usage
names so we included the ability to include a local 'user defined' layer group names/order that could be hot linked to
one of the standards, we used UNSPSC. However linked to UNSPSC, CPV etc enabled easier searching for suppliers even if the sector terminology was confusing.
Best Wishes
A number of the big component suppliers maintain cross reference coding
between identification groups like UNSPSC, (https://en.wikipedia.org/wiki/UNSPSC)
CPV (https://en.wikipedia.org/wiki/Common_Pr ... Vocabulary). [Using these might help with
maintaining translation] I wonder if
it might be worth approaching one or more of McMaster Carr, Farnell-Newark, RS...
and see if they would work with the FreeCAD.
I worked with one supplier in the early 2000's to make a local student components database, automatically linked
by identification groups + local supplier/manufacturer's part number.
NB, even within the 'English' speaking Universities/technology areas/courses there were differences in common usage
names so we included the ability to include a local 'user defined' layer group names/order that could be hot linked to
one of the standards, we used UNSPSC. However linked to UNSPSC, CPV etc enabled easier searching for suppliers even if the sector terminology was confusing.
Best Wishes
Re: Rethinking the "Part Library"
It's absolutely fine. In my opinion should be 2 separated folders "Architectural Parts" and "BIM parts". In BIM we can put cross beam connections (pic1), concrete blocks, anchors.... I'm not sure we need Medical parts. I was working 1 years in pharma 2008 and I didn't saw any big-pharma special equipment. We can create on bottom folder Other parts and move Medical parts. We can make one more folder: Typical machines. And sub folder: Food and chemistry machines -> Screw covers, Mixing equipment, Silos, .... also to Typical machines we can put some "Molds"chennes wrote: ↑Wed Dec 22, 2021 4:28 am Just for the record, the current hierarchy base looks like this:Code: Select all
Architectural Parts Computing Electrical Parts Electro-pneumatic Electronics Parts Generic objects HVAC Hydraulics Industrial Design Logistics Mechanical Parts Medical Parts Pipes and tubes Robots/Quadruped robot/Spider robot Symbols
Best regards
Marcin
- Attachments
-
- pic1.PNG (529.08 KiB) Viewed 4901 times
Re: Rethinking the "Part Library"
Little thinking,
As "part collections" in a Open Source program "should be listing" Open parts, at least if "available through" standard menu items.
I maybe want to have a "manufacturer catalog" in FreeCAD,
But having a clear documentation on how this could be done, will maybe encourage "manufacturer" to make their own "part collections" and made them available "ready made" for FreeCAD "part library infrastructure".
Probably some email to customer relations with link to the appropriate documentation and some idea of FreeCAD "user base" would make some manufacturer think that this is a "profitable idea", letting them make the hard work, as a "customer service" will be the way to spread more FreeCAD around.
As if one manufacturer start to make such things, probably other will follow.
But as usual maybe this is a bad idea.
Regards and Merry Christmas to all.
Carlo D.
As "part collections" in a Open Source program "should be listing" Open parts, at least if "available through" standard menu items.
I maybe want to have a "manufacturer catalog" in FreeCAD,
But having a clear documentation on how this could be done, will maybe encourage "manufacturer" to make their own "part collections" and made them available "ready made" for FreeCAD "part library infrastructure".
Probably some email to customer relations with link to the appropriate documentation and some idea of FreeCAD "user base" would make some manufacturer think that this is a "profitable idea", letting them make the hard work, as a "customer service" will be the way to spread more FreeCAD around.
As if one manufacturer start to make such things, probably other will follow.
But as usual maybe this is a bad idea.
Regards and Merry Christmas to all.
Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Rethinking the "Part Library"
It will be nice also to add "Tutorials" and "Examples" on top.
*Tutorials
*Examples
Architectural Parts
->BIM (subfolder - crossing joints)
Computing
Electrical Parts
Electro-pneumatic
Electronics Parts
Generic objects
HVAC
Hydraulics
Industrial Design
Logistics
Mechanical Parts
Medical Parts
Pipes and tubes
Robots/Quadruped robot/Spider robot
Symbols
In Tutorials sub folder:
- 1.Basic
- 2.Medium
- 3.Advanced
- 4.Typical parts (loft-screw / .... /.... )
In Examples - subfolders:
- Parts
- Assemblies
- FEM
- Techdraw
- Houses
- Buildings
- Architecture/Interior
*Tutorials
*Examples
Architectural Parts
->BIM (subfolder - crossing joints)
Computing
Electrical Parts
Electro-pneumatic
Electronics Parts
Generic objects
HVAC
Hydraulics
Industrial Design
Logistics
Mechanical Parts
Medical Parts
Pipes and tubes
Robots/Quadruped robot/Spider robot
Symbols
In Tutorials sub folder:
- 1.Basic
- 2.Medium
- 3.Advanced
- 4.Typical parts (loft-screw / .... /.... )
In Examples - subfolders:
- Parts
- Assemblies
- FEM
- Techdraw
- Houses
- Buildings
- Architecture/Interior
Last edited by marcin86 on Thu Dec 23, 2021 12:58 pm, edited 1 time in total.
Re: Rethinking the "Part Library"
Agree 100% with your plan @chennes.
I would also vote for "conponents library" instead of parts, as indeed Parts as a very specific meaning in FreeCAD, and this library could evolve to include non-Part stuff (spreadsheets, mesh objects,...) some day.
Or, do we take the opposite route, and say "this is strictly for Part objects" (ie. They MUST have a BREP-based shape), that might be interesting too, to keep the quality high. Hmmm... the more I think to it, the more I like it...
I like the loose git-based structure. People can PR anything. It lives on its own. It's just a bunch of files.
We have a kind of improved Parts library browser tool in the BIM workbench: https://github.com/yorikvanhavre/BIM_Wo ... Library.py ( https://wiki.freecadweb.org/BIM_Library ) might be an inspiration...
I would also vote for "conponents library" instead of parts, as indeed Parts as a very specific meaning in FreeCAD, and this library could evolve to include non-Part stuff (spreadsheets, mesh objects,...) some day.
Or, do we take the opposite route, and say "this is strictly for Part objects" (ie. They MUST have a BREP-based shape), that might be interesting too, to keep the quality high. Hmmm... the more I think to it, the more I like it...
I like the loose git-based structure. People can PR anything. It lives on its own. It's just a bunch of files.
We have a kind of improved Parts library browser tool in the BIM workbench: https://github.com/yorikvanhavre/BIM_Wo ... Library.py ( https://wiki.freecadweb.org/BIM_Library ) might be an inspiration...
Re: Rethinking the "Part Library"
I am going to try to do some planning for this in the next couple of days. For efficiency it would be nice if the git repo had a “catalog” file listing some simple info about the components. I think I’d rather not just use git’s structure here, it would be good to have a short description of each part for display. Maybe even a small (like 64x64) screenshot of each?
Re: Rethinking the "Part Library"
Looking forward to new development in the parts library department.
The FreeCAD-Library repo is up over 30 GB now, which is far from ergonomic to work with. (see https://github.com/FreeCAD/FreeCAD-library/issues/341)
The FreeCAD-Library repo is up over 30 GB now, which is far from ergonomic to work with. (see https://github.com/FreeCAD/FreeCAD-library/issues/341)
Re: Rethinking the "Part Library"
Another flight delay, may as well poke at this now. I propose an XML-based catalog, defined recursively so that one catalog can reference another. A possible structure for the file might be:
We’d set size limits for description, say 64 characters, and for image size, say 64px. Components would be available download-on-demand, or you could tell your system to pull in entire catalogs or folders. This would be pure HTTP(S) downloads, no git requirement on either end. This format would be easy to generate programmatically from our existing repo. Let the bikeshedding begin .
Code: Select all
<catalog name=“Chairs”>
<folder name=“Mid-century Modern”>
<component name=“Eames”>
<description>Yellow and chrome</description>
<category>furniture</category>
<version>2022-01</version>
<image>eames_chair.png</image>
<file>eames_chair.stp</file>
<file>eames_chair.stl</file>
</component>
<catalog url=“https://more.data.com/furniture”/>
</folder>
</catalog>
Re: Rethinking the "Part Library"
OK.
A good source of prior art is the BOLTS library. They use YAML for similar purposes. referring to https://github.com/boltsparts/BOLTS/blo ... arings.blt, I think this proposal is on the right track for sure.
We should allow a description tag for folders, as well as components.
The BOLTS project also specs the configurable parameters of objects in its descriptor files, which I would highly recommend considering an out-of-scope feature for this system. (better to let FreeCAD's existing systems handle re-computation/generation of parametrized parts)
One question I have is whether licenses on library objects would be on a per catalog or per component basis. Per-catalog is simpler, but creates conflicts when a sub-catalog with a different license is embedded.
Re: Rethinking the "Part Library"
I would prefer per component, for flexibility, but I could be swayed on that point. I’d love for FreeCAD to help you keep track of those licenses, filter on them, etc.
Maybe have a catalog license that is the default, and components can also provide their own.