Is there a mechanism to list Dependencies of elements in the Browser or Timeline?
I'll tackle it on my own.
If it is completed, only those who want to use it can use it.
It takes a very long time to complete because I am learning as I go along.
For now, I have only created a dependency with a feature that has a profile.
I don't even know what information is desired and how it should be displayed.
@kandennti that looks like a very promising start.
In general, what you'd display is akin to a node graph an network structure. It would not be a simple list!
I only understand Japanese, so I hope I can communicate well.
I have been busy with work and have not been able to work on the add-ins very much.
I also have a few problems and would appreciate your input.
The first concern is how to display the following operations.
Create a sketch and extrude it. Create a sketch again and extrude it.
The second extrusion is done as a new body.
At this time, if you display the dependencies, it will look like this.
This in itself is not a problem.
Next, combine the two bodies. If you display the dependencies here, you will see
At this point, when the dependencies are displayed, it looks like this.
Unable to retrieve information on body 2.
The way Combine 1 gets the information that Body 1 and Body 2 are related requires that the timeline marker be moved to the front of Combine 1.
It should not be any further forward. It must always be before one.
This is not a specification of the API, but of the Fusion360 CAD system itself.
What I am wondering is if I should move the timeline markers around to get the correct dependencies.
I won't know until I actually build it, but for long timelines It could take a long time to display.
Attached is the add-in I am creating.
It is still incomplete, but it can display what I have described.
After launching the add-in, commands will be added in the following areas.
Another problem is how to display dependencies.
At first, I was thinking of using only timeline elements to represent dependencies in a graph structure.
However, although we could obtain information on which body a feature such as a fillet or chamfer depended on, there was no way to obtain information on which feature it depended on.
Therefore, we decided to include the body.
I have not worked with many 3D CAD systems so I don't know much about them.
I believe that most 3D CAD history systems probably use a linear time series system like Fuison360.
I use CATIA V5 in my work and the CATIA history system has a tree representation of dependencies around the body.
It may be a matter of familiarity, but I personally find this representation easiest to understand.
I am thinking of abandoning the current representation of timeline elements in a graph structure and switching to a tree representation centered on the body, but it will be mostly a reworking.
Should we think easier?
Hi Kandennti-San,
You have taken … on the formidable task!
The dependency of design elements in F360 can be pretty daunting. Assuming that API exposes all interdependences (I doubt it), the respective graph in the general case will be very complex. The recent changes (and possible? future developments) to processing/calculations of userParameters algebraic function set might make tracing interrelationships of elements even more difficult. It would be challenging to estimate (if even possible) the algorithm cost of creating a full interdependency graph. Assuming that it is represented by a complexity estimator function T(n)=O(2^n) and n=2 (optimistically), it is evident that the cost will grow very fast. One way to contain it would be to concentrate on a limited set of elements (e.g. one body, component, sketch…) and not on the whole design. The outcome could still add valuable information to the designer, not to mention it would bring along simplification of things. The question here is how efficiently F360 exposes dependencies. From my own experience, I know that scanning timeLine is relatively slow. An alternative would be to query design elements directly.
Regarding the type of dependency graph to choose at this stage of development, the off-the-shelf attire … might be the fastest to implement and also without too much labour. The question is, would linear, tree graphs types accommodate the design complexities and convolutedness of F360? My feeling is … no, they will not. Alternatives … consider looking at ‘multidimensional graph theory’ …
All The Best With The Task
MichaelT
@FrancoGabrielPerez wrote:If the program knows that another feature is referencing the one I try to delete, can't it at least show me the name of that feature? even if it's not the most helpful it's better than nothing.
It is not hopeless. A solution is in sight:
Since Fusion will not do this for you - simply start a new discussion thread and Attach your file and I will do it for you.
@TheCADWhisperer (great name haha) Thanks for the offer, I already solved the problem, it's not hard just time consuming.
What I meant by hopeless was the focus of the developers, we get things like generative design, which are awesome don’t get me wrong but other more basic things get pushed to the side in my opinion. Like better info on dependencies or exiting a sketch without saving the changes you just made or being able to dimension an "Arc/Path Length". And I get it, flashier new features sell the product better, but new features don’t keep me in Fusion, ease to use does.
@kandennti what you are doing is awesome, I’m not familiar with developing add-ins so I wouldn’t know where to start with something like this. What language are you using for development?
I’m also not a native English speaker, I understand the hassle of using a translator, you communicate perfectly. For me al least, it’s a pain to use a translator to write replies, on the positive side, here I am talking to a Japanese person.
I’m going to try you add-in and hopefully give you some useful feedback.
Dear kandennti
If you can make such a thing work and be understandable, that would be very impressive! (your ability to communicate in English already is)
Personally, I would be very happy with a simple display of dependencies for an individual item. That shows the parents and children of any clicked-on sketch or operation. SolidWorks does it like this:
From the context menu, you can also get them displayed in detailed list form I seem to remember.
I haven't found any equivalent in Fusion. My earlier suggestion (suppressing the item and seeing what else is suppressed) doesn't work well - it is slow and often shows up "dependencies" that simply aren't there.
It's just frustrating when I try to move or remove or adapt a feature in the timelines, and it says "other features depend on this" but gives you no suggestion what they might be. A way to see them would be frequently useful, and I am personally less interested in seeing something that tries to communicate how an entire solid model is constructed.
Thanks
David
Finding a feature that will generate a warning when deleted can be created with a relatively simple script.
For example, if you delete sketch 3 in the sample data here, you will get warnings for extrusion 3 and sketch 10.
If you run this script and select sketch 3, a dialog will display the results.
# Fusion360API Python script
import traceback
import adsk.fusion
import adsk.core
def run(context):
ui = adsk.core.UserInterface.cast(None)
try:
app: adsk.core.Application = adsk.core.Application.get()
ui = app.userInterface
msg: str = 'Select Feature'
selFilter: str = 'Features'
sel: adsk.core.Selection = selectEnt(msg, selFilter)
if not sel:
return
feats = getDependentFeatures(sel.entity)
ui.messageBox('\n'.join([f.name for f in feats]))
except:
if ui:
ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))
def getDependentFeatures(feat) -> list:
app: adsk.core.Application = adsk.core.Application.get()
des: adsk.fusion.Design = app.activeProduct
def getPoorHealthEntities() -> list:
return [tl.entity for tl in des.timeline
if tl.entity.healthState != 0]
# ****
app.executeTextCommand(u'Transaction.Start temp_remove')
des.timeline.moveToEnd()
beforeTokens = [e.entityToken for e in getPoorHealthEntities()]
feat.deleteMe()
dependentFeatures = [e for e in getPoorHealthEntities()
if not e.entityToken in beforeTokens]
app.executeTextCommand(u'Transaction.Abort')
return dependentFeatures
def selectEnt(
msg: str,
filterStr: str) -> adsk.core.Selection:
try:
app: adsk.core.Application = adsk.core.Application.get()
ui: adsk.core.UserInterface = app.userInterface
sel = ui.selectEntity(msg, filterStr)
return sel
except:
return None
Here is a video of the actual test.
The mechanism is simple: the API actually deletes the feature, finds the feature that causes the warning, and returns it to its original state.
The problem is, as you can see in the video, it takes a long time to find them. For those who want this feature, it is an excruciatingly long time.
FreeCAD has the ability to generate dependency graphs; if I remember correctly they integrated an open source package. Surprised Fusion doesn't support it.
One use I bumped into is starting off a project with some simple base sketches. Over time the base sketches can get more detailed and cluttered so they need to be refactored in separate dependent sketches for clarity. Fusion does a pretty good job of managing extrude profiles when overlapping profiles are added to a sketch until it doesn't. A dependency tree would show when a body's references to a base sketch have been fully removed at which point those base sketch features can be removed.
I used to jam everything into a few base sketches, but now I am finding it useful to create a multitude of dependent sketches.
In a component with a hundred sketches you could also spot sketches that no longer have dependents and can be removed.
It has been quite some time, but I was able to secure a decent amount of time, so I resumed some work.
I was quite lost, not knowing what information to present and how to present it.
To summarize, I gave up on the idea of using a graph structure.
I created some small scripts and worked on them, but I was not able to retrieve as much information as I had imagined.
Therefore, I decided to use a tree structure instead of a graph structure, although I cannot explain the reason in detail.
This representation is similar to the history of CATIA V5 that I use in my work. (I personally think this is an excellent representation)
The poor display will be improved in the future.
The data being tested is the data here.
Basically, the body is represented as the center, and the elements within the body are arranged in chronological order.
We believe that we have been able to express the dependencies of the body better than the current timeline.
Currently, the only function available is to highlight the data by typing search words in the search section.
In the future, we would like to add a "Find in Window" function from Tree elements.
The code is very incomplete, but it is available on github.
This looks like a really worthwhile step forwards. Well done and thank you!
Can't find what you're looking for? Ask the community or share your knowledge.