assembly without solver

[Zolko]

I have a very strange feeling right now: is it even possible to include a file by link ? And not include a copy of that file ? I just toyed with the Python console, and when I type

Code: Select all

>>> App.ActiveDocument.addObject('App::VRMLObject')

it does include an empty APP_VRMLObject. When then I define the property "Vrml File" in the "Data", I can see the included model. When then I save that as a FreeCAD file, it does include a copy of the file, and the mention

Code: Select all

        <Object name="App__VRMLObject">
        ...
                <Property name="VrmlFile" type="App::PropertyFileIncluded">
                    <FileIncluded file="support_LensArray.wrl"/>
                </Property>
        ...
        </Object>

and in the .fcstd archive there is indeed my .wrl file. This means that it makes a copy, and not a link.

Then, when grepping "PropertyFile" in the App source directory, I only get PropertyFileIncluded results. There is a PropertyLinks file in the src/App directory, but

Code: Select all

>>> App.ActiveDocument.addObject('App::PropertyLink')
or
>>> App.ActiveDocument.addObject('App::PropertyLinks')

give only errors. Does that mean that it is currently not possible to include a file by link ?

[Zolko]

There is a DocumentObjectFileIncluded in the ~/src/App directory, but no DocumentObjectFileLinked. From what I know, it should be possible to add such a DocumentObjectFileLinked, beginning with a copy of DocumentObjectFileIncluded and define the file to be inserted not as coming from the FCSTD archive but from a path/filename .

I would not be able to do such a thing, actually I would not be able to compile FreeCAD from source, but I think this should be doable. Is there someone who would be able/willing to try such a thing ?

Later, we can define the LCS in the model that should be used for insertion (if none is present/defined use the default (0,0,0) ) and the LCS in the assembly where it should be placed. And then apply transformations if necessary. And then we'll have a standard CAD assembly workbench. Even if it's not what everybody wants to use, I'm sure there will be many people happy to have that feature.

[Zolko]

Maybe you should have started the topic with a different title because what seems important is the additional step of specifying local coordinate systems and degrees of freedom before inserting a part.

well, that part of the problem is actually already solved: the LCS feature does exist, and it does quite exactly what an LCS is supposed to do ... which means it was implemented by someone who really new what he was doing:

Code: Select all

App.activeDocument().Body.newObject('PartDesign::CoordinateSystem','LCS')

Now the only mystery is to know how to put that button (back ?) into the PartDesign workbench toolbar.

Btw, I like the simplicity of this solver

nice, thank-you. So now the next part of this is to be done: insert a Body (*.fcstd) into another Body, each having an LCS defined, such that the part body is placed in the assembly body with matching LCS. And inserting the body by link, not be copy.

[DeepSOIC]

I actually wanted to implement something like that with Part-o-magic+Lattice2 combo. Still not there yet.

Latice2-in-PartDesign tutorial almost does display this workflow. But it's not quite an assembly yet.

The key thing missing in Lattice2+PoM combo is an Instance feature. I have some thoughts on implementing it, but I don't want to start until I check out the stuff made by realthunder, in order to not reinvent the wheel.

[Zolko]

I actually wanted to implement something like that with Part-o-magic+Lattice2 combo. Still not there yet.

Reference placement is like a handle to pick-and-place your latches. The most convenient place for this tutorial is the center of the latch, at its root, right where the edge of the thing to be held by the latch touches it. You can have as many different reference placements as you like, for uses in different situations.

yes, this is exactly what I mean by an LCS. Nice stuff. Though I'm not sure why you absolutely want to do arrays there. If you have a part with (at least) one LCS, and several target LCS in your assembly, when you want to place several instances of your part, you select all target LCS and you're done. Unless you do it for hundreds of instances, it should be enough to do it by hand.

Do you think it would be a lot of work to use the PartDesign::CoordinateSystem instead of the paper planes of your lattice ?

[DeepSOIC]

Do you think it would be a lot of work to use the PartDesign::CoordinateSystem instead of the paper planes of your lattice ?

Yes. I think there is no point in doing it whatsoever as of now. A lot of things currently possible will be lost, and I see no gains.

Instead, it may be better to merge Lattice into FreeCAD, and write a small C++ binding code to allow using Lattice2 things from C++ workbenches.

Unless you do it for hundreds of instances, it should be enough to do it by hand.

It depends. If you want a parametric flange with number of bolts settable with a spreadsheet, arrays are the way to go.

[DeepSOIC]

Do you think it would be a lot of work to use the PartDesign::CoordinateSystem instead of the paper planes of your lattice ?

What can be done easily, is to allow using PartDesign::CoordinateSystem and App::Placement instead of a paperplane for population features and such. In fact, it's so easy, I'm gonna try it right now.

[DeepSOIC]

Done, commit abb2e516

lattice-lcs-test.FCStd

(6.56 KiB) Downloaded 81 times

Not all Lattice2 features will work with them, but most will (some of them don't use getPlacementList routine to extract the list of placements)

[fosselius]

Please take a look at the asm3 documentation
https://github.com/realthunder/FreeCAD_ ... i/Concepts

Link
The forked FreeCAD core introduced a new type of object, called Link. A Link type object (not to be confused with a link property) often does not have geometry data of its own, but instead, link to other objects (using link property) for geometry data sharing. Its companion view provider, Gui::ViewProviderLink, links to the linked object's view provider for visual data sharing. It is the most efficient way of duplicating the same object in different places, with optional scale/mirror and material override

Coordinate System
The user is encouraged to first read this tutorial to get some idea about the new concept of local coordinate systems. The tutorial is for the original unfinished Assembly workbench, but gives a pretty comprehensive overview of what Assembly3 is providing as well. The Part or Product container mentioned in the tutorial are equivalent to the Assembly container in Assembly3, which of course can be treated just as a part and added to other assemblies. There is one thing I disagree with this tutorial. The concept of global coordinate system is still useful, and necessary to interoperate with objects from other legacy (i.e. non-local-CS-aware) workbench.

[Zolko]

Please take a look at the asm3 documentation
https://github.com/realthunder/FreeCAD_ ... i/Concepts

Yes, I've seen that, and it raises more questions than it answers:

• it's a fork of FreeCAD ???
• some concepts are questionable
• it seems more complicated than what I have in mind
• but some things go definitely in the correct direction

How is it possible to interact with the developer ?