Assembly3 preview

[fosselius]

I would expect that double-click on the linked part in treeview should open the part.

[freecad-heini-1]

I would expect that double-click on the linked part in treeview should open the part.

In Creo you take the right mouse button, then a dialog "open as file" opens or just "open" it. Then a new window opens with the single part.

[realthunder]

works. Now that your version doesn't open a tab on all assembled/linked parts (which is great) there is a new annoyance: how to actually open a linked part when necessary ?

The "Select linked object" command is exposed as a toolbar button, but no shown by default. I'll add them in next release. Meanwhile you can bring out the button through Tools -> Customize -> Toolbars, create a new global toolbar, and add whatever your favorite commands there. You can easily find link commands there. You need to perform a workbench switch action to make the toolbar appear. Once the toolbar is there, you don't need to actually click the button, just select a Link, and use keyboard shortcut "S, G". You may also want to consider the "Select deepest linked object" command, in case you have multi-level linking. You may also want the "Back" and "Forward" command in "View" toolbar, to let you got back and forward of your previous selection.

Update: forgot to mention. You may also want to turn on Sync view option (Tree menu -> TreeView options -> Sync view), so that you can auto jump to the view window of the selected object. I shall activate this option by default in the future.

Screenshot from 2019-06-20 06-49-37.png (185.2 KiB) Viewed 2069 times

[realthunder]

I would expect that double-click on the linked part in treeview should open the part.

Link forwards the double-click action to the linked object. For example, if you double click a linked sketch, it will enter sketch editing mode. The core performs some trick (based on your current select) to let you edit the sketch in place. For part object, double click activates move, but Link will intercept the move action and move itself instead of the linked object.

[ceremcem]

What do you think, how difficult would it be to implement such a "variable" functionality into App::Link ?

This was discussed before here and currently there is a working way.

Some of the models are just such variants of their base models in FreeCAD-Asm3-Library.

I know that it's not a perfect solution because the "Profile length" issue requires uncountable amount of files by this approach. However, we have a solution.

[Zolko]

What do you think, how difficult would it be to implement such a "variable" functionality into App::Link ?

This was discussed before here

Ah OK, I understand now why realthunder said:

Actually, this feature has been requested multiple times in this thread.

I wasn't aware because this was discussed on another thread ... which begs the question: is it a good idea to have many discussion forums for the same subject ?

and currently there is a working way:

• Use expression engine to obtain document name and parse it to get the variant parameters, like here: #202 (comment)
• Keep the edge version of the model in a folder
• Generate the variants automatically by using a text file
• Exclude the generated models from the Git history.

I know that it's not a perfect solution because the "Profile length" issue requires uncountable amount of files by this approach. However, we have a solution.

yes, this is a good beginning, but to be honest, I was looking for a more "parametric" solution. I tried to do it by using spreadsheets, and while it's very handy for a single document App::Link doesn't seem to be very spreadsheet-friendly across several documents.

As another thought, can't PropertyXLink things be used to pass properties across documents/objects ?

[realthunder]

yes, this is a good beginning, but to be honest, I was looking for a more "parametric" solution. I tried to do it by using spreadsheets, and while it's very handy for a single document App::Link doesn't seem to be very spreadsheet-friendly across several documents.

As another thought, can't PropertyXLink things be used to pass properties across documents/objects ?

I've spent lots of effort to make expression/spreadsheet external linking friendly. You can simply refer to any object in any document using only expression, without relying on App::Link, and it will work just the same. On the other hand, if you do refer to an App::Link object in an expression, you can easily refer to the linked object's property using normal syntax. For example, if Link001 points to a Box, then Link001.Length gives you the length of the Box. But that's probably not what you want or maybe some bugs somewhere. So, it's better if you can attach some file here to show the problem you have encountered.

[Zolko]

For example, if Link001 points to a Box, then Link001.Length gives you the length of the Box. But that's probably not what you want or maybe some bugs somewhere. So, it's better if you can attach some file here to show the problem you have encountered.

I don't have a file because I've tried (and failed) many times, so I'll explain it : what I'd like to do, ideally, is to have a place-holder for variables in an assembly (a spreadsheet would do, but it can also be a FeaturePython object to which I add custom fields), to have multiple instances of linked objects, such objects having a place-holder for variables (...), and these variables driving parameters for construction entities.

Code: Select all

