Bug with computed sketch dimensions

[Witsend3486]

Hello,

I just hit this in the past few days: Fusion wants me to delete a dimension before it will allow me to change that dimension.  It seems to relate to dimensions that involve a computation, even a simple one such 12/2.  I get the message "Failed to solve.  Please delete or modify one of the following constraints/dimensions: d63...".  Dimensions that are simple literal values (like 6) don't seem to have a problem; I can change them to 7 or whatever without a hitch.

When I take Fusion at its word, delete the dimension, and try to re-dimension the feature, Fusion then says "Adding this dimension will over-constrain the sketch.  Choose OK to create a Driven Dimension."

This is a link to a project with the problem.

What I've done...

1. I entered a copyright statement in the comments, posted it, and closed the comment window.  (This doesn't seem to be important.)
2. I loaded a bunch of user parameters from two files using a free app from the app store.  (I don't know if loading via the app is important.  The app seems to be ParameterIO.py version 1.2.0 by Wayne Brill).
3. I set looking into the +X axis as the front view (also probably not important).
4. I'm modeling a full-scale prototype that is to be scaled down later for a model.  I set a number of dimensions by 'upscaling' them from what I want them to be in the model to what they would be in the full-scale prototype.  Thus, I originally thought I wanted d63 to be 3/16ths of an inch in the model, so I divided it by D$Scale (the scale factor) to produce the full-scale size.
5. I did similar things as far as I got in the sketch.  A number of dimensions are upscaled in the user parameters -- for example, D$Brg_P_ID is defined as D$Brg_ID/D$Scale.
6. Other dimensions are simply calculated from literal values, usually things like dividing a diameter by 2 to produce a radius.
7. Things were going fine until I changed my mind and decided d63 ought to be 1/4 instead of 3/16ths.  When I clicked on the dimension, edited 0.1875 to be 0.25, and hit 'return' Fusion came back and said "Failed to solve.  Please delete or modify one of the following constraints/dimensions: d63..."
8. I also tried changing d65 (across the very top of the sketch) which is just a calculated dimension from literal values (49.125/2), but doesn't involve a user parameter, and got the same problem.  d59 (the left side of the sketch) is just a plain, literal number (6) and it doesn't seem to have a problem.

This seems to be a relatively new problem since I've done this within the past month or two without a problem of any kind.  In the most recent update, I seem to recall something about fixing the sketch engine (making it more robust or something) -- this sounds like a good place to look.

I've attached the Fusion 360 Diagnostic Log File.  I just got the most recent Fusion update bringing me to version 2.0.5044.  Windows 10 Home is on automatic updates so heaven only knows what Microsoft has me running.  I rebooted (but did not power down/up) yesterday morning hoping that would cure the problem, but it didn't.

I searched the forum but didn't find anything recent that looked similar; unfortunately, I'm not very good at searching forums.

Respectfully,

Bill

[TrippyLighting]

I have to admit that I don't have the patience to debug this overly complicated sketch.

First I'd try to simplify the sketch.

It looks to me that this sketch would be used to create several components from. I'd break that into individual sketches separate for each component.

Then fillets really don't belong in sketches if they can be modeled as solid features.

That alone will help keeping the sketches simpler and usually make the way easier to debug.

[Witsend3486]

Peter,

1. I don't think this is a problem with the sketch, I think it is a problem with the sketch constraint engine.
2. I think the code trying to change the dimension constraint is looking through a list of constraints that the changed dimension might conflict with and not recognizing an identity between the constraint it wants to change and the constraint it thinks it is in conflict with.  Somehow, been a computed constraint is adding to the confusion.
3. I think I've made that sort of mistake before, although not in the context of a CAD geometry system.  I think it was in a deadlock detection algorithm for a net-distributed lock mechanism -- I neglected to see if the instance holding the conflicting lock was the thing requesting the conflicted lock.  It got complicated because it was X held A and wanted B, Y held B and wanted C, while Z held C and wanted A, except more generalized.  All the players could hold many locks and the entire spreading chestnut tree had to be searched -- figuring out when you'd run into yourself got challenging.
4. I've done this sketch before back in May 2017 without a problem.  I hesitate to re-open that one for fear the updated code might break it.  There are a few new wrinkles this time around, but nothing that I would have thought would have broken Fusion.

Respectfully,

Bill

[lichtzeichenanlage]

Fusion 360 works best with small, simple sketches. So doing everything in one sketch doesn't work well wit Fusion 360. The reason is, that the sketch engine has problems. Sometimes performance, sometimes stability. AD has changed things in latest release and perhaps this doesn't worked out well for you. 

All that said, you could easily simplify your sketches by

• Remove all the fillets from the sketch and apply them as features in the model environment.
• You could easily split your sketch in 3 to 4 separate sketches.

[TrippyLighting]

Once you've followed our advise and simplify your sketches with the methods described and still run into problems, please report back. 

[davebYYPCU]

This sounds like the recent update is breaking the older model type stuff, 

you will likely need AD to review this.  They announced stronger robust sketching.

Maybe @jeff_strater, will know who to tag.

[TrippyLighting]

---

@davebYYPCU have you reviewed the design ?

[davebYYPCU]

No.  Just read the thread so far.

[TrippyLighting]

via GIPHY

[davebYYPCU]

and I can't see anything in A360, out the door now, back tomorrow....

[lichtzeichenanlage]

[jeff_strater]

@Witsend3486, this probably is an issue with the sketch solver.  Nearly impossible to say whether this is some new failure caused by recent changes or not.  

The sketch itself is not overly complicated for Fusion, but the parameter relationships are hard for me to try to untangle to try to figure out what might be going on.  Still, Fusion should handle it.  If you want to help us debug this, reducing the size of the design and parameters to a point where it is easily understandable would be a big help.  Otherwise, it will just take us longer to look into this.

I have the design, and can reproduce the problem:  edit d63 from "( 0.1875 / D$Scale ) * 1 in" to "( 0.25 / D$Scale ) * 1 in"

I can't say offhand that the error is wrong, but I'm willing to believe it is.

[Witsend3486]

Jeff,

Here is a simpler version of the project that still has the problem.  If you try to edit d37, the value 5.445754 in the middle of the sketch, you get the message that you need to delete that dimension in order to change it.  The only user parameter that has been used to this point is D$Scale, and that has only been used in d36 to upscale 0.1875 to prototype size.  d35 and d32 have been calculated using only literal values, both being divided by 2 -- d35 to convert a symmetric dimension to an offset from the line of symmetry and d32 to convert a diameter to a radius.

The user parameters were still loaded from a file using ParameterIO.py, but I doubt that has anything to do with the problem.

The rest of this you probably don't need to know, but here it is....

What is going on here is a layout sketch for a drive box for a steam locomotive to be built as a scale model.  The drive box includes

• The containing box,
• Tapered roller bearings at each end (described by the D$Brg_x parameters using Timken nomenclature),
• The axle (12" diameter at the center, 13.625" diameter at the wheel mount,
• Containing bearing covers,
• An array of half-threaded Moire holes drilled across the bearing cover and drive box threaded interfaces to accommodate locking set screws once an appropriate bearing pre-load has been set, and
• Assorted O-rings.

When the layout sketch is complete, individual components are to be declared and detailed sketches, as needed, will be derived from the key elements of the layout sketch.

The object is modeled in full, prototype size but is to be built as a scale model, thus the scale factor of D$Scale.  Certain dimensions are specified in model size and need to be scaled up to prototype size in the CAD model.  d37 is one such dimension, being the width of a groove in which to terminate the threaded bore that the cover is to screw into.

The bearing to be used in the model is a (Timken) 18690-18620.  Its key dimensions are recorded in the D$Brg_x user parameters.  Since it must be modeled in the prototype size, all of its dimensions are then upscaled as D$Brg_P_x user parameters by merely dividing the corresponding D$Brg_x parameter by D$Scale.  Note that none of the D$Brg_x parameters have been used yet in the simplified project above.

This...

954CA28572 Bearing Box Section with Axle and Wheelsis a cross section of the same assembly done back in May of 2017.

This time around I'm trying to be a little more sophisticated in that I am now affiliated with a group that wants to build this model steam engine in two different scales: one for a track gauge of 7.5 inches and one for a track gauge of 15 inches (they swear they are not crazy).  This will involve two different bearing selections since there is no bearing (that I know of) that is exactly twice the size of the 18690-18620 set.  The likely bearing for the larger model is a 52375-52637 set.  My plan is to load (again using ParameterIO.py) an overriding D$Brg_x parameter set with the larger scale factor and the key dimensions for the larger bearing set and let the parametric CAD engine of Fusion regenerate an appropriately adjusted prototype-size design.  If it works, which I expect it will, I will then be able to rapidly accommodate any reasonable scale request; for example, someone who wants to build a 16 inch gauge engine.  All of this might reasonably cascade into any associated CAM work, too, although I haven't thought about how to automate the selection of different size tools (I'm not much into CAM yet).  It seems like a sophisticated, but reasonable, use of Fusion 360 to me. 

I will admit there are still some product data management issues left here -- I will have to keep straight in my mind which scale variant is current in the project.  The only way to tell currently is with the D$Scale value and N$Brg_Ident user parameters.  Well, nothing is perfect.

(Perhaps this would have been well done in Branch/Merge but, as I recall, Branch/Merge is now deprecated.)

(Actually, if you wanted a new Fusion feature, the ability for individual components in a project to override base user parameters might be nice.  Then a component could be copied within a project and key parameters overridden to create an object inheriting all the base object features while overriding key elements of the base design.  But that is for another day and would require considerable thought as to the possible ramifications, especially regarding downstream effects.)

Respectfully,

Bill

[jeff_strater]

Thanks, @Witsend3486, for the detailed explanation as well as the trimmed-down version of the design.  That is exactly what we need.  Unfortunately, when I load this model and edit d37, it seems to work.  Am I doing something differently?

[Witsend3486]

Jeff,

Yes, when I open the sketch, double click the dimension, and enter a literal (like 5), it works for me, too; however, if I try to set the dimension as "0.0625/D$Scale", I get the problem.

Background:

The sketch element being dimensioned is supposed to be a groove for a threading tool to finish its cut in.  In real life, I think I can get away with that groove being about 1/16" wide.  With the right threading tool that ought to leave room for the tool to stop before bumping into the shoulder leading down to the somewhat smaller bearing bore.  It also corresponds to about the smallest grooving tool I think might be able to cut a deep enough groove so that the threading tool is not dragging its tip in the relief groove when it stops.  (I haven't been a machinist in a long time and, from what I've seen on YouTube, machining has come a long way since then, so I may be quite out of touch on what can be achieved these days.)  I made the bottom of the groove (the dreaded) round (fillet) to avoid the stress risers of square corners.

Being the size I expect to machine in the model, it needs to be scaled up to prototype size so that, when the prototype is scaled down to be a model, the groove comes out being 1/16" wide again.  (Now that there are two model scales involved, I need to insert some more trickery so that the double size model ends up with a 1/8" groove, but that is a problem for another day.)

Thank you for taking the time to look into this, especially so on the weekend.

Respectfully,

Bill

[jeff_strater]

Thanks, Bill, I can reproduce the problem now.  Very thankful for the work to narrow the problem down.

Interestingly, the problem (at least in this instance) seems to be not one of computed sketch dimensions, but one where the value changes a lot, a special kind of a geometry problem.  0.0625/D$Scale evaluates to 0.47, so the value is going from 5.5 or so to 0.47.  This causes the solver failure.  This is an important bug for us to look into.  And, it may be a recent regression, although I can't say for sure.  Interestingly, if you approach the change gradually, you can get there.  I understand that this is not really an acceptable workaround.

here's a screencast showing the problem boiled down even further (getting rid of all the user parameters except D$Scale:

[lichtzeichenanlage]

@jeff_strater: Are you experiencing the same issue without the fillet in the sketch?

[jeff_strater]

@lichtzeichenanlage, do you mean the arc with the tangent constraints?

yes, I find if I remove this arc and replace it with a line, I do not see the problem.  Clearly, it is some problem with the tangent constraints on the arcs.

[lichtzeichenanlage]

@jeff_strater_ Sry - yes.

[MichaelT_123]

Hi Mr. Witsend,

As a preamble, please note that I am not Autodesk insider/associate/advocate/etc. and my view/ opinion/tenet is made from my subjective perspective as a user of the software.

So, where to start…

As I have noted, you have had worked for NASA, and apparently, you have developed a custom of dealing with complicated things as I also impute from your sketch. It is a nature of some minds to challenge complexity (good for you, Sir) and the name of it is the progress. One, however, must realize that there is also a risk of a failure, as in your sketch attempt example.

Failure is not a bad thing. It is an opportunity to look deeper for the cause of it.

The obvious one is that the complexity was greater than the capacity, whatever they mean.

The another, in this case, is a technicality (science) of the subject.

The sketch, composed by curves (cx), points (px) and relations /constrains/parameters (rx) between then can be represented by an abstract function SF(c1,c2,.. p1,p2,.. P(r1,r2)).

As relations (rx) might not be necessary permutable, so they are enclosed in the function P(r1,r2,…). 

On the side… jingle %, jingle %, T_F360,  such constraints order shuffling function would be useful!.

In order to fulfill design process objectives (and land safely on Mars), the function must return a singular outcome. In F360 jargon, such status is called a fully constrained sketch. When it returns more than one state, e.g., one in mm and the other in inches it will result in crash landing (… just a joke, I could not resist, please forgive me…) as your design approach resembles the event when on the mission to Mars… exotic SI units have been used instead of the robust imperial system!

In general, SF arguments (cx,px,rx) have their permitted domains in their respective spaces. They are conjoined or are in the reciprocated states. They are interdependent. In space/cosmos analogy the movement of a single mass object influences trajectories of the whole swarm of them.  More likely than not they have their permissible (or probable) value ranges (states). As the previous sentence implies these ranges are dynamic, they depend upon the rest of SF(…) arguments.

On the side… jingle %, jingle %, T_F360, calculating such ranges would be the useful addition to sketch/design constraining process.

Possibly it would lower the risk of hearing on a telephone (internet) line:

‘Hello, hello,... NASA calling… .T_F360 we have a problem…’. (…just a joke… could not resist... please forgive me).

On practical note Mr. Witsend, what to do in your particular case?

As some interlocutors in this thread indicated, simplification of design approach could be a good choice.

However, if for some reason you want to stick to the current one, you may consider:

• Checking the validity of your functions/constraints. I have had some glimpse of them; however, I am a pity to say, that they are beyond my short-range capability.
• A possible culprit is a scaling factor (omitted or placed in a wrong place)
• Using heuristic method (slowly changing its value) try to devise its permissible range (might be the single value though)
• If you really want to find out systematically when/where your mental process or/and F360 machinery failed, build up SF(..) for your case (set of algebraic equations) and solve it. It might be quite a laborious process though and, in my opinion, if it is methodical and successful, deserving Nobel’s price for an excessive determination. 
• On the side… jingle %, jingle %, T_F360,  it would be not so difficult to perform this analysis inside F360 machinery, resulting in a very sophisticated sketch and even design debugging toll for these pervasive problems. 
• I have heard about planned Mars trip… it would be decidedly the useful implement… particularly if you want to cooperate on projects with Europe.

The most straightforward, time-saving approach (based on my personal experiences) would be to start from scratch, possibly changing/improving/simplifying the design flow… by being so enriched by the previous experience. If you and others have problems with it now… think about what would happen in let say five years’ time. Old designs tend to lose sharpness by the universal statuary law.

       With Regards

         MichaelT

P.S.

Sir, I hope that you take this post with some pinch of witty humor to which I suppose you are predisposed. Best wishes in your design endeavors.  Merry Christmas Mr.Witsend.