Even the best Fusion 360 designers sometimes end up with errors and warnings in their designs. Those errors and warnings are there for a reason. The purpose of this article is to help you fix your Fusion 360 design when it breaks, and how to prevent those errors from occurring in the first place.

We’ll explore the tools and techniques that are available in Fusion to help you repair a wide variety of Fusion errors and warnings that can happen when working with a design. We’ll show you enough of the internals of Fusion so that you can understand the root cause of these errors. We believe this understanding will help you both to fix the errors when they happen and also how to design/edit in such a way that you avoid ever seeing the errors in the first place. We will only cover the Design workspace and tools, not CAM/Manufacture, Simulation, or Drawings. 

Goals and Starting Principles/Guidelines

There are just a couple of things we want to lead with. Call them tips, or recommendations, or whatever. They are useful, we think, to keep in the front of your mind when doing parametric design.

Fix It When You First See It

This may be the most important point of all. It's really easy to just ignore problems in your model, especially warnings. "It’s just a warning, so I can ignore it, right? I can fix it later, if I have time." If you let errors pile up, they get harder to fix, for a number of reasons. One of those reasons is, the more time that has passed since the error appeared, the less you will remember what design change you made that caused the error.

Barring some Fusion 360 bug, design errors always happen as a result of a change that has been made to the design. When you make a change and an error occurs, stop, understand the error, and fix it right away. Another reason to fix errors promptly is to prevent future problems. If you let an error/warning go unfixed, you may create references or dependencies to bad geometry. Then, if you do fix the problem later, the fix may actually cause further errors from downstream features.

Warnings Are Serious

Another critical thing to remember: Warnings are bad, too. Just because a Warning seems less serious than an Error, you should not ignore Warnings. These are indications that your design is no longer functioning correctly. There are breaks in the parametric dependency that are very important to understand and fix. Just because it is a Warning, and not an Error does not mean that you get to ignore it.

Compute All Is Your Friend

Think of Compute All (CTRL-B) as a kind of a crude “design checker." If a Compute All works, your model is in good shape. Frequent Compute All checks, when rolled to the end of your timeline, are good to do. If you have a large design that may take a few minutes to compute, start a Compute All before a coffee break. After a successful Compute All is also a very good time to do a Save. During Save, I usually put a comment in the version description about “clean model” or something, so I know I can get back to a good state if I need to.

Editing While Rolled Back in the Timeline Can Hide Errors

The one caveat to the statement, “design errors always happen as a result of a change that has been made to the design” is: while those errors technically happen at the time of the change, they may not reveal themselves until much later. If you are rolled back in the Timeline, features that are to the right of the design marker will not compute (that is essentially what the design marker does). But later, if you roll to the end, errors that are caused by an edit will be revealed. So the tip here is: if you are editing when rolled back, be careful to roll forward frequently so as to catch errors as early as possible.

Related: 11 Fusion 360 Tips and Tricks with Scott Moyse

Errors and Warnings and Parametric Design

This section will dive right into some of the internals of Fusion 360 to help understand the nature of Errors and Warnings in Fusion.

Errors and Warnings

Both Errors and Warnings indicate a design failure. What constitutes an Error versus a Warning in Fusion? What is the difference between the two states? What causes these design faults to occur? How is the rest of the design affected by Errors/Warnings? In this section, we’ll explore some fundamentals and Fusion 360 internals from the area of feature status to help us understand errors and warnings more completely.

The Difference Between an Error and a Warning in Fusion 360

A Timeline Error is a compute failure that is so severe that the feature in question cannot successfully compute at all. A Timeline Warning is a failure which is not severe enough to prevent that feature from computing some result. A second major difference between the two is the condition’s effect on downstream features in the Timeline. An Error will block compute of any dependent downstream features, while a Warning will not. We’ll explore this in more detail below.

Another difference is the propagation of the error status to downstream features. A feature with an Error will propagate that Error status to dependent features, while a Warning status allows downstream features to remain in a healthy status.

A Brief Introduction to Parametric Feature Design

A parametric design is a sequence of “features” (Timeline entries) that are computed in a specified order. That order is determined by two factors: creation order, and dependencies between features. This dependency is critical to our understanding of Fusion 360 error handling. We’ll explore the nature of these inter-feature dependencies next.

Want to share your knowledge?
Write an article for AU

Feature Dependencies

