Deleted Dimensions Stay as Parameters

Deleted Dimensions Stay as Parameters

will.astill
Advocate Advocate
282 Views
15 Replies
Message 1 of 16

Deleted Dimensions Stay as Parameters

will.astill
Advocate
Advocate

I found something strange today and thought I'd ask if this is desired behaviour?

I occasionally use functions in dimensions "on the fly" while in a sketch, but I think I'll avoid them like the plague after finding this.

 

Steps:

1. Create a sketch with two dimensions and make one a function of the other.

2. Delete the "source" dimension.

3. Make a new "source" dimension and then change it.

 

Result:

The original dimension stays in the model as a parameter (even if I didn't intentionally create the parameter as a user parameter), but is effectively hard-coded and invisible.

I can see why this is, but on a more complicated sketch it's possible to accidentally end up with something undesirable and not know about it.

 

Suggestion:

Should Inventor at least prompt to say that I am deleting a dimension that is consumed by other dimensions?

Should the parameter list have these highlighted in red or something to make auditing easier?

Maybe "Purge unused" in the parameters list could highlight "floating" dimensions.

 

This is a very simple example to illustrate the point.

willastill_0-1752230655625.png

 

0 Likes
283 Views
15 Replies
Replies (15)
Message 2 of 16

CCarreiras
Mentor
Mentor

I do not see anything usual in the chart .

 

You deleted the dimensions in the sketch, but not edited the functions, so the parameters are still needed and cannot be purged.

If your goal is to substitute d8 and d9 for d12 and d13, update the functions. After this, if you use the purge, d8 and d9 can be purged.

 

That's the way it must to be.

CCarreiras

EESignature

0 Likes
Message 3 of 16

will.astill
Advocate
Advocate

I don't see a problem with the need to do it from Inventor's point of view. Clearly the formula needs the source info to be retained.

 

It's the fact that there's no warning that other dimensions are relying on the one I'm deleting, and there's no indication in the dimension list that this is a "virtual dimension" value that worries me.

 

As an example, I've been working on modelling up some railway wheelsets from drawings for analysis. These have a complicated curvy web which is defined from a centreline so I needed a relatively complicated sketch to make it work. Some of the critical dimensions were defined from the centreline (not my drawings!) so I'd defined web thickness with one dimension and added dimensions to the centreline, making them thickness / 2. Over the course of a few days of dipping in and out, and various attempts to get the sketch to reflect what I wanted I'd deleted the thickness dimension and re-added it, not noticing that the thickness / 2 dimensions were now effectively hard coded with a hidden value. And yes, I used construction lines and mid-point constraints where practical, this was a place where that didn't seem to be the best option.

 

Fast forward a week or so and there are now several configs, thickness is a parameter and the model has evolved but a really critical dimension has never been updating and there's nothing to tell me that it isn't. Thankfully I did checking drawings for all the model configs but if I hadn't I'd probably never have spotted it.

 

So yes, it's a sensible implementation to solve a problem, but not having a warning or any indication at all that it's doing that doesn't seem very sensible.

 

I'd say it's similar to database integrity - one method would be to delete the source and just hardcode the values into every sub-table, but a more sensible method is to prompt the user that there are records relying on the value you are trying to delete and let them decide what to do.

0 Likes
Message 4 of 16

RajSchmidt
Advisor
Advisor

I usually rename parameters that are important to me and/or used in equations. That makes it easier to handle such situations. If I have parameters where I know that they will be used in many places I tend to create them beforehand as user parameters.

Oh, and fill in the comments. It helps the remember your design intend if you have to change something later.

Message 5 of 16

will.astill
Advocate
Advocate

Thank you. Sounds like good advice to me.

 

Do you think I'd get any traction if I added the suggestion to Inventor Ideas to have a warning when deleting dimensions that an "orphaned parameter" is created?

 

From the response to this thread it doesn't seem like anyone else is interested, even though the engineer in me thinks this is a terrible implementation approach.

0 Likes
Message 6 of 16

RajSchmidt
Advisor
Advisor

You can always try, sometimes small things get implemented quite fast.

I just wonder if such a mechanism would slow down the performance. After all, there must be checks implemented to find out if a parameter is used anywhere. And concerning warnings – most users tend to ignore them anyway (or are simply annoyed by yet another pop-up.)

Message 7 of 16

swalton
Mentor
Mentor

I create User Parameters for any critical values or calculations.  I drive the sketch dimensions or other values in the model from those user parameters.  That way, I can delete any sketch dimension, assembly constraint or similar without losing any design logic.

Steve Walton
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


Inventor 2025
Vault Professional 2025
Message 8 of 16

CCarreiras
Mentor
Mentor

I believe you overcome this with a better work method.
You have already here some good advices to avoid that problems.
I also use the process that  @RajSchmidt and @swalton  suggested, and i don't miss that option you suggested.

 

If you rename a dimension, it's because it's important in your project, and if you change your mind about that and you need to delete a renamed parameter, you will be aware that probably you will need to substitute those in some equations.

 

When a model start to grow you don't need to have:
d27= d03/d15 + d14
you will need:

Dim_A= Lenght_A/Main_Height + Offset_C

 

I understand your idea, and it's nice to have all the tools i can get to help us, but I don't believe that developers will be happy to implement that "permanent check"...

CCarreiras

EESignature

Message 9 of 16

will.astill
Advocate
Advocate

@CCarreiras - I think you are confusing my point, which isn't about the need for adding and using user parameters, or intentionally using them, it's about the behaviour of the software when creating function-driven dimensions from within the sketch environment. The only reason for including the parameters dialogue in my original screenshot was to demonstrate that the software automatically created parameters without any warning, which isn't a desirable behaviour in my view.

 

I agree that the suggestions above are useful good practice for working with parameters, but the core issue here is that the software automatically creates something unexpected without warning that can have undesirable consequences.

 

I've posted on ideas anyway as it should be something easy to implement and it's easy to select "don't prompt me about this again" if it bothers. 

https://forums.autodesk.com/t5/inventor-ideas/warning-about-orphaned-dimensions-when-deleting-dimens...

 

In the mean-time, if anyone in the future reads this and is interested in how to add a check for this into their workflow...

Open the parameters and look at the "consumed by" column.

  • Any that are blank are auto-created, "orphaned" parameters that are unused (e.g. d10 below).
  • Any that have a value, but don't give a "SketchN" reference (e.g. d12 below), are "orphaned" parameters that are consumed by another parameter.
    In my view these should have a red exclamation mark next to them, be bold, and be flashing with a little siren noise sounding as they are probably something that wasn't intended and they are as naughty as having an unconstrained sketch. I'm struggling to think of a single case where this would be intended by the user.

willastill_0-1752580125817.png

 

Message 10 of 16

will.astill
Advocate
Advocate

Out of interest, can anyone think of a scenario where someone would want this behaviour as a deliberate feature?

I'm really struggling to think of one.

0 Likes
Message 11 of 16

Mario.VanWiechen
Advocate
Advocate

No real comment on your " problem ", poor modelling techniques will always cause problems down the road.

 

my approach is to create a parameter that is called " thickness " if there is any kind of plan that I would be using it often. The parameter then also has a name not just a sequential number. May make you think harder about deleting a dimension but since it references a parameter it does not matter

Message 12 of 16

will.astill
Advocate
Advocate

Thanks for the reply @Mario.VanWiechen. I'm never a fan of "finger quotes" in messages, there is always the possibility that the reader interprets them as a hidden implication of idiocy, although I'm sure that wasn't your intention!

 

Nevertheless, I accept that this is something that will come about through poor quality modelling which I fully accept is bad practice (it certainly was a very messy model in my original case - that's why I produced the model checking prints that alerted me to the issue). I'll re-iterate though that I wasn't intending to use parameters in this one-off model, this was something I've used many times (functions in the sketch environment) and the parameters were created and orphaned automatically by the software without my knowledge.

 

It's worth noting that in a busy work environment people don't always follow best practice or can unintentionally make mistakes. Human error is a definite thing that has caused serious incidents on occasion, even in very professional environments (Arianne V 1996 for example). I'm a firm believer that if it's easy to prevent human error through a simple control then it's something that should be implemented where practical. My view here is that the implementation does something a user wouldn't reasonably expect, that could have catastrophic consequences, and that could be fixed very easily.

 

I'd still appreciate anyone explaining a use-case for the ability to create an orphaned parameter for me. I can't see how it's useful behaviour except for the software developers.

0 Likes
Message 13 of 16

swalton
Mentor
Mentor

I don't have any insight into Autodesk's design decision.  My guess is that the choice to keep the orphaned parameters was an attempt to minimize disruption/errors in the dependent calculations/parameters.  

 

As you have pointed out, one of the consequences of that design choice is that the model editor has to be cautious when using dimension or constraint parameters in equations.  

Steve Walton
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.

EESignature


Inventor 2025
Vault Professional 2025
Message 14 of 16

will.astill
Advocate
Advocate

Thanks @swalton.

 

I suspect you are right, rather than it being for a specific design workflow since no one is able to suggest one.

I'll definitely be using dimension dependency more thoughtfully in the future.

 

@johnsonshiue - it would be really interesting to me to know if this is something Autodesk consciously decided to do and if so what the reason is? Or if it's just something that came about via a chain of other decisions.

 

TLDR:

It's possible to "orphan" a dimension by using it in a formula. In a sketch dimension (let's call it d2), reference another dimension (e.g. = d1 / 2) and then delete the source dimension (d1). The software creates a stand-alone parameter containing the original value of d1 that is now only accessible via the parameters list. I'm not convinced that's safe or desirable behaviour in engineering software.

 

0 Likes
Message 15 of 16

peter.roman
Advocate
Advocate

This is what I do.
I constantly check the parameters list for parameters that are not consumed by a sketch or model feature (ie have no names like <featuretype><number> / are only consumed by other dimensions).

 

peterroman_0-1752715716173.png

 

peterroman_1-1752715733136.png

 

 

0 Likes
Message 16 of 16

johnsonshiue
Community Manager
Community Manager

Hi Will,

 

Many thanks for reporting the issue! If I recall how it works correctly, it has been behaving like this from R1. I was not involved in the decision to determine the behaviors. But I can speculate that it was for ease of implementation.

The current behavior can be understood by the following simple logic.

Parameters and sketch dimensions are two separate things. When a model dimension is created, a parameter is also created and assigned to the dimension. After that, the user tries deleting the dimension. Inventor checks if the parameter participate in other expressions (in-use). If there is no such relationship, the parameter can be deleted along with the dimension. In this case, the dimension can be deleted but the parameter has to stay in order to support the other expression. Furthermore, when the dependent dimension is also deleted, the isolated parameter will be deleted along with it. This works the same regardless of the parameter type (model, reference, or user). As long as it participates in an expression, it cannot be deleted.

 

I do agree with you that when breaking any parametric relationship seemingly or actually, Inventor should always inform users. In this particular case, we could add a warning. Some users like you will love it. But some users will hate it. We will have to provide an option to suppress it. I guess we have not focused on that yet. Please feel free to submit an idea to Inventor Ideas forum (https://forums.autodesk.com/t5/inventor-ideas/idb-p/inventor-ideas-en).

Thanks again!

 



Johnson Shiue (johnson.shiue@autodesk.com)
Software Test Engineer
0 Likes