Can't drive a dimension with valid formula, but can drive that dimension with param assigned same formula

[dannym9999]

I am trying to enter a belt path that will auto-adjust the distance between D1 and D3 to tighten the belt

D1,D2,D3,belt length are defined params

The relationship between D2 and D3 has been fixed here to make the problem even simpler, yet Fusion still fails

The engagement angles are driven dimensions

I try to assign the length of the segment as 1/2 the belt length - the three engagement arcs

This results in "fail to calculate".  This is possible and would not be a circular dependency.  When the section length changes it will adjust arc angle d29 of and d12 but there is still only one solution

Just experimenting, we make a standalone line up top with the same equation.  This also fails to calc, even though the calculated length of the line will not adjust arc d29 or d12 so that was not the problem

Here's the strange part- I created a param "beltseg1" with the EXACT SAME formula I am trying to use directly.  THAT will assign to the standalone segment second from the top. 

Then I went back to the diagram and found I CAN drive this segment length with the param.  In this scenario, as the segment length does change driven engagement angles d12 and d29 which does the complex calc I needed.  But why does the eq not work directly but will work when entered indirectly as a param?

IMHO referencing driven dimensions in a param list is weak design practice.  When multiple sketches are involved, it is unclear what driven dimensions would be available to use on the param definitions table without creating a circular dependency.  Or from the sketch's perspective it will not be clear what params can be used without creating a circular reference because the param table may have driven dimensions which are created in subsequent sketches

[davebYYPCU]

Without going into the Parameter against direct entry, for the moment.

I take it that you want the parameter to calculate the straight line length, which then adjusts tangent angles.

If so, why is D10 not a permanent 140 degrees?  What is D13 doing?

File arrived with parameter D3 set to 12mm but sketch has D3 as D2.  (D3 = 13mm is being used in the formula?)

Set D14 to Driving, Set B14 to Beltseg1, and let me know if that sorts it out.

What I can't resolve is how the formula calcs a line length and a dimensioned same value line are not the same.

May be something in the file history. @Phil.E can you check this one please.  Weird.

Edit:  With more work, the sketch can be drawn, the arc lengths can be calculated, dimensioning the segment causes the arc lengths to recalculate, quicker than we can keep up, there's a circular dependency without error warnings.

Might help...

[Phil.E]

Thanks for doing the work on this one. Which is the correct value? 62 or 46 mm?

Logged as FUS-172988.

[davebYYPCU]

62 ish, the 3 arc lengths add up to about 63, and total chain length has to be 125.

I keep seeing the tangent angles adjusting.

Might help…..

[dannym9999]

I've not fixed the engagement angles, pulley spacing, or idler locations yet, by choice.  The pulley tooth counts, idler dia, and belt length are up for adjustment.  

The design process is to enter in pulley tooth counts, belt length, and idler dia and see what geometry works.  One pulley is coincident with origin, the other is fixed on a horizontal line.  At that point you can grab the idler and rotate it around the smaller pulley and watch the smaller pulley and idler move along valid solutions.

This does work fine now, but only when the formula for the length of the middle belt is on the param table and the param is assigned to the run.  I can't assign the same formula directly on the sketch, it returns a failure to calc upon pressing enter.  Which is weird

[davebYYPCU]

Umm, that helps, with the what you want, 

how to get manageable parameters, with 4 dependent variables, is above my paygrade.

Arc Length plus Beltseg, plus two more arc lengths, = 125mm.

I had the 125.04 chain length, from these parameters.  (Check parameter list for angles not rounded up)

Nominating the arc angles at each end.

I have found in the past, tooth count * pitch = belt length, 

where pulleys are polygons, with pitch equaling the polygon side length.  Would totally change this diagram.

Might help...

[dannym9999]

A pulley doesn't need to be modeled as a polygon.  The total circumference is gt2pitch*toothCount, and diameter is circumference divided by PI.  When you draw a circle in Fusion, the diameter or radius is something you can dimension, but you can't dimension a circle by circumference AFAIK.   So the param table has D1 (diameter of pulley 1) = num_dbn_teeth*gt2pitch/PI, we draw a circle and define its diameter as D1.  The full circumference is D1/PI.

So the belt is properly tensioned when beltLength/2=the three arc lenths plus this straight run.  It's not fully constrained at that point, the idler circumference touches the 

The actual length of the belt wrapped on this pulley's half above the symmetry line is the fraction thereof.  The arc is a driven dimension Fusion sequentially assigns upon creation, in this case d12.  That's not displayed in a screenshot but if you hover the mouse pointer over the (110.7deg) it will tell you that and it's referenceable.   

So the belt length wrapping the first pulley is (d12/360deg)*D1*PI.  Repeat for the arcs on the other two.  That's a symmetry line, I intend to put another idler mirrored on the other side so we only need to solve for this half, beltLength/2.

