2018 Link sheet metal issue

jletcher · ‎04-03-2018

Something to look at.

when you derive a sheet metal and use the "Link Sheet Metal Styles" it does not change the Material type.

It should be MS

jtylerbc · ‎04-05-2018

The derived part does not have any bodies in it.

It behaves the same whether there are bodies or not, or even if it is a standalone part (as shown in my first set of sample files). How it was modeled doesn't matter, only the material settings.

@jletcher wrote:

And that is just the 20ga I still have what 30 to 50 more thicknesses to go can you imagine the list and that is what @jtylerbc don't understand.

I do understand that, and already addressed it, but I'll say it again. With the way the tool currently works, and your large number of material and thickness combinations, setting the material by the Sheet Metal Rule may not be the best method. It may be more efficient for you to use Sheet Metal Rules that don't control the material, and just manage the material in the part itself.

Just a thought here - I know you hate anything that looks like a "workaround", but it seems like it would be possible to resolve the conflict with some iLogic. It might be possible to look at the active Sheet Metal Rule, and make material decisions programmatically based on that. This could probably use some refinement, but I'm initially thinking of something like:

Set material in template file to "By Sheet Metal Rule."
Create Sheet Metal Rules (may be what you already have) that define a material only in cases where it is different from your most common one.
Use If/Then/Else logic to see if one of the "special material" SM Rules is active. If it is, do nothing - the SM Rule material stays in control. If not, change the part material to your common material.

I think that could get you the functionality you're looking for, using tools as they currently exist. It gets the template material setting (which causes your whole problem) out of the equation, but still lets you effectively have a default common material so you don't need create thousands of Sheet Metal Rules.

johnsonshiue · ‎04-05-2018

Hi Brian,

Many thanks for the explanation! I missed the part that the material style was overridden in the source file. I thought it was overridden in the derive part before derive happened. Indeed, the behavior is sort of as designed. I think the main confusion here is that Sheet Metal Defaults dialog does not convey the idea that the material (supposed to be dictated by Sheet Metal Rule) has been overridden manually. It would have been nicer if there is some sort of hint in the dialog showing that. Also, it would be great if the material style in the default Sheet Metal Rule is pushed to the derive part.

This is a design choice. Either way has a point. I will work with the project team and see how we can improve this workflow further.

Thanks again!

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

jletcher · ‎04-05-2018

I think you all have lost my point I give up.

MechMachineMan · ‎04-05-2018

The point that you don't have a good feel for the way Inventor works?

