Assembly3 preview

[realthunder]

However, Im seeing a 'FeaturePython' object has no attribute 'UseRotation' error; will check out for more detail

Could you please provide a file show the problem. I've searched code, seems only Robot and Path WB is using attribute with this name.

when creating a link transform group, i wanted my z offset between every element to be 120, but i got x offset of 1.
Did not see any option for this, can it be configured or is it hardcoded?

Could you please provide a file or picture showing you intention?

[bill]

Simplified down, here it is.

newRTpyErr.png (134.34 KiB) Viewed 2669 times

No err thrown in .18, .18.1, or dev app img .19?

Below is file!

[realthunder]

Simplified down, here it is.
Below is file!

This is a bug of the Path workbench. I'll submit a PR later. Meanwhile to fix your problem, find out the erroneous object's internal name (just mouse over it and see the name in the status bar), and run the following command.

Code: Select all

App.ActiveDocument.Profile_Edges.Proxy.initOperation(App.ActiveDocument.Profile_Edges)

Assuming the object's name is Profile_Edges. Note you need to change both name in the above code.

[ceremcem]

@realthunder

FYI: I've encountered no problems while building from source.

[Zolko]

New version released.

nice, well done, works with Asm4, and much better: no more opened windows for all linked parts, and LCS have all the same fixed size. Well done, thank-you again.

There was a time when it was said that your branch could become the next v0.19, do you know anything about this ? The current v0.19 doesn't seem to be your branch. Is there hope ?

[realthunder]

There was a time when it was said that your branch could become the next v0.19, do you know anything about this ? The current v0.19 doesn't seem to be your branch. Is there hope ?

I will work on merging the Link part of my branch to upstream soon.

[Zolko]

I will work on merging the Link part of my branch to upstream soon.

that's great news.

There are still some minor bugs and I'm sure they will be ironed out, but there is one major feature that is currently missing from your App::Link implementation and that could be a killer feature for FreeCAD: the possibility to include an external model by passing it a variable. Like calling a function or a library with an argument.

For example, one could make a model of an extruded beam, specify the extrusion length, and when this model is included into an assembly then the assembly can override the default length such that the part is included with the length specified in the assembly :






in this way, you could have a single file for a given profile, and still make complex assemblies with custom length. What's more, imagine building a structure with such beams, each branch having a custom length. If you don't have such a "link with variable" feature, you'd need to make an extra file for each branch of your structure, where the only difference would be the length of the extrusion. What a waste of ressources. And if you happen to modify the length of a branch, you'd have to edit the correponding file. And if you were "smart" and have called the beam according to its length - like beam-30x30x560 - you'd have to change it's name too ! Whereas if you can include a model and pass its length, you have a single file for all branches, and changing the length is trivial: you "edit" the corresponding variable and the model adapts to it.

Another major use-case would be screws: you could add a screw to the assembly, and if you include it by variables you can change its prameters (diameter and length) inside the assembly. May-be changing its style is too, but that might be too complicated and errore-prone. As it happens, there already is such a screw-maker add-on, that allows to make any screw one wants, so it would be easy to add a screw library to FreeCAD and suddenly FreeCAD would be usable even for (quasi-)professional work. Without that, you'd have to have a huge list of every possible screw, and once included into an assembly you couldn't change its parameters without having to re-import and re-position the model.







Technically, I'd say that a model should declare if a variable is "callable" from an assembly, not all parameters of the model should be accessible externally. And when the model is inserted (linked) with a variable, the model is first rebuilt and then linked. If a file is App::Linked multiple times into the same assembly, each instance should have its own value for its variable.

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

[realthunder]

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

Actually, this feature has been requested multiple times in this thread. And my past response is that this is not really a Link feature, because link does not know how the linked object works, therefore it is the linked object that should be modified to support this.

But now, I'd say different. Although my view didn't change completely (that this is not really a Link feature), it is not impossible to do this by only modifying the core. And I have actually already laid foundation in order to achieve this, with the dynamic property feature I added in the current release. The idea goes roughly like this.

• It is now possible to dynamically add any property into any existing object, and each property can have a list of attribute, like read only, hidden, etc.
• A special attribute can be added to signal the property to look for overriding property of the same name (or with some prefix).
• If found, the property can redirect its get/setValue() to the overriding property. So now an object can store its computed value into a set of new properties without changing its computation logic.
• App::Link will look for properties with another special attribute, and inject them as overriding properties into the linked object during recomputation, copy back the computed values, and remove them after done.

Although not impossible, it is still not an easy task. One of the troublesome part is that it require to modify the get/setValue() function of every property. And some object may store state information in non-property variables, and we also need to block view provider update of the linked object, and so on. Despite these difficulties, guess what, in the past few months, I am actually contemplating something much greater using this property redirection technique. I am thinking of running multiple instance of FreeCAD in the background, one for each document, probably without loading GUI module, and redirect property value through inter process communication, or even network, and render GUI stuff in a separate FC process, just like what a modern web browser does. This can solve several problems, like achieving massive parallel scale regardless of FC or Python's single thread nature, or sandboxing the worker process so that we can safely run whatever script code inside, etc. etc. But of course, there are many other details needed to be thought through before I'll give it a try. Maybe this property override feature is a start.

[realthunder]

New bug fix version released.

I have included Python3 Qt5 built for all platforms in this release, also included a few Qt5 related fixes.

[Zolko]

New bug fix version released.

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 ?

OpenLink.png (578.96 KiB) Viewed 1916 times

When right-clicking on a link (in the tree-view) you have to go to "Link actions" and "Select linked Object", which is not very self-explanatory. On the other hand, selecting "Toogle active part" gives an error:

Code: Select all

Traceback (most recent call last):
  File "<string>", line 1, in <module>
<class 'AttributeError'>: 'NoneType' object has no attribute 'setActiveObject'
Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: 'NoneType' object has no attribute 'setActiveObject'

Would it be possibe to include a menu entry "Open Linked Part" right under (or above) "Toggle Active Part", and outside the "Link actions" submenu ? If I'm not mistaken, it happens in ~/src/Gui/Workbench.cpp "void Workbench::createLinkMenu(MenuItem *item)" and the command is "Std_LinkSelectLinked" which is in the sub-menu "Link actions" of the context menu, but I wouldn't know how to add the command correctly.