What causes a dependency between features? If Feature B needs geometry or topology produced by Feature A, then we say: Feature B depends on Feature A. In the UI, this is always because of a geometry selection in a feature creation command.

For example: When you select a profile for Extrude, you create a dependency between the Sketch that owns that profile, and the Extrude feature you are creating. Selecting an edge to Fillet creates a Fillet feature which is dependent on the feature which created this edge. If you use a Box feature to create a solid body, then Fillet one edge of that body, you have created a dependency between the Fillet and the Box feature.

Here is a more concrete example:

• Sketch1 contains a rectangle
• Extrude1 produces a solid body from that rectangle
• Offset Workplane1 created from the end face of that Extrude

This Timeline creates this set of dependencies:

• Extrude1 depends on Sketch1 (for the profile)
• Plane1 depends on Extrude1 (Extrude1 produces the reference face)

What are the implications of these dependencies?

1. Order of compute. In this case, the Timeline order is the same as the dependency order, but there can be cases where features can compute (or partially compute) out of Timeline order.

2. Dependencies determine what gets computed when you make a change. If you edit a sketch, every feature which depends on that sketch will get computed. If you edit a feature, every other feature which depends on that feature will get computed.

3. You cannot reorder a feature in the Timeline before one on which it is dependent. In this simple case, that should be obvious (you cannot reorder an Extrude before the sketch containing its profile, or an Offset Workplane before the Extrude that makes the face it uses), but other cases can be a little less obvious.

4. Error propagation. This is the important point. Errors in a feature can propagate to dependent features. We’ll look at this in more detail later.

The important things to remember regarding feature dependencies and error handling:

• The dependency system is the core technology behind parametric design. It is what makes the design “parametric” in the first place. The dependency between a Sketch and an Extrude is what allows you to edit that Sketch and have the Extrude update when you exit that sketch. This is the core distillation of the power of parametric design. 

• Any dependency is a potential source of an error. Almost all feature errors you encounter will be caused by a dependency failure. We’ll cover this in more depth below.

• Be careful and intentional when creating dependencies. More dependencies means more potential failures. Sometimes you need to create dependencies, but there are plenty of times when one dependency or another is not needed, so avoid those if you can. Sadly, Fusion makes this problem worse with some of its default settings and behaviors. We’ll show you what options to set to avoid the worst of these. These settings were chosen, ironically, to make Fusion appear to be easier to use. And, to some extent, that goal is achieved. However, that ease of use comes at a cost of creating a brittle design. So, it’s debatable whether these ease-of-use settings are really an advantage or not.

Parametric Naming and Matching

Another important topic to understand in trying to understand design failures in Fusion is a subsystem that we internally call “Naming and Matching.” This directly relates to the Dependency topic above, as most of the dependencies in the system are handled here.

This system can be described at its most basic as: Naming and Matching is the way in which Fusion 360 tries to remember what you selected in creating a feature (Naming), and making sure that the same entity is found again at the time a feature is computed (Matching). Most dependency failures (and therefore most feature failures) are caused when a Fusion Match fails to find the right dependent object at compute time. We’ll dive into this subsystem in a bit more detail later.

What Causes Fusion Design Errors?

This section will cover the most common causes of design Errors/Warnings in Fusion. As stated above, nearly all Errors or Warnings are caused by edits to the design. Or, to say it another way: Any design fault is caused by... you. A design which does not have any Errors or Warnings will not spontaneously create Errors. If you’ve done a Compute All, and have not made any design changes, that design will continue to be healthy the next time you access it. In all cases, some design change is the underlying cause of Errors or Warnings.

Not counting data management errors, or other non-Design errors, there are two main categories of design errors:

• Geometry errors
• Dependency errors

Geometry Errors

This type of error seems to be a less common error, but let’s discuss it first, so we can spend more time on the more common error type. Geometry errors include failures that are purely because the operation cannot be completed. For instance, if a Fillet fails with the error “Fillet could not be created at the requested size,” it is because the modeling kernel itself cannot produce the fillet faces. These kinds of errors occur in features like Shell, Fillet, Face Draft, Loft, and other complex modeling features.

Dependency Errors

This type of error accounts for a larger percentage of all design errors. Reference errors are caused when a dependency (see above) for a feature is not resolved (or, the wrong number of them is found) at the time a feature computes. For example, in the case of an Offset Workplane from a body face, if the face that was referenced cannot be found, then we call that a matching error. Any dependency to geometry that is selected in creating a feature is a potential matching failure.

