PR#2862: Configuration Table using Spreadsheet

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
OficineRobotica
Posts: 433
Joined: Thu Feb 21, 2019 8:17 am
Contact:

Re: PR#2862: Configuration Table using Spreadsheet

Post by OficineRobotica »

realthunder wrote: Thu Nov 19, 2020 10:35 pm
I'm havig a bit of trouble with a file that worked flawlessly prior to restarting FC. The file contains a working config table. After restarting FC , if I go and try to change the configuration of the body in the "Bracket Type" group FC will crash with this error message in the terminal. The strange thing is that it worked flawlessly prior to restarting FC.

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
#0  /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f8619588210]
#1  0x7f84efcac308 in Sketcher::SketchObject::rebuildExternalGeometry(bool) from /tmp/.mount_FreeCAuCb0FZ/usr/lib64/Sketcher.so+0x1f38
#2  0x7f84efcc5d23 in Sketcher::SketchObject::execute() from /tmp/.mount_FreeCAuCb0FZ/usr/lib64/Sketcher.so+0x63
#3  0x7f861ab539da in App::DocumentObject::recompute() from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADApp.so+0x8a
#4  0x7f861471029a in Part::Feature::recompute() from /tmp/.mount_FreeCAuCb0FZ/usr/lib64/Part.so+0xa
#5  0x7f861aae3c49 in App::Document::_recomputeFeature(App::DocumentObject*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADApp.so+0x209
#6  0x7f861ab3b786 in App::Document::recompute(std::vector<App::DocumentObject*, std::allocator<App::DocumentObject*> > const&, bool, bool*, int) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADApp.so+0x596
#7  0x7f861ba25af4 in Gui::PropertyEditor::PropertyEditor::closeTransaction() from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADGui.so+0xe4
#8  0x7f861ba29ecd in Gui::PropertyEditor::PropertyEditor::closeEditor(QWidget*, QAbstractItemDelegate::EndEditHint) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADGui.so+0x4d
#9  /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Widgets.so.5(+0x2f84ff) [0x7f861a4364ff]
#10  0x7f8619aa2a18 in QMetaObject::activate(QObject*, int, int, void**) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0x6c0
#11  0x7f861a4437f4 in QAbstractItemDelegate::closeEditor(QWidget*, QAbstractItemDelegate::EndEditHint) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Widgets.so.5+0x40
#12  0x7f8619aa1594 in QObject::event(QEvent*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0xbc
#13  0x7f861a2b27f2 in QApplicationPrivate::notify_helper(QObject*, QEvent*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Widgets.so.5+0xdc
#14  0x7f861a2b831d in QApplication::notify(QObject*, QEvent*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Widgets.so.5+0x1ac9
#15  0x7f861b74f809 in Gui::GUIApplication::notify(QObject*, QEvent*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADGui.so+0x89
#16  0x7f8619a8c606 in QCoreApplication::notifyInternal2(QObject*, QEvent*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0x86
#17  0x7f8619a8c83e in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0x1da
#18  /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5(+0x1dc54c) [0x7f8619abb54c]
#19  /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/./libglib-2.0.so.0(g_main_context_dispatch+0x27d) [0x7f861613480d]
#20  /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/./libglib-2.0.so.0(+0x54aa1) [0x7f8616134aa1]
#21  /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/./libglib-2.0.so.0(g_main_context_iteration+0x31) [0x7f8616134b41]
#22  0x7f8619abb0e8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0x5e
#23  0x7f8619a89019 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0x187
#24  0x7f8619a8ce8f in QCoreApplication::exec() from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib/libQt5Core.so.5+0xfd
#25  0x7f861b6ca527 in Gui::Application::runApplication() from /tmp/.mount_FreeCAuCb0FZ/usr/bin/../lib64/libFreeCADGui.so+0x1807
#26  /tmp/.mount_FreeCAuCb0FZ/usr/bin/FreeCADLink(+0x44bf) [0x55f2d74d34bf]
#27  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f86195690b3]
#28  /tmp/.mount_FreeCAuCb0FZ/usr/bin/FreeCADLink(+0x47d9) [0x55f2d74d37d9]

Code: Select all

