Where to store variables, and referencing parent Part

General Development
1

So, I’ve been going through the whole FreeCAD learning curve, using it for prototype design, and of course at first all my models kept breaking as I changed things, learned all about the “toponaming” problem of referencing generated geometry, so have developed a workflow that uses NO referenced geometry and I just place EVERYTHING via expressions based directly on values in a dimensions Spreadsheet. It’s a bit tedious, but it produces very robust and stable models which I can fiddle with and change dimensions and not break things.

However, I’m not entirely happy with the Spreadsheet workflow, especially as it has started to get PAINFULLY slow (updating even unreferenced text fields on the spreadsheet works but hangs the whole program for like 5 minutes or more)! Also, I’d really like to be able to have my variables NESTED, as I kinda have a lot of them piling up, and it’s hard to move stuff around in the spreadsheet. Plus I can’t access these values directly from the tree, which interferes with my workflow, and the Spreadsheet Workbench does not even allow to be in a separate un-docked window.

As I’ve looked around for other solutions, I found this article from last summer on just this subject from Ondsel (who I hadn’t heard of before this, but damn they sure seem active in FreeCAD dev), which agrees with my assessment of a need for a better solution, as I have also tried and found lacking all the options it presents.

I also just (finally) learned that you could add arbitrary properties to any node! This seems almost sufficient, but then the question of where to put these properties. I was hoping to use the App::Part objects to hold this data, like have a set of expression properties right on that object, which pleases my sense of organization, but apparently then none of the geometry objects inside the part can reference them!

TLDR:

I’d like to better understand why that is, why can an object inside an App::Part container not access properties of that container? I’d also like to understand a bit better what efforts are under way to build some kind of core arbitrary variable handling system, and how I can help (my day job is as a software developer, in Java these days, but have a dim memory of writing C++ code in an earlier aeon).

2

The dependencies for recompute are based on the whole objects, not single properties. Changing no matter what in your spreadsheet thus causes a recompute of all objects which use something (dufferent) from the spreadsheet.

An improvement bringing also relief to your structure problem is, to use multiple spreadsheets. There is also something more lightweight: the addon DynamicData workbench.

3

You might look at the Assembly4 workbench. I use it for assemblies, but I also use it as a convenient and lightweight way of storing arbitrary properties that I use as parametric values for almost everything.

Put simply, this workbench adds, among other things, an App::PropertyContainer named “Variables” that contains one property for each “Variable” created using a simple workbench tool, via a dialog box. Once created, you can directly access each variable/property in the Property panel after selecting “Variables” under the “Assembly” object in the Tree or ComboView panel. You can use full ExpressionEngine syntax in the Property panel to create whatever expression you might want for that property value.

You can also reference these variables in other FCStd files, there is a naming syntax for that. This is a nice way to share parameters between FCStd files. Just avoid circular variable references between files and you can do some amazing things. At least that’s what works well for me–two years using FreeCAD and I virtually never worry about toponaming issues.

There is also a DynamicData workbench. I have not used it, but I have seen others recommend it. You might check that out too.

4

Yeah, I have tried using all the other solutions currently, Dynamic Data, Assembly4, etc. I just learned that my idea of just putting custom properties on the enclosing App::Part does work! But you have to reference it weirdly using this hiddenref() method. This discussion here on Ondsel’s github is exactly what I’m talking about.

I posted here in the Developer’s Corner because I’m interested in a technical discussion on the subject, so if anyone can help me understand why this hiddenref() is necessary, or is actively working on a core solution for this important feature, please reach out here or on github. :slight_smile:

5

Hi joshualibrarian, I’m about to start working on this problem. I commented here because that seems to be the best location for a technical discussion at this moment. As I mention there, I would love to discuss this further with you. Your workflow seems similar to mine and I have the same frustrations, so let’s make it better!

6

Hi joshualibrarian, in the meantime I have been studying the problem in more detail and I created an issue in the FreeCAD repo for discussing the problem.