Inventor (from almost everything I have encountered in it through actually digging into the UI and API, as well as Autodesk's documentation and blogs by other experts on the software) is set up to have a "proper" way of doing things, which utilizes styles and default values. BUT because end users always want something different than designed, they have put in "overrides" for most of the settings, so that end users can get the final result they want. The catch is that these "overrides" aren't embedded within the system as deeply as the default (as designed & intended usage) so there is not nearly the functionality with them.

Examples:

- Drawing styles ("default") + local styles ("override behavior")

- Document BOM Structure ("default") + Occurrence Bom Structure ("override behavior")

- Sheet metal RULES material ("default") + Material dropdown box ("override behavior")

Once you grasp this, I think you still stop fighting the program so much and start trying to figure out ways that work with the program instead of constantly finding yourself swimming upstream all of the time.

The point is that there SHOULD be a workflow to make 'anything' you want happen. Users who can't figure out that method can just resort to the 'override' behavior to get the job done and be functional, but miss out on the smooth workflow of the software.

Kinda like these forums -- the general Inventor Forums is for discussing the way the program works (default).... and the IdeaStation/Customization exists to try and make the program work the way you want it to (override).

--------------------------------------
Did you find this reply helpful ? If so please use the 'Accept as Solution' or 'Like' button below.

Justin K
Inventor 2018.2.3, Build 227 | Excel 2013+ VBA
ERP/CAD Communication | Custom Scripting
Machine Design | Process Optimization

iLogic/Inventor API: Autodesk Online Help | API Shortcut In Google Chrome | iLogic API Documentation
Vb.Net/VBA Programming: MSDN | Stackoverflow | Excel Object Model
Inventor API/VBA/Vb.Net Learning Resources: Forum Thread

Sample Solutions:Debugging in iLogic ( and Batch PDF Export Sample ) | API HasSaveCopyAs Issues |
BOM Export & Column Reorder | Reorient Skewed Part | Add Internal Profile Dogbones |
Run iLogic From VBA | Batch File Renaming| Continuous Pick/Rename Objects

Local Help: %PUBLIC%\Documents\Autodesk\Inventor 2018\Local Help

Ideas: Dockable/Customizable Property Browser | Section Line API/Thread Feature in Assembly/PartsList API Static Cells | Fourth BOM Type

jtylerbc · ‎04-05-2018

@johnsonshiue, that's correct. It's a specific combination that produces the problem. If you control everything from Sheet Metal Rules, all is well. If you control everything from the part material, all is well.

If you try to mix the two methods, you get the situation that @jletcher described. He has erroneously attributed the problem to derived parts in a multisolid scenario. It absolutely does happen there, but it is not unique to that situation. Any situation where the material in the part is not set to "By Sheet Metal Rule" will cause it.

As you mentioned, this is a "design choice" in the software, not a bug or limitation. In theory, it could have worked either way (Rule Material governs, or Part Material governs), as described in one of my earlier posts. Autodesk chose one over the other. James has a good reason for what he wants it to do - it just isn't compatible with the way it works now. @Curtis_Waguespack and @mcgyvr have expressed some support for his logic already, and there are likely others that would agree. I think it should be posted as an Idea to gauge the overall community's preference.

Personally, it doesn't make much of a difference to me which way this works. I briefly created the same template situation James has, but did so by mistake and quickly changed it. After changing it over to be entirely based on the Sheet Metal Rule materials, my result would be the same either way. I eliminated the conflict from my setup altogether, so how it resolves is not particularly important for me. But others may have good reasons for preferring a reversal of the convention. Both seem technically feasible, so the question would be which method would help the most users.

mcgyvr · ‎04-05-2018

@johnsonshiue wrote:

Hi Brian,

Many thanks for the explanation! I missed the part that the material style was overridden in the source file. I thought it was overridden in the derive part before derive happened. Indeed, the behavior is sort of as designed. I think the main confusion here is that Sheet Metal Defaults dialog does not convey the idea that the material (supposed to be dictated by Sheet Metal Rule) has been overridden manually. It would have been nicer if there is some sort of hint in the dialog showing that. Also, it would be great if the material style in the default Sheet Metal Rule is pushed to the derive part.

This is a design choice. Either way has a point. I will work with the project team and see how we can improve this workflow further.

Thanks again!

Johnson,

For my own curiosity...

Being that its functionality at least from a user side is undocumented (its not in the help and I haven't found it anywhere else) I wonder how its being labeled as a "design choice" vs a bug..?? How do you know its not a bug? Is there internal documentation that states the desired function of that? Are you just making an assumption in this case? There are quite a few things Inventor currently does that are still bugs.. Why is this labeled a "design choice"?

It carries over the "overridden" unfold rule.. But it does not carry over the "overridden" material.. Where is it documented that it should function like that?

That to me is 100% a bug and even goes against the definition of "derived" itself.. I expect something "derived" from another to start out with the exact same characteristics,etc.. as its source.

Per Autodesk the sheet metal styles includes the "complete material definition".. So to ignore the selected material should be seen as incorrect.

If the functionality will not be changed and classified as a bug at least the wording should as follows..

The check box should state "Link Sheet Metal and Unfold Rules"

And while we are talking about that.. The check box above it should say "Use Appearance override from source component".. Colors were removed starting in 2013

-------------------------------------------------------------------------------------------
Inventor 2023 - Dell Precision 5570

Did you find this reply helpful ? If so please use the Accept Solution button below.
Maybe buy me a beer through Venmo @mcgyvr1269

jletcher · ‎04-05-2018

And the bashing continues... See @Curtis_Waguespack I tried without rant and it got me nowhere.

@johnsonshiueare you going to address me or did I just waste my time a typing my reply to you?

Curtis_Waguespack · ‎04-05-2018

@jtylerbc wrote:

Curtis_Waguespack and mcgyvr have expressed some support for his logic already, and there are likely others that would agree. ...

To be clear, I've not recently stopped and taken time to understand the issue being discussed here exactly, but I am familiar with the settings from past setup efforts and trouble shooting issues, and remember it to be something akin to this:

A long time ago, I used to have a 3 way light switch that was wired wrong to start with, and then someone came along and replaced that light with a ceiling fan with a pull switch. So there were a couple of different ways to get that circuit in a state where none of the switches would turn the light back on.

In order to resolve it you had to either:

a) know that there was a "trick" to the circuit, and start trying different combinations on/off for each switch

b) know the combination needed