OS: KDE neon User Edition 5.20 (KDE//usr/share/xsessions/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 2021.0125.23662 +3138 (Git) AppImage
Build type: Release
Branch: LinkStage3
Hash: 40e8834692a9f7d1ede120da0181b0361081bd1c
Python version: 3.8.6
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

ConfigTable.jpeg
ConfigTable.jpeg (271.26 KiB) Viewed 10220 times



There is another problem with this file tough. Prior to the crashes I was actually able to change the configuration of the body and make a link out of it. Set the link property "LinkCopyOnChange" to "Enabled". If the Bracket configuration is changed , the link geometry gets all messed up. Triyng to understand why this might be I noticed that some sketches of the linked object lose some of the constrints that actually exist in the parent body thus upon changing the dimensions of the linked braket using the bracket type property , the sketches won't follow the change because of the lack of apropriate constraints messing up the geometry. Could this be related to the interaction between link and the recent sketcher changes?

The configuration table and variant link are such powerfull tools , I really like them.Thank you.
BR
Attachments
Bracket.FCStd
(109.89 KiB) Downloaded 162 times
Check out my Youtube channel at: https://www.youtube.com/@OficineRobotica
User avatar
Kuzma30
Posts: 163
Joined: Wed Oct 24, 2018 11:50 am
Location: Ukraine

Re: PR#2862: Configuration Table using Spreadsheet

Post by Kuzma30 »

I use russian names for Group in Configuration table. It show inncorect as you can see on screenshot. Can you fix this?

Another question.
Is it possible have 2 and more configuration tables in one spreadsheet?
Attachments
Screenshot from 2021-03-08 10-27-31.png
Screenshot from 2021-03-08 10-27-31.png (408.41 KiB) Viewed 10036 times
RealThunder's A3 Wiki translation, join the project https://crowdin.com/project/freecad-asm3-wiki
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: PR#2862: Configuration Table using Spreadsheet

Post by realthunder »

Kuzma30 wrote: Mon Mar 08, 2021 8:45 am I use russian names for Group in Configuration table. It show inncorect as you can see on screenshot. Can you fix this?
Can you please post the file with the problem. I'll check.

Another question.
Is it possible have 2 and more configuration tables in one spreadsheet?
Yes, it's possible. But I haven't tested this. The likely problem you might have is when you insert new rows in top table. The lower table's binding may get messed up. So for now, make sure to leave enough space for your table.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Kuzma30
Posts: 163
Joined: Wed Oct 24, 2018 11:50 am
Location: Ukraine

Re: PR#2862: Configuration Table using Spreadsheet

Post by Kuzma30 »

realthunder wrote: Tue Mar 09, 2021 3:34 am
Kuzma30 wrote: Mon Mar 08, 2021 8:45 am I use russian names for Group in Configuration table. It show inncorect as you can see on screenshot. Can you fix this?
Can you please post the file with the problem. I'll check.
I make test file. Look for text "Error here. Ошибка тут".
Attachments
test.FCStd
(12.95 KiB) Downloaded 157 times
RealThunder's A3 Wiki translation, join the project https://crowdin.com/project/freecad-asm3-wiki
User avatar
czinehuba
Posts: 159
Joined: Mon Oct 15, 2018 4:59 am
Location: UK
Contact:

Re: PR#2862: Configuration Table using Spreadsheet

Post by czinehuba »

Kuzma30 wrote: Mon Mar 08, 2021 8:45 am Another question.
Is it possible have 2 and more configuration tables in one spreadsheet?

Yes it's possible, when you create the config table, make sure change the end of the table from ZZx to the last value of the alias.
I've done some with two or three before.
GinTonic
Posts: 10
Joined: Tue Mar 23, 2021 5:49 pm

Re: PR#2862: Configuration Table using Spreadsheet

Post by GinTonic »

Hello everybody
A couple of months ago I started to look into FC without having any previous CAD experience. Especially I am interested in parametrized design. Recently I stepped across the configuration table concept, installed the link branch from the AppImage and started to explore it. My idea to use it was to have one master body as basis for a set of bodies with the same geometry and derive from it bodies with different dimensions using the configuration table. When noticing that I need to use the copy on change option for this and this breaks the link between the configuration table and the parametrized body and I also did not find a method to "refresh" the parameters after a change in the configuration table I tried to find a solution for this. Below I describe a method that seems to work, reference is made to the sample project file attached.

For better overview I want to have all my parameters in one place so I generate a master spreadsheet (SS in the sample project).

For each parametrized component I generate a spreadsheet containing the configuration table (SS_Board) with references to the master spreadsheet.

A master body is generated in part design (Board) with references to the paramters in SS_Board.

The configuration table in SS_Board is generated pointing to Board.

Links are generated according to the parameter sets of the configuration table (BoardL,..M,..S).

In the links copy on change is set to enabled and the parameter set selected (Large, Medium, Small)

For each of the links we have now automatically generated copies of Board, SS and SS_Board

In order to link the parameters back to the original configuration table I then bind the parameter section of the copied spreadsheets (renamed to SS_BoardL, ..M, ..S) to the corresponding region of SS_Board. Furthermore I replace in the expressions of the links all refrences now pointing to the copied master spreadheet to point to the master spreadheet SS. After this the copies of the master spreadheet can be deleted.

That's it.

So far as I have played with it, this method appears to work. In this context the following comments and questions:
1.) Is this method within the design limits and can I assume it will not break after a future update?
2.) In a more complex project I noted that updates after changes in the master spreadheet are not propagated and either a manual update in the related spreadheet or a close/open cycle is required. I can live with this.
3.) Could this method be implemented as option to avoid the error prone manual interventions described above? Or is this not a good idea?

