Parameter uniqueness per component not design

[GeorgeWilliams]

Include an option or refactor the existing parameter naming to be unique per component not per design. 

Inserting components that are then set to unreferenced (i.e. break link) should not have its parameter names auto-changed to be globally unique if a parameter of the same name exists anywhere else in the design.  Duplicated user parameters could be avoided by prefixing or postfixing the component name with an unused character (e.g. "FooComp:BarParam", "BarParam@FooComp", etc). 

At a minimum...

• For users, some dialog should be displayed listing those parameters that should be renamed.
• For programmers, an API should be included to handle the event thrown before the auto-naming action to give the programmer the ability to rename the parameter to something more usable.  Frankly, if we had this event then it would be trivial to create an auto-naming add-in to implement a naming scheme like that shown above - e.g. "FooComp$BarParam" could currently be created via a "Before_Occurrences_addByInsert" event since the "$" is an allowed character in a parameter name.

The current process of Fusion automatically appending a numeric index (e.g. "_1") to duplicated parameter names results in a confusing set of parameters that quickly become meaningless and impractical to reference in assemblies with a significant number of parameterized components.

The current parameter UI is an improvement over the Inventor parameter UI in that all the parameters for all components (assuming they are not referenced comps) are grouped per component.  That organization is helpful.  However, the lack of being able to use the component name to reference parameters limits the complexity that can be effectively managed with Fusion.  A list of "Width", "Width_1", Width_2", ...  "Width_N" parameter names quickly becomes difficult to manage and comprehend... especially when you are trying to communicate design intent to others in your team...

[promm]

Thank you for your idea, this is getting changed to future consideration.  From your request it sounds like you are looking for a way to control parameters in a way similar to configurations.  You are referencing how we change the naming, however there is a bigger picture that we are looking to address sometime in the future. When we explore how we are going to solve this problem, we will evaluate this design.

Regards,

Mike Prom

[GeorgeWilliams]

Thanks Mike!

You busted me!  We definitely see this as having value for configurations.  We are currently working on a configurator for Fusion 360.  🙂

We do also see this as a general usability improvement to help all users more easily manage parameters.

In regards to your "bigger picture... in the future" comment, I assume that is in regards to configurations.  If so, we'd love to offer ideas and perspectives to you all on that.  We many years of experience in automating Inventor (with multiple technologies - .NET, iLogic, ETO) for small, medium, and large projects.  🙂

[promm]

George,

I will reach out when the time comes to work on this project.

Cheers,

Mike Prom

[thburn]

Please consider also to group and sort parameters.

Currently if you add a parameter it just adds at the end, but sometimes I want to move it up/down the list to keep parameters close together if they belong together.

A grouping would also be nice to keep the parameter window clean.

Thanks...

[ikcalb]

Any progress on this one?

(Goes hand in hand with parts families, which would really be worth implementing too)
see my comment in:
https://forums.autodesk.com/t5/fusion-360-ideastation-request-a/accessible-unser-parameters-for-link...

[ikcalb]

Any progress on this one?

(Goes hand in hand with parts families, which would really be worth implementing too)
see my comment in:
https://forums.autodesk.com/t5/fusion-360-ideastation-request-a/accessible-unser-parameters-for-link...

[julian.tilbury]

Fusion really needs this.

I'm a software engineer having to do physical design for a prototype scientific instrument.

Because its a prototype, mostly made from off-the-shelf pieces, the bits I design, like cases

and mounts, can change because we need to test a different solution, or because we need

to change component because of discontinued parts, availability or price.  The whole design

needs to be fluid.

As a software engineer familiar with object oriented design this physical design is a textbook

case of the paradigm. For instance if I have a widget mounted in a box, which is inside a case

I might have:-

On activateing the widget, I would like to have parameters:-

Height = 20

Width = 10

On activating the box, I would like its height & width to just be:-

Height = 30

Width = 15

but I might also want to make sure it enclosed the widget so I should be able to refer to

them:-

Height = Widget::Height  + 10

Width =  Widget::Width + 5