The sketch isn't  fully constrained at that point, the idler is constrained to contact the smaller pulley on the back of the belt but the angular relationship isn't constrained.  Moving the idler will consequently move the smaller pulley in and out to keep the belt length constraint satisfied- and note that any change there will also change the engagement arcs but it will still solve all of it dynamically.  Or, alternately, you can grab the smaller motor pulley and move it in and out and Fusion will relocate the angular position of the idler to satisfy the belt length formula.  If you try to grab the small pulley and move it too far out (or in) manually, Fusion won't let it move that far.  That's because in the overall design process the exact motor placement may get tweaked by another relationship.  Or I may change belt length, either pulley tooth count, or idler dia.  Fusion will be able to adapt entirely automatically, so I see this as the best possible design practice

That's why the 3 engagement arcs should remain *driven* dimensions as shown.  Defining them with a constant would lock it and it can't adapt anymore.  Well, you can work from a fixed engagement angle criteria too,  but only on one pulley.  At that point the sketch is fully defined and the smaller pulley location as well as the other 2 driven engagement angles are locked

[dannym9999]

oh snap, it DOESN'T work.  Fusion bugged out and miscalculates the geometry, and says this is ok when it clearly is not ok!  A line cannot be 70 AND 170 at the same time!

It looks like the solver can't figure out how to calc for the free length at all.  It's possible to figure out but very difficult.  It wouldn't let me enter the formula on the sketch as a dimension because at that point it saw it wasn't powerful enough to figure out.

When the formula is placed in the param list using driven dimensions from a sketch, it can't see that it can't calc it.  It should go red on the sketch if it can't.  Nope, it did the worst thing- it tells you it's solved when it isn't, and the design is invalid yet appears good to go for mfg. 

 

[davebYYPCU]

Did you review my file?

Easy to calc the straight line, and doesn’t break.

If you change one value at a time, all is good.

(I think too many driven dimensions, cause a circular dependency)

To have 4 variables and mostly all blue sketch, nightmare waiting to happen.

Might help….

[dannym9999]

I see your pic where you try to fix the engagement angles- this probably gives a solution but it's of no real use for the problem at hand, where those angles will be variable

The file you enclosed is for a hutch.  Nice but I don't see anything in it that was relevant

The best I could do is change the free length to a driven dimension and make a construction line float above the sketch elements that adds up the 3 driven arcs and that length, and let it show the final sum there.  Then I can drag the pulley out until that sum is equal to 1/2 the belt length, or close enough to it. 

It's messy, it's not automatic, but will give an answer.

[davebYYPCU]

Oops, fixed.

Will be a few hours before I can send the demo.

Not sure why it would not work, those 3 arc lengths are so close to 62/63.

Changing pulley size, or any single change for a stable result, any driven dimensions will be ok, but referencing 3 in one formula is asking too much.

Might help….

[Phil.E]

Thanks @davebYYPCU for working on this post. I noticed something about Fusion here.

Measure and Default Measure do not provide a loop length. If I'm wrong, which is possible, I can't find it.

Both of these commands could easily show the selected loop length in this image. Do you agree this would be helpful? (logged improvement FUS-173101)

[davebYYPCU]

Loop length is available / displayed in the live lower right working window.

Selected, displayed.  

Now having the extraction of the value to Clipboard by the Measure Tool will be appreciated by many.

Might help….

[Phil.E]

Now I see it. The improvement is now a bug report, citing inconsistency of results. It shouldn't matter how many connected curves there are.

The measure dialog has a tool to copy to clipboard by clicking the value.

[davebYYPCU]

Aware of that, in my workflow don’t think I have tried to select a chain.

My testing seems to be - weird results from multiple driven dimensions in a formula.

Fusion seems to make two lines either identical length, with different dimension values, or visa versa.

Might help…

[dannym9999]

well it sounds like the logical next step would be that fusion's Dimension feature can select a loop length to either drive or be driven.  then it has a referenceable dxxx label and the existing features do everything from there

a loop length should be applicable not only to arcs but splines etc.  that may actually may some awkward special case code obsolete.  like getting a point on path down a spline would just be a regular point with a loop type constraint fixing it at either a fixed distance or as a fraction of the dimension placed on the entire loop length

the more i think about it, the more it opens up

[Phil.E]

I just noticed the inconsistency in Measure when trying to see how to measure the results of formulas like these. It's not central to the story, sorry for adding noise to the conversation here.

@dannym9999 I was not talking about measure with your idea in mind. Measure is not parametric, and it is not connected to parameters at all. It is merely a reporting mechanism. What you want would be years of work, and so far, not on the sketch or parameters roadmap. Great idea, but far from the Fusion we have today.