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.
@Anonymous - thank you for providing the learning content reference. However, I watched that video, and it doesn't refer to using driven dimensions in equations, it only shows how to create them and that they update from model changes, as opposed to driving the model. I did not see anything in that lesson that implies any capability that is not in Fusion today.
I didn't realize we still need to show that this is a much needed feature, this can be done in Solidworks or inventor without blinking. I made another toy example of trying and failing to use driven dimensions in fusion.. I think even limiting driven dimensions within the same sketch would be huge.
edit: I also noticed a bug at the end when I tried to re-reference the driven dimension it keeps the old value instead of the new one..
I'm a pretty new user of Fusion 360, coming back to the CAD scene after a 10 year break due to changing professions. And I have to say that I think it's a truly great piece of software. But once in a while I try to do something that seems like an obvious thing to do, and it turns out that it's not possible in F360. This is one of those times.
I'm amazed that this "feature" has not been added after being requested years ago. It makes no sense that you can only reference driving dimensions, but not driven dimensions. Just fix this already 🙂
I want to pattern something using a driven dimension as the pattern distance. The driven dimension is pretty complex, it's not practical to calculate it myself. I understand that referencing driven dimensions can sometimes create circular loops, but if there would be no circular loop in this case is there any know workaround to this issue?
I'm back after reading this whole thread from start to finish. I have a naive question.
Is it relatively easy to add a tool which makes a measurement (like Inpsect->Measure) and turns the result into a referenceable parameter, but the measurement also becomes an event in the timeline? If you want to reference the new parameter you could only do it after this measurement event in the timeline, so you can sidestep the circular dependency / iterative solution problem. However, I have no idea how hard it would be to engineer parameters which are only available after an event in the timeline.
It's possible that limited functionality like this example could relieve much of the tension the community is experiencing, and not take the resources of a large refactor of the constraint solver. Curious to hear your thoughts.
@gregmainland - If you really read through 13 pages of comments, that is an investment worthy of a response.
What you describe is essentially what the solution to this requirement entails. A driven dimension is kind of like a persistent measure, it is just encapsulated into a sketch. The complexity here is not really conceptual. The theory is pretty simple, and as has been pointed out here, has been done in Inventor years ago. The problem is only one of implementation. We made a simplifying assumption early on (turned out to be a bad one, I guess, but Fusion was aimed at a different customer then...) that this was not needed. So, the parameter system was built assuming that all parameters could be computed at the very beginning of the compute process. Unfortunately, that assumption has become baked into the product over time. The difficulty is not really in preventing circular dependencies - any solution here would prevent that up front, so we also don't have to deal with iterative solutions. The problem is really summed up in your description here: "I have no idea how hard it would be to engineer parameters which are only available after an event in the timeline". Today, we can assume that all parameters are always available any time. We'd have to introduce the idea that some parameters are not available depending on where you are in the timeline. None of this is rocket science, it is just work.
We do get how important this is. It is a high priority for us. I hope, as much as you all do, that we get to it soon. It would make me happy to cap this thread at 13 pages of comments by saying "done"...
We appreciate the seriousness of the comments here. It's nice to be able to have a civil discussion with actual users of the product on topics like this.