I might have to refer to a global parameter in the Widget

MyParam = Case::Depth

Or from one widget to another:-

Param = Case::Box::Widget::Param

There are many object oriented programming languages to give inspiration

for a design that would give Fusion parameters more modularity & expressive

power.

At the moment, I'm trying to use a global parameter file with names like:-

Case_Box_Widget_Height

and use the ParameterIO plugin to share it.  I expect all software engineers who

read that will groan - there should be a better solution.

Given ParameterIO is a Python hack, I'm tempted to write a better version, but

I have a deadline for another version of our prototype ...

[david.lantier]

 My 2 cents ...

First, I would like to design a component in a project, with its parameters, a reuse it in another projects, then use the inserted component parameters. Yes, this will do a chain of dependents, and broke the final project if a component is removed. A change on initial(s) components could affect any dependent project - according they are or not using the initial component parameters. An object notation (instance-name "." property-name, ie. component.param) seem to be the best solution.

Second, it would be great if we were able to declare some conditions (ternary or better, simply "if ... else") to manage values that cannot be managed by a "simple" equation. And if theses tests could result in messages (an alert after a change when limits reached, for example), this would be very fine! 

Another way could be to rely on an excel sheet that could be a base linking some dependent projects together. May be more simple to handle for users. I think this could be developed, and I think I can do it (but not sure, I'm experienced programmer but not with fusion), but I do not want to spend time and finally discover a better solution! So, wait and see, or try to make a solution?

Thanks for comments, and Fusion360 is a really great project and product!

[kaN3PRT]

There really should be some progress on this.

You can already save a copy of a component as a separate entity.

Next step is to allow a component to have replaceable parameters with defaults so you can, upon import (reference) of it be asked if you want the inserted component to be supplied parameters from the referring design, or keep it's own/defaults.

When we are into it, the opposite should also be possible. After inserting a component "abc" it should be possible to create something else with abc::width as well, reusing it's parameter.

[GeorgeWilliams]

Calling all "likers"...  I've been receiving a number of emails from folks who have "liked" this idea.  If you like it, please vote for it so it can get this idea moving!

Also, to "Autodeskers" monitoring this thread/idea - any status for us on this or alternative implementations that we can use to achieve the same result?

[dchavir]

I'd like to take it a little farther, and treat all components as instances of a class similar to your favorite object oriented programming model.  If a component instance had variables (properties?), they could be marked as public/private/read-only/read-write and referenced accordingly by other components in an assembly for example.  One could even envision components having methods, so instead of just getting dimensions of a component to calculate a position or whatnot you would just ask the component how it sizes itself or where it wants to be located given a couple of parameters.  You could build some robust components where each instance could be customized via setter methods to make sure the requests or given values were suitable.  I think an assembly of intelligent components (programming with representations of physical objects?) would be wicked cool...

[ekbiker]

I would love this feature as well.

[peterA6TP8]

This "feature" request has been here for quite a while..  But it seems there is a even more basic feature that needs to be tackled first.

I think Inventor or another parametric program are better suited for taking advantage of parametric parts to make large configurable assemblies. Once you have a 2k or 10k part assembly of a machine it's very nice to re-use all that work. But parametric assemblies are complicated and not necessary for most design jobs.

Fusion 360 also differs from Inventor in that your data is available at any computer that can run Fusion 360, which is most. You get T-spline shape tools. The design workflow is much faster because it is a 'direct' modeling tool. You can also run Fusion 360 on a Mac. You can work collaboratively on your designs with anyone you invite to the design.

Fusion 360 does not have parameters like Inventor. [EDIT: in 2013 when this response was first posted Fusion did not have parameters, but it does now - Fusion 360 has full Parameters, as well as Direct Modeling - PE] However, in Fusion 360 sketches there are constraints and dimensions to provide exact mechanical details. Assembly tools such as Joints and Motion Study provide analysis of your machine designs. 

Phil Eichmiller , Software QA Engineer, Fusion Quality Assurance Team , Autodesk, Inc. 12-04-2013

The biggest help would be an ability to share parameters across many designs.

DimaGorbenko

2019-02-13

My recommendation would be to check out Autodesk Inventor and start over.

TheCADWhisperer

2019-02-14

I realize that all the issues with shared parameters is a bottom-most root level basement feature, and by above, was not implemented on line 1 of code.  Especially since Inventor the product's "parent" did it right, and is being recommended as a solution. This feature is probably not easy to retrofit to an existing product..

Yet it sounds like from "But parametric assemblies are complicated and not necessary for most design jobs." that a decision/mind-set has been made that full blown parametric sharing is not needed. I wonder if this is case everything being a nail, because the only tool you have is a hammer..

There's this: Driving design through separate files - but it sound's like a workable retro-fit, not a base level feature. The description of the feature is pretty much "to be done done by the student".

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-E2C8260C-25FC-4505-88F8-95D03E1AA78A

I'm a software architect by profession, and the ability to share information across different systems/designs is always a major design decision -- it's either a killer advantage, or a unforgiving flaw. Looks like a 20 year old product Inventor did it right, but that knowlage/skill, at least of this one feature, did not make it's way to Fusion.

Hey -- anybody want to bet that Inventor was written in C/C++, while Fusion is in Python?   C requires programmers to think about the format/layout of their data, while Python has a more relaxed (as in almost non-existent) attitude. 

It's about time this get promoted to the basic feature that it needs to be, or at least document the heck out of how the hack above might work (and update all the old mail chains).

[peterA6TP8]

OK, the 'derived' feature mentioned in above kind of works -- but you have to work for it

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-E2C8260C-25FC-4505-88F8-95D03E1AA78A

Supports both "derive" and "import" actions -- At least with what I know now, the "derive" action fits my idea of having a common set of base shared parameters.  Following is what works for me at this time. 

Caveats:

1. Parameter names get appended with "_ref"
2. You CAN chain from Base -> Derivied1 -> Derived2, but need a "_ref" suffix gets added for each level
3. Auto-completion of names doesn't work for these guy -- unless you manually put the parameter into the "favorites"  list of the derived design  (click on the star in ChangeParameters window to turn it yellow) 
4. Need to 'save' the design that contains the 'source' data, before you can read it into the 2nd
5. You get a little flag if parameters are changed (upper left window before 1st design tab), but you must manually "pull" them into the design

Think first -- I suggest you create a really large project with a few dozen inter-dependent parts, and then realize that it has become too complicated to continue. Then

1. Create a Single Base Design -- (yea, object oriented programming term) -- and call it something like BaseParameters
2. Have fun, drawing something like the letters "BaseParams" that you can see in the design - make it clear and visible - this is what you will see in the Detail Panel.
3. Go into Modify:ChangeParameters spread-sheet-ish page and start adding your parameters. Establish a consistent naming rule BEFORE you create the first parameter.
4. Make liberal use of the Parameter Comment field..   Your co-workers will like you better...
5. Empirical evidence suggests that only "Favorite" items get promoted to the derived drawings.  - so get in habit of click on that Star to turn it yellow 
6. Save your design
7. From this BaseParameters design, use Solid:Derive, A) "Create New Design", or B) "Add to existing design". Note I prefer not to select any objects (also a feature) to pass to new/existing design when I do this -- it's all about the Parameters.
8. In your New/Existing design, bring up the Modify:ChangeParameters page, Dig down to BaseParameters v1 (derived) and see the copied parameters
9. Remember -- auto word completion will not work in derived, unless you move them into Favorites area. So again, consider making all the stars yellow...

