topic Re: Documenting Intent in Design File in Fusion Design, Validate & Document Forum

Documenting Intent in Design File

davidpbest — Thu, 16 May 2024 18:29:04 GMT

From my days as a programmer, I would never consider writing code that did not have comments embedded that explains what’s going on in the code in terms someone else could understand. Things like the logic, variable usage, etc. So how do you embed comments in a Fusion 360 design file for others to read when stepping through your design? I mean beyond labeling all the bodies, components, sketches, joints, and adding new names to things in the timeline. People have sent me Fusion files and asked for help, and some of their design step decisions are obscure or elusive, and I would love to have had some kind of commentary embedded in the browser or the timeline that were “notes” or “comments” or “annotations” that elaborated on the purpose of a given design step in the timeline, or how some of the more complex functions (like and extrude with reference to object features or construction planes). I suppose I could create a sketch with text notes on it, but that seems pretty obscure way to leave comments in a design file. As manager of a big design department of a large corporation (which I'm not), it would seem this would be a desirable capability since staff turnover is always happening.

Comments/suggestions?

Re: Documenting Intent in Design File

davebYYPCU — Thu, 16 May 2024 19:46:00 GMT

Comment dialogue is bottom left of Design Window.

might help…

Re: Documenting Intent in Design File

TrippyLighting — Thu, 16 May 2024 19:54:55 GMT

@davebYYPCU wrote:

Comment dialogue is bottom left of Design Window.

might help…

True, but that is only one comment for the entire design.

Many years ago, we discussed the idea of a note feature in the timeline. It was well received with the Fusion PM at the time, but never implemented.

Re: Documenting Intent in Design File

davidpbest — Thu, 16 May 2024 20:00:06 GMT

I'm aware of the comment field in the lower right. This is fine when sending a revision between team members, but is not what I'm talking about. You can't describe your design intent for each step in the design process using a single field like this. Please add my suggestion to the queue for enhancements. As programmers yourself, I don't understand how you could overlook such a basic function - or is the Fusion 360 code void of comments?

Re: Documenting Intent in Design File

TrippyLighting — Fri, 17 May 2024 01:03:36 GMT

@davidpbest wrote:

.. Please add my suggestion to the queue for enhancements. As programmers yourself, I don't understand how you could overlook such a basic function - or is the Fusion 360 code void of comments?

I don't work for Autodesk, nor am I a programmer. However, I occasionally write C++ code for embedded microcontrollers.

The Fusion 360 team consists of several hundred people, broken into many different teams that are distributed globally!

The programmers, those folks who actually write the code, are not the ones who decide what functions are implemented.

I personally don't think this feature would be very difficult to implement, but it only very rarely comes up as a request. As such it hasn't gained any traction.

Re: Documenting Intent in Design File

Drewpan — Fri, 17 May 2024 01:58:34 GMT

Hi,

While it may not be very helpful if you start in the middle of the timeline, if you name your components, assemblies

and sub assemblies as you go, in theory you shouldn't NEED to have comments for your MODEL. Remember that fusion

is more than just the modelling part, I can create a full set of documentation directly from my model. Unless I am going

directly to CNC, which would be foolish in many cases, I would be creating the design documents. These documents

should always contain specific information such as tolerances, fits and other technical information that the model

does not directly show to the naked eye. The information exists and should be available and the documentation is the

normal place this stuff lives. If you name everything correctly, when you step through the timeline you can see how

the model was built step by step and the names of the parts should give you a clue as to what the part actually is

and what it does. This is similar to a code comment, it gives you a clue about what the code does.

A model is ultimately just a model, it is not a complete design. You can model it to see if it will work but if you actually

plan on fabricating the model then you have to finish it, which includes the documentation. In the same way that a

computer programmer comments his code, the software specification tells him what to write and the documentation

tells the user what the function is and how to use it.

Bear in mind that I am talking about how the real world should work, not what individuals may do in a small shop.

A big business would create a model, document it and then fabricate it from the documents either by machinists

or CNC it. Records would need to be kept, your documents are part of the record.

Cheers

Andrew

Re: Documenting Intent in Design File

davidpbest — Fri, 17 May 2024 02:14:15 GMT

Thanks for your perspective, but I disagree. I label everything (sketches, joints, body and components, steps in the timeline, etc, etc.) effusively, even add text comments to sketches. But the logic behind the sequence of operations, the relationships between component alignments and interactions, or the intent behind certain sequences of operations can still be confounding to someone who didn't do the design in the first place. With parameter driven designs, brittle dependencies can be tested out, making the design more robust for future enhancement without falling apart with errors, but still, nothing can substitute for a breadcrumb trail on the logic used during the design.

Re: Documenting Intent in Design File

Drewpan — Fri, 17 May 2024 02:33:57 GMT

Hi,

What sort of information do you want to comment then?

If I start a sketch it shows in the timeline. If I extrude something from the sketch it shows in the timeline. If I then

fillet the extrusion it shows in the timeline. It is obvious what I am doing just by looking so what do I need to

comment?

If I need to make a shaft turn and it has a bearing with a press fit then inserting a comment in the timeline is not the

appropriate place for that information to go. The documentation should have those notes. Similarly, I may set up this

shaft with a rotation limit in fusion but I should also document it.

I don't see the need for additional comments and even if you did want to add them in the comments section then you

can still just start a new line for each new comment and refer to the named parts to identify the relationship.

The reason we have documentation Standards is so that anyone trained in the standard can pick up any document

and the information used should be right there so they can understand it. If I have documented that my shaft has

a roller bearing with a press fit then the design intent is also right there in front of me. No engineer is going to write

notes that they redesigned something six times because it didn't work so this is why they ended up with this design.

The timeline would capture the design and configurations or versions would show these design changes.

Cheers

Andrew

Re: Documenting Intent in Design File

davidpbest — Fri, 17 May 2024 02:57:36 GMT

"Best practices" in the software engineering world is to document your code with commentary. I see no reason why such a practice shouldn't apply to a complex physical product design model.

I work with a small collaborative team across the globe on complex products, and when someone picks up a design from another engineer with an assignment to make some modifications, invariably there is a call to the original designer asking things like "what was your intent with these three steps in the timeline" or something else akin to that like "I changed this and I'm getting loads of errors from Fusion, and I can't figure out what you were doing here in the timeline. Help!". So we have started a practice of inserting sketches with text commentary to communicate the more obscure aspects of how the design was derived. This goes much deeper than your example of shaft-to-bearing fit tolerances.

I’m perplexed - as I would think that someone like yourself, who has gone to great lengths to discuss "best practices" with Fusion (rule #1, etc.) in your earlier post about “Learning Fusion” would see the value in this. We don't have to belabor the issue - we just see it differently. But it wouldn't be very difficult for the Fusion team to implement a "no operation, text only" capability to stick in the timeline when people feel it would help others who might inherit the design for modification.

Re: Documenting Intent in Design File

Drewpan — Fri, 17 May 2024 06:39:44 GMT

Hi,

I am not trying to belabour and we obviously don't see quite eye to eye. I am just trying to understand under what

circumstances people would regularly use what you are proposing. I am quite familiar with commenting code in

software engineering I am trying to grasp why it is an issue with fusion.

I am all for standards and best practice because it is the best way to fit into a team environment. It keeps everyone

on the same page. Where I am a little confused is if the outside design team is designing to a standard of some kind

and they produce an assembly that works and fits the standard why a third person would want to pull it apart to try

to understand it? It meets the standard. It works. If there is an issue then sure discuss it, that is normal, but one of

the reasons it was outsourced to another team is because someone cannot do the whole thing themselves. Software

works in exactly the same way.

In engineering the design intent will depend on the specifications. I need one of these that does that for this much

by this time. I know how big it is, I know what it does, I know where it fits. It is like asking someone to make a clay

pot and get them to describe how they do it, they just sit down and make it, they don't think about how they do it. An

engineer just sits down and does it, he may need to do some calculations but part of the idea of modelling is to model

it first then let the computer work it all out. If I was drafting I would have worked out a bunch of stuff first then built

the model. Quite a different mindset and workflow. The other thing is that I send the engineering documents to get

fabricated or the CNC file or the complete model, I usually don't send the whole thing with comments and all.

I suppose what I am saying is that if I ask for a design set to a specific standard then that is what I will get and I don't

need to pull it apart. An example I have used is designing an aircraft. One team builds the fuselage and another builds

the wing. Both pieces will join together smoothly because there is a standard to fit them together. Yesterday the wing

team sent a wing that fits. Today they sent me another one that also fits. I know they are different wings because one

of them weighs a lot less so they obviously redesigned something inside. I don't really need to know what or why they

changed something, they did and it still fits and works with the fuselage. There may be a brief note that the internals

were redesigned to save weight but nothing more. Why would you say "we increased the strut cutout section by 2mm

all around to reduce weight". Sure, now I know what they did and why they did it but does it really matter?

These days many projects are just too big to do things the old way. Not all engineers do things the same way. What

works in one domain will not necessarily work in another. What a small design group does is very different to what

a large one does. Also remember that with software, the compiler ignores comments when creating the code. Think

about the bloat in file size if Airbus or Boeing implemented that all design teams had to document every part design

at the modelling level to assist with design intent. The Airbus A380 was redesigned many times to reduce weight

from beginning to actual cutting of metal and still ended up overweight from what it was meant to be.

I think that this particular suggestion is one of those that might be a nice to have that some people would use, but

not urgent enough to implement as not enough people would actually want it.

Cheers

Andrew

Re: Documenting Intent in Design File

davidpbest — Fri, 17 May 2024 06:51:44 GMT

I will DM you on this rather than clutter this public thread with a continuing debate.

Re: Documenting Intent in Design File

TrippyLighting — Fri, 17 May 2024 11:20:41 GMT

@davidpbest wrote:

I will DM you on this rather than clutter this public thread with a continuing debate.

Please don't!

This is an interesting topic, and members of the Fusion team do read through these posts. Continuing this conversation might well help them decide if/when to implement. I will take this to the Fusion Team Slack channel and ask for feedback.

@Drewpan is correct that currently, this would not be a feature that is much asked for, but that is limited to this and other fora, which are populated mostly by people who don't work in larger team settings.

The Fusion teams work a lot on team collaboration features. In a team setting, I can see this "simple" feature as very beneficial.

Increasingly, work in companies is being distributed across different divisions and locations. A Note feature can be very helpful in such environments.

Re: Documenting Intent in Design File

laughingcreek — Fri, 17 May 2024 15:06:48 GMT

I have always wanted to be able to add notes interspersed in the timeline. notes, bookmarks, section dividers, what ever you want to call it. I think this would be hugely useful whether you working in groups or individually.