adrianinsaval wrote: ↑Sat Mar 25, 2023 3:43 pm
I don't really see why and even if it was I don't see that as a strong argument to deviate from the standard way data is stored in FCStd files.
I am not only talking about FreePDM. I am talking about any PDM. And we are talking about a new Assembly? Then why not use a FileList.txt?
It is about opening the file that you stored.
but what's the usefulness of the numbers? what info do they provide that cannot be obtained by just looking at an item position on the list? Do you really need to store 00001 in a file to know that the first item on the list is the item 00001, the second 00002 and so on?
No, it's only a reference that should be used inside Document.xml but it is easier to read than Document.xml, especially when Document.xml is getting complicated.
Just said, there are good reasons, why some extra, out of the BoM count, elements should be allowed too. For drawings, slider directions, axis, measure points, special faces, ...... . It is, in my opinion, up to the user to use and therefore force the correct structure. Disallowing rare but valid usecases per se is not really helpful (similar to the whole one solid for bodies discussion).
Also the whole automatic BoM generation idea is nice, but have some flaws. Some parts are count different as whole as positive ints. Flat steel, bar stocks, ropes can count in mm, stuffing box material in mm or kg, oil in liters, alloy coatings in g and so on. Also when mounting in an assembly 1000 screws, you need some of spare, similar with very small o-rings and so on. And at least, some things should not be count (geometries for drawings, very common in machine engineering).
The entire thing will not be implemented from scratch, it will be based on existing functionality and data formats.
Creating an entire new file format for this is ridiculous, linking external files will not be reimplemented from scratch, we already have Links for that.
xml is not the friendliest of formats but I don't think it's that hard to read data from it. At least not enough to justify changing core freecad functionality before implementing something that could perfectly be implemented with the existing format, all for the sake of making your life easier...
user1234 wrote: ↑Sat Mar 25, 2023 5:26 pm
Just said, there are good reasons, why some extra, out of the BoM count, elements should be allowed too. For drawings, slider directions, axis, measure points, special faces, ...... . It is, in my opinion, up to the user to use and therefore force the correct structure. Disallowing rare but valid usecases per se is not really helpful (similar to the whole one solid for bodies discussion).
Good point, maybe it's worth having an additional group for those object, "Auxiliary" for example. Or just in the "Elements" group.
That way everything inside the "Parts" group is genuinely a part.
Here is an image for the Asm3 toolbar. I hope we can get past using geometry for an attachment reference. Using a Sketch, origins or LCS you can have one icon to make an attachment.
If you think I'm being biased then let me know I will pick on my assembler for a while.
Attachments
snip66.png (129.07 KiB) Viewed 1122 times
Last edited by freedman on Sun Mar 26, 2023 3:06 pm, edited 1 time in total.
freedman wrote: ↑Sun Mar 26, 2023 12:30 am
I hope we can get past using geometry for an attachment reference
Would you build a wall placing bricks by their local CSs instead of aligning their faces?
I think using geometry elements is a key functionality for assemblies. I think ASM3 aproach using (geometriy ) elements and linking their LCSs is a step into the rightdirection.
Maybe the Part container can be extended to be used as ASM3 assembly container to make ASM3 more compatible with other WBs already using the Part container.
Some functions from the tree context menu could be placed in a dialog window to simplify editing.
These thoughts about ASM3 would also apply to a new default assembly WB.
FBXL5 wrote: ↑Sun Mar 26, 2023 8:54 am
Would you build a wall placing bricks by their local CSs instead of aligning their faces?
Have you ever actually build à brick-wall ? If you had, you'de know that their faces are not aligned, there is mortar between them
But unless I was doing ornamental stuff I would try to align their frontal faces co-planar - no mortar on these faces.
And the mortar layer should have a constant thickness and so opposite faces of different bricks have to be parallel with a constant offset - parallel is a state of alignment.
I think no one would design the mortar matrix of a "wall assembly", would you?
adrianinsaval wrote: ↑Sat Mar 25, 2023 5:37 pm
maybe it's worth having an additional group for those object, "Auxiliary" for example. Or just in the "Elements" group.
That way everything inside the "Parts" group is genuinely a part.
Auxiliary, this is the english word what i missed, thanks. I really never used the ASM3 workbench, but i interpreted the "Elements" object/container in the tree as auxiliary object/container.
Greetings
user1234
edit: to be clear, i simple group will do it either, but it should be allowed to add more then the assembled parts