For updating parameters -- start from the Base

1. Modify/Tweak/Add parameters in your BaseParameters design -- and then Save it
2. In all the other derived designs, you will see little chain/yellow ! triangle on upper left. Click on it to pull in updated parameters.
3. Unfortunately, ANY change to your BaseParameters design, even if you didn't modify any parameters, will cause you to need to refresh all the derivied designs. (the chain/yellow ! triangle) will come up -- good reason why NOT to have anything but global parameters in here
4. If you chain the Derivation of the designs -- Base --> Derived1 --> Derived2, then you MUST "Get All Latest" in Derived1, Save it, then do it again in Derived2
5. You CAN have multiple BaseParameter sources (from different base designs) in any of your Derived Design... But think real carefully about your naming schemes before doing so. Finally back to what this initial article is all about. Don't be any more complicated than you need

One very helpful tool is to be able to import/export all the parameters in a design to a CSV (comma separated value) file. This doesn't have the automatically of the little chain/yellow ! triangle in the upper left, but it allows you to see the NAMEs/values of all the parameters. See https://apps.autodesk.com/FUSION/en/Detail/Index?id=1801418194626000805&os=Mac&appLang=en

Might be an interesting way to create your initial values in a easier/more collaborative environment. Google Sheets for example... 

So that's my workflow -- still trying it out.

