Help on using dependency graph requested

[falviani]

Hi,

My setup:
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22319 (Git)
Build type: Release
Branch: master
Hash: 33ef4e0e35fba74c6e2fa3829cfd15c4b6f67e94
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

I have graphviz installed and can get a dependency graph with no issues. My problem is that I have a pad flagged with "multiple solids" and I cannot for the life of me figure out where the error is (file is attached). I have a couple of questions about the dependency graph usage:
1) <Most Important> How can I determine which of the nodes are the multiple solids Freecad is complaining about? The only items outside the body are the spreadsheets.
2) Which direction do the arrows go? I think they go from item->something-item-depends-on. Several of them have 2x or even higher attached, which seems suspicious.

AirAssistDependencyGraph_simplified.png (175.47 KiB) Viewed 143 times

Thanks in advance. If I can figure out how to use the dependency graph as a tool I think I'll be more effective in debugging my models.

Frank Alviani

[chrisb]

You use 0.19 and after a recompute (you can mark the root of the document for recompute to mark everything) you see the first error in "Mainplate". Move the mouse over it and you see the error.

You have to know, that after an error you still see the old state of the object, because no new 3D view could be computed.

Next thing to do is to make the previous feature visible, i.e. Nozzle holder. That's a small rectangle with a hole in it.
Make the sketch MainPlate visible ...

Snip macro screenshot-06d802.png (3.54 KiB) Viewed 138 times

and you will see that padding this will have a connection with the previous feature only if the direction is going down instead of up - check the Reversed box - and that it has to be of appropriate length which would be something around 150mm.

[falviani]

Thanks for the reply

1) You didn't mention the dependency graph at all. I take it you didn't use it to find the problem, just from experience assumed the feature preceding the mainplate was the issue. Is it a general rule of thumb that the preceding feature is always the cause of the 'multiple solids' problem? Is the dependency graph useful?
2) If you have the entire model rendered it's not clear but the plug is at the end of the trough, which overlaps the mainplate to form a single solid. It is intended to end the trough, with a hole through it for the hose nozzle to protrude. The airbrush hose goes down the trough to point at the focus of the laser engraver's beam, blowing smoke away from the material as it's being burned by the laser. The plug is only 3mm thick (that's the default thickness I'm using for this model). Deleting the sketches and features restores the mainplate to a 'working' state.

Again, thanks,
Frank

[jmaustpc]

1) You didn't mention the dependency graph at all. I take it you didn't use it to find the problem, just from experience assumed the feature preceding the mainplate was the issue. Is it a general rule of thumb that the preceding feature is always the cause of the 'multiple solids' problem? Is the dependency graph useful?

Great tool but is not the tool in this particular case.

My problem is that I have a pad flagged with "multiple solids" and I cannot for the life of me figure out where the error is (file is attached).

What you have done is create features in the wrong order such that at one point in your history you have two feature that are not connected, hence two solids which is not supported within a single body. I suspect that your file was correct at some point and that you have accidentally moved the history order some how.

open your file and the feature in error is shown in the treeview section of combo view

Screenshot_20200907_113453.png (71.83 KiB) Viewed 119 times

You started modelling the bottom bits then modelled the top bit and only then try to join them with the additive loft, which is an invalid order, they must intersect at each point of time in the history.

So to fix this I just moved the "top bit" to after the "additive Loft" which is the middle bit. To do that select the faulty feature, then right click to get the context menu, select "move object to after another object...

Screenshot_20200907_114736.png (32.83 KiB) Viewed 119 times

you will then get this dialogue pop up, select the "additive loft"...problem resolved.

Screenshot_20200907_114913.png (26.51 KiB) Viewed 119 times

[jmaustpc]

A screen shot,

Screenshot_20200907_121600.png (97.76 KiB) Viewed 118 times

Is this what it is supposed to look like?

and the repaired file.

AirAssistMount_1-4_v2d_fixed.FCStd

(89.09 KiB) Downloaded 3 times

Jim

OS: Ubuntu 18.04.5 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.
Build type: Release
Branch: unknown
Hash: 34c11fcc63efa2fc72cbc74c75c76e9f19d5c84c
Python version: 3.6.9
Qt version: 5.9.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/Australia (en_AU)

[falviani]

Thanks for the input!I keep falling into deep potholes of ignorance

I've attached an image of what the finished model is supposed to be:

FinishedDesign.png (7.41 KiB) Viewed 112 times

The point of the exercise is to move the trough 2mm closer to the "front", where the vertical straps are extruded. I thought that by attaching all sketches to datum planes or axis planes, I could make the model more robust. It was then pointed out I could simply attach all sketches to just the origin planes and adjust the distances and angles of the attachment. So I switched the support objects to the origin planes appropriately and removed the datum planes. I now am back to having the basic main plate and trough solid, but I hope that if I add the remaining bits in the right order I'll be able to rebuild this correctly. The horizontal plate attached to the trough braces the unit over the acrylic plate holding the laser, while the vertical straps with holes fit either side of the X stepper motor, held in place with a zip tie.

It has certainly been educational. Again, thanks!

[chrisb]

2) Which direction do the arrows go?

I come back to this, as you got excellent answers from Jim on your other question. I had forgotten about it after invesigating your model.
The arrows go from the depending object, e.g. a sketch, to the object they depend on, e.g. the man XY-plane.

If I investigate a model, I almost never look beyond the first error, but it is definitely a good idea to check the step directly prior to it. In your case that was the sketch which looked ok so I went further back.
This has indeed to do with the dependency graph, because I go back and investigate the objects on which the erroneous object depends and then go back even further. But going just up the tree was in your case sufficient.

A different approach would start at the beginning, and check every single step until you find the culprit. For doing so you hide everything and then go down the tree by making visible the next object and investigate it.