File structure #11742
Replies: 12 comments 7 replies
-
|
I don't really see the point of using different extensions. But I guess we could easily make freecad accept .fcasm files. In current implementation I have not introduced a software limitation regarding the number of assembly. I tried to keep things as flexible as possible, enabling multiple assemblies, nested (though nested assemblies are not tested/debugged yet) and enable as much types of object as possible (not all types are supported yet : draft, fem, meshes are untested). I think most people will use a single assembly per document anyway. But why would we introduce an artificial limitation to prevent the creation of 2 in the same file? |
Beta Was this translation helpful? Give feedback.
-
That's the central question. I don't have the answer. If we see most other CADs doing something that we don't understand we have two choices: We can assume they know something that we don't. Or we can assume they're fools.
This is an area that I hope assembly experts like @ppemawm weigh in. @PaddleStroke is right to take a minimal approach at this stage. Optimizing something too early is almost always a mistake. |
Beta Was this translation helpful? Give feedback.
-
Hardly an expert and have somewhat of a conflict of interest. I am assisting @Zolko-123's development in whatever way I can as a mechanical design engineer and will continue to promote Assembly4 as long as there is progress. My industry experience with CAD/D was from the early days of Unigraphics so I'm sure that it is quite obsolete by now. My only suggestion is that anything new needs to have at least the capabilities and fundamentals of Assembly4 which is my only but well satisfied current experience. I especially like the simplicity of one assembly per file but with unlimited nested sub-assemblies and the ability to create independent reusable bodies in the same file for smaller assemblies. The self-contained small assembly file which will likely be more common than not is much easier to share. And, as I have commented too many times before, when you develop the basic structure, do not forget about the differences between (bottom-up) assembly and assembly design (top-down). An assembly workbench must support in-context modelling as a basic feature. |
Beta Was this translation helpful? Give feedback.
-
|
I think that having more than one root per file does not make sense physically. If you can mate the roots together you have, by definition, an assembly. if they just float in the 3D view, they are not practical no manage because you can’t just isolate one: say you have a desk and a chair in the same file, you can’t share just the desk with your client. If you can import a subset of the file into another (like a library), it gets more interesting but you will actually manage them more easily if they are each in a single file. If you use the file to store multiple configuration of a part (say a screw), whith a spreadsheet to drive the variants, then you’ll be better off with an actual configuration feature. You may think of a special kind of assembly that can be encountered in the industry. While it uses the assembly container, the parts it contains aren’t mated together. There are often bundles of fasteners that are stored together in their own assembly. Say you have a housing with a lid: you have the housing part, an assembly for the mechanism inside, a lid part, and an assembly containing all the screws used to secure the lid on the housing. When the screw bundle is opened in its own window, you’ll see them floating in the void. Maybe the name assembly isn’t right in this context. Indeed Catia uses the term “product” for bundles and proper assembly. You can watch the following video from Wintergatan where this is mentioned and shown. It’s not the main point of the video but you will learn a lot in how engineers work with CAD. |
Beta Was this translation helpful? Give feedback.
-
|
If sub-assemblies and sub-parts are allowed, it would be necessary to provide an option to disable this feature. It can be the default but having to tell FreeCAD to create an independent file each time a new sub-part or new sub-assembly is created would be very cumbersome. Typically something that can be asked in the startup wizard. |
Beta Was this translation helpful? Give feedback.
-
|
A different topic: templates. We already have drawing template but it could be so much more and flexible. The drawing templates are just SVG files for the background. With actual templates files, you can set the standard (ISO, ANSI, whatever) and other things that would need to be done by hand each time a new drawing is created. Also for parts and assembly, but drawing also, companies often have their own metadata (part number, name, make or buy, type of part, etc.), which need to be recreated by hand each time. If you have a set of file in a FreeCAD directory somewhere like
|
Beta Was this translation helpful? Give feedback.
-
|
Any news on this? I was thinking lately of a tangent subject: compatibility of FreeCAD files created by different versions of the program. Feature will be more and more numerous as time goes on. Older versions shouldn’t be able to open them. On the other hand, newer versions should be able to open older files but what about legacy features and formats? When #6884 is implemented, how old parts will look like? Should files have the version in the metadata to be checked by FreeCAD? If it is newer than the program, it displays an error message explaining why. If it is newer, should FreeCAD retain legacy features code? Convert them? |
Beta Was this translation helpful? Give feedback.
-
|
The problem already exists: #12552 |
Beta Was this translation helpful? Give feedback.
-
|
This discussion is very interesting. I have to make up my mind a bit, but in any case it is good to have some historic overview as well. For enforcing one part per file, you need to be able to link files together. Linking files in FreeCAD is relatively new, so if you wanted to do assemblies before that you had to copy in geometry from other files. Being limited by having only one root is then not so logical. About having only one root per file: it may be a good thing to enforce that, but currently FreeCAD is not designed for that. Since everything is in the end a DocumentObject, FreeCAD does not make that much distinction between whether it is a part, body, sub assembly, or a simple property container like Dynamic Data, Assembly 4 Variables, Path PropertyBags and the VarSet of #12135. Especially for this kind of document objects, you want them to be on the same level as an assembly, for example to link to an assembly from a different file with different parameters. In #12135 I address modularity problems that (in my humble opinion) should be solved in FreeCAD. These problems are related to file / document object structure. One possible explanation of why other CAD programs do things differently, could precisely be these modularity problems. Unfortunately, I don't know much about other CAD software packages. @pierreporte, you seem to know much about that. Could you perhaps give me some introduction in how other CAD packages solve things regarding modularity? |
Beta Was this translation helpful? Give feedback.
-
|
I know very little about how CAD software work internally. I am just a professional user. I’ve heard that Catia is able to generate fully parametric assemblies. For example a gearbox with a few parameters like the ratio, that generates itself (gears, housing, etc). The parts are drawn using a lot of parameters and expressions internally that are driven by the assembly parameters. However this has no real life use in the industry. Parts do change and can change often but they are fully independent. You don’t want side effects that can lead a part to be modified when you don’t want it. In fact, they are locked once finished. It happens a lot with Alibre because assemblies can’t be made read only although the parts remain intact. |
Beta Was this translation helpful? Give feedback.
-
|
After some testing with Ondsel SE 2024.1, it appears that the ability to have more than one root part in files leads to the need to load the files when opening them for insertion into an assembly, because it is necessary to know what’s inside. This means that when a lot of parts are available (when you open a folder and not just a part—not possible at the moment but you can select more than on file to emulate this), the loading time can be enormous. On my machine (i5-1135G7) it takes one or two seconds to load half a dozen of very simple parts. When you have dozens of them with reasonable complexity (not uncommon) and stored in the network (slower than a local SSD), you can expect to be waiting one minute or something just for the list of parts to appear. If a company has all its file in a single network directory, it will be a long wait. |
Beta Was this translation helpful? Give feedback.
-
|
One possibility to alleviate this, would be to use a treeview and show files, and when you expand the files it would load the file content and show the inner solids that can be used. But I'm not sure to understand your issue here because why do you want to load all the files in the first place? You can browse your folder in your OS file manager and open only the files that you need. And if you use one file per part it should be the same between looking for it in the file manager or in the insert tool list. |
Beta Was this translation helpful? Give feedback.
-
|
As I understand, opening a part in the |
Beta Was this translation helpful? Give feedback.
-
|
I can’t believe I haven’t though of this. Allowing more than one root per file is detrimental to collaboration. If you have more than one root part in a file, two people can’t edit one of the parts each. And if parts in an assembly are stored in the assembly file, it is impossible to edit them while the assembly file is edited by someone else. Situations like this happen all the time and are perfectly normal. |
Beta Was this translation helpful? Give feedback.
-
|
I certainly would rather be able to put more than one part in a single file! Especially if they are all related, or used together to create one thing. If the issue is that it loading the file takes a long time, I would ask why we're storing the entire object hierarchy in a single |
Beta Was this translation helpful? Give feedback.
-
|
I think having more than one root per file could lead to problems where someone creates dozens of roots in one file and brings up some weird bug that no-one even though could happen. This has two benefits, it would allow to share projects with parts that are stored in a partslibrary that is somewhere but the folder of the Projekt. And it would make it easy to save Version/Snapshots of a Projekt. I use the Therm Projekt a synonym for Part/Assembly. |
Beta Was this translation helpful? Give feedback.
-
|
@sliptonic What is your current opinion on this after a little more than two months? What has been said about this at Brussels? |
Beta Was this translation helpful? Give feedback.
-
|
Let’s say you create an assembly container and create parts in it using |
Beta Was this translation helpful? Give feedback.
-
|
See issue #12708. |
Beta Was this translation helpful? Give feedback.
-
Introduction
The assembly workbench is arriving sooner than later. When #10764 is merged, it will pretty much be there. However, there seems to have been very little discussion about the file structure that comes along multi-part projects. Two weeks ago, there was a short discussion with @sliptonic on reddit showing that, indeed, the matter isn’t settled and that it may be a good idea to start brainstorming as a community and an Ondsel blog post was contemplated. I took the liberty to open this discussion, as a starting point and to centralize the ideas. The blog post will still be welcome. The point of view of @PaddleStroke would be appreciated, as he is the main developer of the assembly workbench. There have been some discussion in #9278 but it is a slightly different scope.
How the industry handles files?
All cad software work a little bit differently but they share one thing: one file contains only one root. It means that files can contain one single part or one single assembly.
There are programs that allow assembly files to contain sub-parts and sub-assembly that are contained by the root assembly, and those sub-assembly can themselves contain parts and assemblies, etc., basically allowing a whole project to be contained in a single file. Most programs, however, can only store one assembly. The sub-assemblies and sub-parts are separate files. In case of multi-object files, the allowed workflow is never mandatory—in fact most companies have as many file as there are parts and assembly as it is easier to manage in a PDM (what if you want to insert a part that exist only in an assembly file in another assembly?)
The same goes for drawings: most programs have separate drawing files, some store them in the part or assembly file. However they all allow for standalone drawings if needed.
File types are a different thing. The vast majority have different types for parts, assembly and drawings. Some other have just one type of files. Extensions are again different: you can have several extensions tied to one file type, to help differentiation and storage (especially useful if you save them as the part number and the drawings files have the same base name).
In any case, it is always possible to insert a part that is stored in a file into an assembly stored in another file. However, the file structure is invisible from the user. Unlike FreeCAD, there in no line in the tree view for files.
Note that I am writing from a mechanical CAD user point of view. Architects can have different requirements so they are welcome to describe how the industry handles files.
An idea for FreeCAD
I propose this:
Beta Was this translation helpful? Give feedback.
All reactions