Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Submitted byAnonymouson10-18-201508:52 PM
Status:
Gathering Support
Ability to reference Driven Dimensions
I have a driven dimension in a sketch, which I would like to be able to use in a calculation for another parameter, but there is no way to reference this. It does not show up in any way under the "Change Parameters" dialog or have any named reference that I can see.
I need to test but I was working on something last night, and while editing a dim, I clicked on another dim, and it popped something like d28 into the box. I didn't look into it but will soon and report back - could it be that the feature is there?
wilsonbrett85: I need to test but I was working on something last night, and while editing a dim, I clicked on another dim, and it popped something like d28 into the box. I didn't look into it but will soon and report back - could it be that the feature is there?
I believe the current behavior is unchanged with respect to the start of this discussion: you have always been able to reference/reuse dimensions for which you've entered a scalar value or formula. However, driven dimensions still don't "exist" within the Parameters space. They have no names, and they're inaccessible from formulas.
This thread is specifically about gaining the ability to reference driven dimensions from other formulas.
In a model sketch, when you are creating a new dimension:
When you select a Driving dimension |<-- 25 -->|, the dimension Name, such as d28, will appear in the edit box.
When you select a Driven dimension |<-- (25) -->|, which is enclosed in parentheses, the value of the dimension is returned, not its Name. If the Driven dimension changes, there is no association or reference, so your last dimension is unchanged.
The request on this thread is the ability to get to the Name of the Driven dimension, not just its value. This will maintain an association.
"I guess the "difficulty" lies in the difficulty to get into a situation where you actually solve a system of equations iteratively, i.e. when the parameter that is composed of driven dimensions modifies the driven dimensions in turn?
But that could be circumvented rather straightforwardly, I'd think, by detecting if the change of the parameter led to the driven dimension being different (sensitivity?) and if so, the system will flag the relationship as currently not solveable and forbid the relationship?
My problem doesn't create such loops but doing the maths for two driven dimensions is horror compared to the simplicity of just comparing two in a Min/Max function and using that in a parameter. My model is highly complex, parameterized and constrained so I can scale different dimensions and angles at will and still get something meaningful out as total design (i love Fusion 360 for this but am surprised to see this one feature doesn't exist).
I would think only if you try to solve the iterative solving of equations at the same time does this get difficult at all.
Thoughts?
Cheers - Marc "
Do people here think that this would be an acceptable first-implementation limitation?
I think the real problem, is simply autodesk did not build this into the requirements early on. Now after two years plus - it has still not registered with the autodesk management that this is a real engineering necessity and not just a nice have addition - and all resources seem to go to pretty visual or funky and interesting things rather than the core engineering
Agreed there. It’s right up there with symmetry and patterning in terms of unfulfilled requirements that are probably now highly nontrivial to implement because people weren’t thinking about them early on
Sure, any incremental improvement would be helpful. But I suspect that the “easy“ stopgap solution isn’t really all that simple, either.
The problem is that you can’t necessarily determine whether the relationships are circular at the point the driven dimention is first referenced. Well, you can, but there’s no guarantee that circularity won’t later be introduced by sketch constraints or any number of other operations. It becomes a Ui issue: all constraining and dimensioning relationships become potentially failable because of an existing reference to a driven dimension. There has to be some way for the user to understand why operations are failing apparently at random, and it’s likely to make the whole app seem balky and unreliable.
@scottmoyse, it's not that it is harder in Fusion than it was in Inventor - it was hard there, too. But, Inventor is almost 20 years old, so they've had time to tackle these hard problems. I can't remember for certain which Inventor release first supported this, but it was several years after the initial release. Like so many other things, it's just a question of priority. We have limited resources, so we can't address all of these "I can't believe this is still not implemented" tasks at once. This one just hasn't bubbled up to the top of the list yet.
And yes, @GRSnyder, it may be that cycle detection is harder than I think, but we do these kinds of checks in other places in Fusion, so I'm more hopeful about this one.
Thanks, everyone, for the valuable input. I agree that this is an important capability.
Hi @jeff_strater, as there is valid concern about the easy detectability or difficulty of late handling of detection of circularity by @GRSnyder you can make it simple by making matters explicit. Allow for two kinds of sketches:
measurement providers: these sketches cannotuse measurements in parameters
measurement receivers: these sketches can use measurements, but only from sketches that are measurement providers
With measurements I mean driven dimensions of course.
This scheme enforces non-circularity but leaves it up to the designer to split up the two kinds and have multiple sketches of these kinds.
In my case I would do a pure construction sketch as measurement provider and then use the measurements I need in other sketches that are measurement receivers.
Would this work/resonate better?
Cheers - Marc (oops, better go to bed now...3h45am!)
(( Having said that: Another concern I have is that my complex design works fine if I don't fiddle too much with angles or thicknesses or lengths. But if I do too much I can never recover my design by putting better/previous numbers back in again as the constraints then no longer work the way I had planned them (a tangent might snap the other way etc.). The only resolution is then to press undo sufficiently often or to recover a previous version of the model. My feeling is it might make sense to introduce ranges for parameters (range constraints?) and the system doesn't accept then certain parameters that would lie outside the ranges where I know it is unrealistic in effect and destroying my model if I'm not careful. So the ranges would add more meaning and a protection for sketches with tons of constraints... But as the recovery is possible via versioning I guess this might just as well be perceived as a mere overcomplication of the model...? Maybe that is the case. ))
Interesting idea, @Anonymous! If I understand your thrust correctly, the idea is to define the “mechanics” of referencing in such a way that circularity can’t possibly occur.
I like the general concept, but the constraints you hypothesize seem perhaps incomplete. It seems like you’d also need to prevent, e.g., projection of geometry from receiving sketches into providing sketches; otherwise, you could easily create loops. More generally, it’s not just sketches that have to be classified. You wouldn’t want to allow the calculation of the intersection of a solid derived from a receiving sketch with the plane of a providing sketch, for example. It seems like these rules could ramify and become quite complex in some cases.
Your outline also gestures toward something that I think might be more generally helpful for Fusion users, namely, a way to more clearly indicate the flow of data and constraints in a design. In the current system, everything’s pretty much just together in one big hot tub – boil it up and see what design comes out the other end! 🙂 Maybe a more general version of your provider and receiver system would be just to have numeric layers. You could refer to the dimensions of anything on a lower layer than yourself, but could not see dimensions above you. A reviewer unfamiliar with the design would know to look at sketches in layer order to understand the structure of the design.
Currently, the timeline kind of serves this function. Maybe limitations on referencing could be based on relative position in time.
(sorry if appearing twice, the edit-message function seems play up here)
Hi, yes and thanks @GRSnyder, the timeline is actually something I don't like as concept at all. It feels like destroying or endangering some later work when going "back to edit a sketch". Eerie to me so at the moment I defer fooling around in 3D before my sketch is really really watertight.
In fact projection currently only seems to work from a previous to a later (or upper to lower in the sketch-list on left) sketch or such I found: it caused me to move the sketch order around under sketches, which felt awkward without having been introduced to such a concept (but then, I only touch Fusion 360 since a few days accumulated work time; all except the (well-hidden) math formulas I can use in parameters I have from the very introductory videos...I have no CAD experience, really...an IT guy). So projection seems somewhat layer-oriented already today (you can check the light bulb for and see an upper sketch when editing a lower one, but not the other way round). Maybe this leads somewhere, @jeff_strater?
More explicit relationships, not just time-ordering relationships as you say sound like a great approach! Maybe this up/down ordering is already implicitly going in that layering direction.
Another consideration: The by-sketch parameters are clearly bound to sketches. But the user-defined parameters are not...I sense that it may be necessary to associate certain user-parameters as non-global and associated with a specific sketch? Just a gut feeling right now.
This is crippling for quick sketch creation / alignments, especially with things like arcs where you are using a point on the arc to align with an edge, then getting a drive dimension to the center of the arc that you want to use for calcs for other dimensions. Please implement this ASAP
Hi @matthewsclark, funny - 3 weeks no movement and I was coincidentally looking into this earlier today as well.
Just to collect another data point: would your scenario still be fine if there was a limitiation as outlined in the above 3 posts? I.e. would you be fine with a scenario where
your driven dimension X can be used in a parameter Y
but your parameter Y is NOT able to affect the driven dimension X in turn?
I.e. you're not looking to have the system solve a non-linear equation iteratively for you?
your driven dimension X can be used in a parameter Y
but your parameter Y is NOT able to affect the driven dimension X in turn?
Nothing too complex that I am doing, just being able to apply simple formulas using a driven dimension would be nice. So far I've been able to get around it by drawing extra sketch lines and getting creative with constraints to graphically accomplish it but it would be faster and easier to just do some quick math in the dimensions using driven inputs in the formulas. Does it sound like I am understanding you correctly?