There are a few ambiguous areas of Inventor that are like this, where you need to know there that is a "trick" to it, in order to get it to work. And it's quite easy to get it into a state where nothing works, or where it's working in a way that the assumption you had to make to get started is causing it to not work as expected.

Much of this could probably be resolved by better, less ambiguous tooltips, and help file information.

Forum links: Inventor iLogic , API and Customization Forum | Inventor Ideas Forum | General Inventor Forum

Migrate Inventor Add-ins to 2025 .Net ( from .Net Framework)

Curtis_Waguespack · ‎04-05-2018

@Anonymous wrote:

See Curtis_Waguespack I tried without rant and it got me nowhere.

You've done pretty well. But you're probably still reaping what you've sown with past rants where you've been difficult to communicate with. If you treat people the way you have in the past they're not going to forget it over night. The nasty reply you just made to johnsonshiue is a current example

But I can tell you're making an effort!

Hang in there, and try not to enter every discussion thinking that the world it out to get you. I'm not saying it's not, but it's pretty amazing what we can accomplish when become mindful of how we communicate, and how our communications are perceived by others, rather than just puking out all of our thoughts and opinions at once, and expecting others to deal with it. I've been guilty of that in the past as well.

Keep focused on the technical statement of the issue, and much of the other stuff will just go away.

Forum links: Inventor iLogic , API and Customization Forum | Inventor Ideas Forum | General Inventor Forum

Migrate Inventor Add-ins to 2025 .Net ( from .Net Framework)

johnsonshiue · ‎04-05-2018

Hi Brian and James,

I got your point. When something requires repeated clarification, something is wrong. I do agree that the behavior is confusing (not that we lack examples). And, I also believe there is work to be done here. Like I explained earlier, there are two issues here. It is unclear to the users that the material style which is also part of sheet metal rule has been overridden. To be fair, there is an option "By Sheet Metal Rule" in the material dropdown list. However, it is still not apparent to the user that the active material style is not the one assigned in the sheet metal rule.

The second issue is about the meaning of "Link sheet metal styles" in Derive dialog. Please note that the option is linking sheet metal styles (sheet metal rule and sheet metal unfold rule). It is not to link to "Sheet Metal Defaults" As a result, the change in "Sheet Metal Defaults" may not propagate to the derive part. This is what I meant by design. There is a design choice here. 1) Push individual styles or 2) pushing the "Sheet Metal Defaults." The team chose #1 because it is more straight forward than #2.

Regarding the overridden material style, it is indeed a design choice. Should it follow the source sheet metal style, while the material style has been overridden in "Sheet Metal Defaults" or should it push the overridden style. In this case, Inventor assumes the user would select the material style manually.

Unfortunately, these intricate behaviors are not well-documented. Even if it did, it might not be easy to understand.

I personally think the best behavior should be following sheet metal styles. The material style chosen in the sheet metal rule should be pushed to the derive part. Then we will get another dilemma. What about the appearance? You can end up with confusing behaviors. I think this may be why we are having the current behavior to begin with.

Anyway, I believe there is work to be done. I will work with the project team and see what we can do.

Many thanks!

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

kimK7B54 · ‎02-15-2019

removed

@jtylerbc wrote:

@jletcher wrote:

So if a costumer calls and says now he wants it out of material "XX". What you are saying it will never change that material from generic I now have to go to every derived part and change it because I have 1" thick set to generic.

It's not that it will "never change the material from Generic". It's that it's changing the material TO Generic, as an override to what the rule said. Aside from that fundamental misunderstanding, what you described is exactly the workflow. But normally, that would be used as an exception in a setup that was primarily driven by sheet metal rules.

If I were preparing for a situation like this, I would set up the materials to follow the sheet metal rule, including in the template, and define the sheet metal rule materials as the most common material for that thickness. Then if the oddball exception case popped up, I would override the material in the parts. Rather than manually going into each part as you described, I would go into the BOM for the assembly, add the Material column, and change all the materials in all the parts from that one screen. The key thing is letting the rules drive the common scenario, and then manually defining the material exceptions when you need them.

Instead, you're setting up a configuration where you are defaulting to an override, then trying to make the standard apply as the exception.

@jletcher wrote:

I am not about to set up 30 1" thick styles so all the materials can be called out in them or 157 1/8" thick styles so I can have material all linked. blue plastic, black plastic, S/S, HR P&O, and so on.

