Assembly3 preview
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Assembly3 preview
I would expect that double-click on the linked part in treeview should open the part.
-
- Veteran
- Posts: 7791
- Joined: Tue Jan 07, 2014 11:10 am
- Contact:
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
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.
Last edited by realthunder on Thu Jun 20, 2019 1:58 am, edited 1 time in total.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
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.
Re: Assembly3 preview
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.
Assembly 3 notes: https://github.com/ceremcem/freecad-notes
Re: Assembly3 preview
Ah OK, I understand now why realthunder said:
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 ?realthunder wrote: ↑Wed Jun 19, 2019 12:19 am Actually, this feature has been requested multiple times in this thread.
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.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.
As another thought, can't PropertyXLink things be used to pass properties across documents/objects ?
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
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 wrote: ↑Fri Jun 21, 2019 7:41 am 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 ?
Re: Assembly3 preview
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.realthunder wrote: ↑Fri Jun 21, 2019 8:05 am 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.
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
┊
Code: Select all
Part
│
├─ Spreadsheet
│ ├─ Length
│ └─ Diameter
│
└─ Extrusion
├─ Sketch
│ └─ Diameter
└─ Length
- Attachments
-
- variable.FCStd
- (18.3 KiB) Downloaded 57 times
Re: Assembly3 preview
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.
Assembly 3 notes: https://github.com/ceremcem/freecad-notes
Re: Assembly3 preview
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>
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
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;
}