Seems like a workable solution -- but I'm not going to call it a good solution.. Too many manual steps. In a large system, refreshing all the designs after one change in going to be ...

It would be nice if the fine folks at AutoDesk would offer their tried and true suggestions here, then get onto actually bring this up to the level that most of the rest of their Fusion 360 product is (That's a compliment)

[peterA6TP8]

Fusion it’s like eating really excellent chocolate covered juicy strawberries that has a few pieces of gravel mixed in with it.

And as to the Plate of ParameterIO plugin,  which I recommended above, the gravel that will chip your teeth is...

I created a simple drawing of a can with the following parameters, which I then exported via Parameter IO

    dia,mm,10 mm,
    wall,mm,2 mm,
    outerdia,mm,dia + ( wall * 2 )

Then I sorted it, (my orginal list had over 1000 params in it), and added a duplicate field.

    dia,mm,10 mm,
    outerdia,mm,dia + ( wall * 2 ),
    wall,mm,2 mm,

    wall,mm,2 mm,

When importing, I got an Exception:

    Addin Stop Failed,
    on ParameterIO.bundle/Contents/ParameterIO.py, line 234 in readTheParameters.
    RuntimeError: 3 : Invalid Expression

The Parameter Import code is making 4 novice level programming mistakes

1. Import Code doesn’t handle missing or forward references (wall used by outerdia)
2. Duplicate variables (wall twice)
3. Beside the exception, you don’t print out the line/text of where the error is in the input file
4. Fails on first error... Doesn't continue to pull in the rest of them and show list of failures when finished.

If you look at the ParameterIO plugin page, you will see that these problems have been reported (at least the exceptions) for a couple of years now. It doesn't look like anyone has really caught the fact that they seem to all be related to forward, undefined or duplicate references

The 'derived' solution that I presented above is still better for sharing parameters between designs, but you need to start with some initial values. If your pulling them from another design or outside source, you are going to run into this. Fusion's Parameter Editor isn't very robust, so doing this outside makes sense. But if you do want to import parameters, to this:

1. Keep to using simple numbers (non-calculated values) as much as possible.
2. Put all your calculated values at the bottom of the spreadsheet/file.
3. Highly recommend all parameters in file being self-consistent - not depending upon values defined outside of the file. You can of course, but it will be real hard to debug it. 
4. Import your new CSV file into a blank never-before used "Untitled" drawing to check for syntax errors.
5. If you get an exception on import, go to the Change Parameter Editor, and find the last line -- the error will be in the next line in your source csv file
6. I'm sure some sort of script could easily be created to validate the data before importing it.

This kind of explains why the Change Parameter Editor is not sortable by parameter name or value.  This is a major missing feature (can you say design error?) in my opinion, but totally explainable if they don't support forward references...   Gives you some insight into how much the original designers considered Parameters to be within Fusion..

The reason we are on this thread is that we are looking for solutions to better handle parameters with Fusion. The workarounds are... well.... workarounds

[jonK64AF]

I am having the same difficulty so thanks for saving me the time to search for a non exixtant solution.

It would be great to be able to sort the parameter list by any field and be able to include a full name with all the keyboard characters.