Assembly (App::Part)
  │
  ├─ Spreadsheet
  │    ├─ Var1
  │    ├─ Var2
  │    ├─ Var3
  │    └─ Var4
  ┊
  ├─ Link1 (App::Link first instance to Part)
  │    │
  │    ├─ Spreadsheet
  │    │    ├─ Length → Var1
  │    │    └─ Diameter → Var2
  │    ┊
  │    └─ Extrusion
  │         ├─ Sketch
  │         │    └─ Diameter
  │         └─ Length
  │
  ├─ Link2 (App::Link second instance to same Part)
  │    │
  │    ├─ Spreadsheet
  │    │    ├─ Length → Var3
  │    │    └─ Diameter → Var4
  │    ┊
  │    └─ Extrusion
  │         ├─ Sketch
  │         │    └─ Diameter
  │         └─ Length
  ┊

The important aspect is that the same part can have multiple instances, and each instance can be driven by different variables set in the assembly. I've managed to do the single-object part of this problem, but when linking it in an assembly I failed.

Code: Select all

Part
  │
  ├─ Spreadsheet
  │    ├─ Length
  │    └─ Diameter
  │
  └─ Extrusion
       ├─ Sketch
       │    └─ Diameter
       └─ Length

In the attached file there is a spreadsheet called "Variables", to which I added custom fields that drive the extrusion. I'm not sure this is the correct way to use the spreadsheets, but it works as expected. I had also tried to add a FeaturePython and custom fields, but the ExpressionEngine didn't accept the fields defined there.

[ceremcem]

is it a good idea to have many discussion forums for the same subject ?

No, I think it's not a good idea. However, my proposal would be just the opposite: This "thread" is actually serving as a chat room (which is a necessity, by the way) and IMO the Github issue tracker (note that it's an issue tracker) should be used for feature requests, bug reports, etc. The rest of the topics (opinion based topics) should be posted here.

[Zolko]

The important aspect is that the same part can have multiple instances...

When I look at the internals of assembly *.FCSTD files, and expecially at the Document.xml inside the archive, links are decribed by :

Code: Select all

        <Object name="Cylindre_1" Extensions="True">
            <Extensions Count="1">
                <Extension type="App::LinkExtension" name="LinkExtension">
                </Extension>
            </Extensions>

and here Cylinder_1 is the instance's name. Below, we find:

Code: Select all

           <Properties Count="17" TransientCount="1">

and this "17 properties" are in all the files I have looked at, therefore I belive that this is the number of properties that each instance has (can have). These 17 properties are:

• ColoredElements
• ElementCount
• ElementList
• ExpressionEngine (this is where Asm4 constraints are stored, lucky that you had foreseen this use-case)
• Label
• Label2
• LinkPlacement
• LinkTransform
• LinkedObject
• Placement
• PlacementList
• Scale
• ScaleList
• ShowElement
• SubElements
• Visibility
• VisibilityList

So, first remark: while it is possible to set visible/hide for each instance individually, it's not possible to set the drawing style (wireframe/shaded/...) for each instance, this is set for the linked part in its GUI window, and applies to all instances. I thik this should be amended.

Second remark: if we wanted to have some sort of info to pass from the assembly to an instance, however this info would be handled (ExpressionEngine, Python, spreadsheet...) this is the place where it should be stored in the *.FCSTD file. In the "Properties" list or in the "Extensions" list, I dunno

Third remark: since the list of properties that are passed from the assembly to the linked object is defined here, it would be good to have a general agreement about what information should be handled. Or, other possibility, limit the info to the bare minimum (and I would not count "Scale" as a minimum) and provide some extension mechanism so that this property list can be expanded/adapted to use cases.

Fourth remark: may-be the standard FreeCAD App::Part object would need some additional feature/property/extension to be able to handle the "Variables" feature that some of us are asking. May-be the PartPy extension mechanism could help ? It does seem to allow to set custom attributes. Such a custom attribute could be a Python command that: if it's being called as an App::Link, then fetches the App::Link instance's name with which it has been called, and ... well, something. Like reading an additional Property "ExternalVariables" that would store the name of the spreadsheet and fields (in the assembly) where the variables (to be used in the specified instance) are to be grabed from, and set the variables (in the part) to those values.

Code: Select all

PyObject *PartPy::getCustomAttributes(const char* /*attr*/) const
{
    return 0;
}

int PartPy::setCustomAttributes(const char* /*attr*/, PyObject* /*obj*/)
{
    return 0; 
}