Types of Dependency Errors

There are three basic ways in which a Matching Error can occur:

1. No Match Found. If no match at all is found for a feature input, this is a direct failure. For example, Work Axis Through Edge has only one geometry reference – a linear edge. If the edge cannot be found, an error occurs.

2. Too Many Candidates Found. This kind of Matching failure happens if a feature is expecting N matches, but N+1 or more matches are found. This usually happens with face splitting or edge splitting. A reference that was a single entity at the time the feature was created becomes two or more entities due to an edit. As we’ll see below, different features can handle this case differently.

3. Mixed Results. In this type of Matching failure, some references get resolved, some do not. Obviously, this cannot happen if a feature only has one reference, but features like Fillet or Chamfer, or Sweep Path, where multiple objects can be selected, can fall into this category.

Two Different Kinds of Geometry Dependency

Fusion 360 has two basic types of geometry reference or dependency: Geometry dependencies, and Topology dependencies. Geometry dependencies mean that the consuming feature is reliant on the geometry of the selected entity. Examples of this include: Offset Workplane (needs the plane of the selected face, not the face itself), Project Edge in Sketch (needs the underlying curve of the selected Edge).

Topology references, on the other hand, need the actual Edge, Face, Body, Vertex, etc. to succeed. Features such as Fillet, Shell, etc do not operate on the geometry of the item, but directly on the item itself. You cannot Fillet a line or an arc – you must fillet a model edge directly, because the edge will be consumed by the Fillet, adjacent faces will be modified, etc.

Geometry reference failures result in Warnings, while Topology reference failures result in Errors. Herein lies a fundamental concept in understanding the difference between an Errors and Warnings. A failure in a Geometry reference will result in a Warning, while a failure in a Topology reference will result in an Error.

Why the difference? Why is one type of failure a Warning, and the other is an Error? Because a geometry reference automatically caches the geometry on each successful compute. Then, when a Matching failure happens, that cache can be used to compute the feature. So, for example, if a geometry reference for an Offset Workplane fails, that feature can cache the plane definition used on the last successful compute to continue to produce some result. It is important to realize that, though a result has been computed, it might be an incorrect result, in that it is no longer connected to the geometry. However, Fusion 360 cannot cache a Topology reference. You need the edge itself in order to compute a Fillet. You need the Face/Body to shell a body. So, there is no way to recover from this kind of failure, hence, an Error is reported.

Each Feature May Handle Matching Errors Differently

When a Dependency Error happens, the effect on your design will depend on the feature involved. While most features react pretty predictably to a Matching failure (a Geometry reference failure causes a Warning, a Topology failure causes an Error), there are some important exceptions that are worth discussing. One is Fillet/Chamfer. These are examples, as we discussed above, where the feature tracks multiple entities. However, if only some of these references fail, the feature can continue to compute those edges that do match correctly. So, even though these are Topology references, a failure does not mean an Error will result – as long as there are some edges to Fillet, a matching failure will only result in a Warning.

Another example of the per-feature behavior difference is how multiple candidates are handled. In some cases, if a feature expects a single matched entity and it discovers more than one exists, an Error will occur. However, other features can handle multiple candidates differently. For instance, in Fillet, if an edge is split, and two candidates are returned where one is expected, Fillet says, “I can just Fillet both of those edges.” So this is not even returned as a Warning state. In other cases, it will depend on the nature of the feature. Some features (such as Offset Workplane, or WorkAxis through Edge) will just select the “first” candidate and ignore any others.

Want more? Download the full class handout to read on.

Jeff Strater is a senior software architect in the Fusion 360 team. I've been with Fusion since the very beginning. My focus is on general modeling/sketching. Before that, I was a developer and architect on Inventor, also before R1. So, I’m a long-time CAD guy. When not working with Fusion or its customers, I like to run, cycle, hike, and read science fiction.

Phil Eichmiller is a senior software quality assurance engineer for Autodesk, on the Fusion 360 team. In addition to testing and designing with Fusion 360, he enjoys working with the Fusion online community, presenting, and teaching Fusion 360. He used Inventor software as a product designer for 16 years. He enjoys sharing his knowledge by teaching Fusion 360 for the CAD program at Portland Community College. Roller Derby is his favorite pastime, especially watching his daughters, who are both derby stars in Portland, Oregon.