If you actually have that many options, and are unwilling to do the work necessary to set it up properly (which may be understandable given the number of combinations), then perhaps controlling material by rule isn't the best choice for you in the first place. My setup is entirely rule-driven, but in my case that currently results in a total of about 70 rules. Many of those rules actually have geometric differences based on AISC guidelines for minimum bend radii for bent plates, which is dependent on both material and thickness. So they needed to exist anyway. If in your scenario the only difference is the material, rather than the bend parameters, then maybe you're not gaining anything from the use of rule-driven materials.

@jletcher wrote:

That link should overwrite everything needed to match the master 100%.

That's exactly what it would do, if you would just stop overriding it. You are specifically telling it not to match the master, then complaining when it does exactly what you told it to do. That's not a software flaw, that's user error.

jletcher · ‎02-20-2019

Wow you missed the whole issue and this issue is dead with 2019.

kimK7B54 · ‎02-20-2019

@jletcher wrote:

Wow you missed the whole issue and this issue is dead with 2019.

Perhaps your replies were less than helpful. I was having the same issue and nothing you said helped. I found the solution on my own.

kimK7B54 · ‎02-20-2019

After dealing with the same frustration, what solved it for me was finding this setting. Perhaps the original poster was also unaware of this setting. A simple screenshot would have saved me hours.

jtylerbc · ‎02-20-2019

@kimK7B54 ,

That's the same setting I was referring to in post #2. I didn't show a picture, so it may not have been as clear as I should have made it. Sorry if I didn't make it clear enough for you to follow what I was talking about - could have saved you some of those hours. At least now, with your screenshot, it should be clearer to anyone else that stumbles across this thread.

As mentioned earlier, I had the same problem myself when I revamped my templates for the 2018 release, so I understand the frustration. I understand now, but at the time I was pretty confused. Since I was working on some sheet metal-related iLogic automation at the same time, for a little while I went down the wrong path thinking something was wrong in my code, before realizing it was just a material setting in the template file.

jletcher · ‎02-21-2019

@kimK7B54

I knew of it but it does not address my main issue.

See 1/8 stainless #3 finish is used most of the time at this clients shop so default template was set for that to save steps, By changing that adds those steps back.

My issue is all should change no matter the default template because that is what I am telling it to do.

So your issue is not the same as my issue and in 2019 my issue is still there ..

jtylerbc · ‎02-21-2019

As currently designed, setting the material in your part to anything other than "By Sheet Metal Rule" acts like an override to the material that is defined in the Sheet Metal Rule. This results in the behavior that both you and the original poster were seeing.

If you define the materials in the Sheet Metal Rules, and have the material set to "By Sheet Metal Rule" in your template, everything works fine (this is what I do in my current setup).
If you don't define the materials in the Sheet Metal Rules, and just control it manually at the individual part level, everything works fine.

I'm not entirely certain if @jletcher knew about the setting or not at the beginning of the discussion. But whether he was aware at the time or not, neither method is ideal for his situation. He has a large variation of materials and thicknesses, which makes it impractical to make individual rules for all the possible combinations, so he can't proceed with the first option. He also has some cases where he wants the rule to control the material, so the second option is also not ideal.

What he really needs is a mix of the two, which doesn't work in the current design of the feature. The ideal solution for him would be if the behavior were changed so that the Sheet Metal Rule's specified material replaces the template material. However, since there's a good chance that would mess things up for other people who are making use of the current "override" behavior of the part material, it's not a quick and easy change to make.

Poor documentation on the way all of this is supposed to work is a big part of the problem, as mentioned by some of the other posters. Many users are unclear on the way it is intended to work, which leads to arguments as to whether it is working correctly or not. Much of this thread was taken up by such arguments, with me insisting I was right (because my way works currently) and James insisting he was right (because his way would work better for his application), and neither of us having anything we could point to for an official statement of what it is supposed to be doing. Better documentation could have made the behavior clear to everyone, even if they didn't agree with how it worked.

Ultimately, this thread probably should have been an Idea posting. The location of the post, and the way it was written, made it seem like James didn't understand the way the Sheet Metal Style linking worked. In reality, he may have understood, but was really asking for a change to the way it worked. Unfortunately that wasn't made all that clear, especially in the beginning.

2018 Link sheet metal issue

2018 Link sheet metal issue

Forums Links

Post to forums