Thank you for reading and a big thanks to all the developers for this great program.
gin

OS: Debian GNU/Linux bullseye/sid (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 2021.311.24301 +3373 (Git) AppImage
Build type: Release
Branch: LinkStage3
Hash: 91ca94db328bf6126c4a01547b6aa2202d876ebc
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.1
OCC version: 7.4.0
Locale: German/Austria (de_AT)
Attachments
CT03.FCStd
(48.76 KiB) Downloaded 154 times
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: PR#2862: Configuration Table using Spreadsheet

Post by realthunder »

GinTonic wrote: Tue Mar 23, 2021 8:01 pm So far as I have played with it, this method appears to work. In this context the following comments and questions:
1.) Is this method within the design limits and can I assume it will not break after a future update?
2.) In a more complex project I noted that updates after changes in the master spreadheet are not propagated and either a manual update in the related spreadheet or a close/open cycle is required. I can live with this.
3.) Could this method be implemented as option to avoid the error prone manual interventions described above? Or is this not a good idea?
The recomputation only applies to the current active document, and any depending documents. In order to get the configuration table to work, it uses hidden link in some places to avoid cyclic dependency loop, so the dependency relationship between the documents is not obvious in many cases. It depends on which object in which document you modified, the recomputation may not always work as expected. It would be better if you have concrete test case for me to check.

Have you tried using copy on change feature in the SubShapeBinder (the green shape binder), with BindCopyOnChange enabled? This is the prefered object to use if you want to keep the parameterized linkage between the the mutated instance and the original object. Any changes in the original object will be reflected to the mutated instance created by the shape binder. The differences between binder and link is that the binder creates a flattened copy of the bound object's shape, while the link keeps the entire hierarchy of the linked object.

The reason I didn't implement similar synchronization with LinkCopyOnChange is because of the difficulty involved when the user changes other parameters in the mutated copy that are not parameterized by the configuration table. It is difficult to keep those non-controlled customization and yet maintain synchronization with the original object.
Screenshot from 2021-03-27 17-05-38.png
Screenshot from 2021-03-27 17-05-38.png (33.09 KiB) Viewed 9503 times
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
GinTonic
Posts: 10
Joined: Tue Mar 23, 2021 5:49 pm

Re: PR#2862: Configuration Table using Spreadsheet

Post by GinTonic »

realthunder wrote: Sat Mar 27, 2021 9:09 am Have you tried using copy on change feature in the SubShapeBinder (the green shape binder), with BindCopyOnChange enabled?
Thank you for the response and pointing me to SubShapeBinder. I did not try it before. A short test based on your recommendation looks promising. I will need to take a deeper look.
gin
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: PR#2862: Configuration Table using Spreadsheet

Post by realthunder »

New development in Variant Link feature. Since someone just asked, I think it's better to posted it here so that other can know as well. The new feature hasn't been added to the PR yet. I'll add it soon. Anyone interested can try it with my latest release (2021.09.09), either Stable or Daily.

In addition to introducing the new features, this post also serve as a formal introduction on how 'Variant Link' works. The user activates a variant link by changing the 'LinkCopyOnChange' property from 'Disabled' to one of the three other modes,

Enabled: the link copies any properties in the linked object that are marked as 'CopyOnChange'. You can mark any property using the context menu in property viewer. Right click the property, first select 'Show all', then select 'CopyOnChange'. By default, the link will show the property of the linked object in green, and show its own property in black. After the link has copied the properties from the linked object, you'll find it changing from green to black, indicating that theses properties are now owned by the link, and changing them won't affect the original object. Later on, when you actually change any of these 'CopyOnChange' properties, the link will make a deep copy of the linked object, and write back those 'CopyOnChange' property to the new copy, creating the 'variant'. It will then link to the variant, becoming an actual 'variant' link. With the latest development, the new copy and any of its dependencies (remember it's a deep copy) is contained inside a hidden 'LinkGroup' object. You can reveal this hidden group by right click any object in the tree, and select 'Show hidden item'. The purpose of this hidden group is to prevent the new copy (and its dependencies) appear in the root of your object tree, in other words, to help tidy up your tree. Do keep in mind, though, that a variant link is not 'cheap' like normal link.

Owned: 'LinkCopyOnChange' will automatically change from 'Enabled' to 'Owned' once the link makes the copy, which is considered to be owned by the link. If you delete the link, the variant copy (and all its dependency) will be deleted. In fact, much effort has been spent to hide the existence of the copy from end-user. You can just pretend that the variant link IS the copy. There is one user requested the possibility to explicitly make a 'variant link' without needing to change any of the 'CopyOnChange' property. You can now do this by changing 'LinkCopyOnChange' directly from 'Disabled' to 'Owned'. A copy of the linked object will be made.

Tracking: this is a newly introduced mode. After the link makes the copy, it will change to link to that copy, but it will still maintain the reference to the originally linked object in a hidden property called 'LinkCopyOnChangeSource' (PS. you can reveal all hidden properties with property viewer context menu option 'Show all'). The link will actively monitor changes in the source and its dependencies. When there is change in any of these objects, the link will mark its 'LinkCopyOnChangeTouched' property. And when the link itself is recomputed, it will re-create a new variant copy of the source. This is what 'Tracking' means. I personally do not recommend using this mode, though. Because making a new copy is a very complex operation. It didn't just make a new copy. It will make a copy along with all the dependencies, apply variant 'CopyOnChange' properties, recompute the objects, and finally do a global search to replace any reference to the original copies with corresponding new ones. It can go wrong in many places. Another reason is that even not in 'Tracking' mode, the link will still track the original source. But instead of auto recreate the variant, it only changes its icon to signal the divergence to the user. You can choose to manually re-sync with the source by 'Alt + click' the tree icon.
Screenshot from 2021-07-21 17-42-12.png
Screenshot from 2021-07-21 17-42-12.png (29.54 KiB) Viewed 7014 times

Another new feature is for the user to control exactly which objects to copy when making the variant. Right click the link with 'LinkCopyOnChange' set to 'Enabled' (you want to do this before making the copy), select 'Setup configurable object'. A dialog will pop up to let you choose which object to copy. For example, you may want to share a spreadsheet to be used by all variants, so just uncheck it to exclude it from copy. This could potentially avoid the expensive and error prone re-sync operation mentioned above and yet maintain some synchronization among all variants. By default, all externally linked dependencies are excluded from the copy.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: PR#2862: Configuration Table using Spreadsheet

Post by Zolko »

realthunder wrote: Sat Sep 11, 2021 1:12 am With the latest development, the new copy and any of its dependencies (remember it's a deep copy) is contained inside a hidden 'LinkGroup' object.
Why not use a hidden temporary Document to contain the deep copy : with a new hidden temporary document, you are sure that it's empty, thus all copied names will be preserved.? If you copy into the current document, existing names will be changed to keep the unique name principle of FreeCAD, so how do you track the changed (variant) variables ?

Also, is this variant link a C++ construct or a Python object ?
try the Assembly4 workbench for FreCAD — tutorials here and here
Post Reply