Can Mid-Planes Update with Linear Patterns?

[janelson33]

Title is self exclamatory.

Screencast is located here: https://knowledge.autodesk.com/community/screencast/4d757f3f-f0f2-4d38-8363-0b3676b10d30

Gosh I hope the software can do this simple task.

I was also wondering if that slowness is normal between the features?

[JDMather]

Can you Attach your *.ipt file here?

Is there a logical reason that you are using standard tools rather than Sheet Metal tools for this design?

[janelson33]

I believe I used the second file that was posted to me here, from MikeKovacik4928, as it seemed better with how he set up the parameters. I don't know why it's an amalgamation of two part styles either; the part solved my needs at the time is all. Since the higher-ups liked the way this made our figures look, I needed to make it easy to use, so here I am now with my slightly modified version.

Anyways, here's the file..I'm assuming you asked for it because it should work?

[johnsonshiue]

Hi Jarott,

Please attach the file here. The behavior does not seem to make sense. I would like to understand it better.

Many thanks!

[johnsonshiue]

Hi Jarott,

I took a quick look at the part. I think I know why it is failing. The failure is legitimate though. The mid-plane was created based on the to parallel faces of the patterned body. When you changed the number of pattern occurrences, one of the faces would be gone and the mid-plane lost a reference and failed.

This is a case of geometric operation not fully realizing design intent. Your intent is to have the mid-plate in the middle of the pattern. But, the mid-plane is actually based on the two faces generated by the pattern feature. I am wondering how other professional MCAD systems handle this situation. But, Inventor's behavior in this case seems logical to me.

To avoid the failure, I would create a rectangular sketch depicting the scope of the pattern via parameters. Then create the workplane based on the middle of the of the sketch instead of the two faces. Or, simply use an equation to calculate the offset distance (half of the pattern extent) from origin and create the offset workplane.

Many thanks!

[janelson33]

Thanks for taking a look!

I figured it had to do with some sort of hierarchy/logic issue in the programming for sure. I am going to try and replicate this in SW 2014 one day as I believe it would update as I intended it to here, based on my experience with the software so far. I think that is one thing SW excels at as it seems to know what you had, and how to shift the things before and after the edits to the next best version that won't hopefully crash...but it of course isn't perfect.

You don't think it has anything to do with the wonkier way it way originally made by MikeKovacik4928, right?

I thought I would be beating out any problem because I have selected what is very simply, the last face of that pattern feature to create my mid-plane. It seems to me, that a smarter solution would be to best solve for how the part was before the change, especially based on my mid-plane inputs alone, right? Like how does that practically make sense? I get it from an objective point, but we users want better intuitive, parametric capabilities like this so our parts just work the way we think they should. Last face is last face, right? I know my ideas are very basic with respect to what actually has to be coded in, but I believe that how the software should think about things.

Originally, the plane was created like you've suggested, as you can see from MikeKovacik4928's design; I guess he knew what he was doing in that regard. Using the right parameters, I can likely get it automatic like I want, it's just not as practical as I had hoped is all.

[johnsonshiue]

Hi Jarott,

There is nothing wrong with the way the part was modeled. One thing I would do differently is to right-click on the Flat Pattern -> check Defer Update. This particular part takes a long time to compute is primarily due to the flat pattern. The part has many bends and the faces have to be checked for unfoldability. The check is quite expensive.

But, eventually, you still need to compute Flat Pattern by unchecking Defer Update. Otherwise, the drawing will not be in sync.

Regarding the mid-plane failure, for this particular case, I don't believe Inventor has such notion that particular face is created by the "last" feature pattern occurrence. The faces have direct dependency on the feature pattern and that is it. When the number of occurrences is changed, the particular face is gone and the mid-plane fails. I believe you can reproduce the behavior in several different ways.

You and I have discussed similar feature dependency issues before. I think the fundamental issue here is that the feature operations do not thoroughly retain user's logical design intent. In some way, it treats feature operation as geometric operation. Feature-based parametric modeling is more than geometric modeling. It should be able to capture user's intent beyond geometry. But, as this case shows, Inventor has room for improvement.

Many thanks!

[blandb]

Like @johnsonshiue had mentioned, if the plane was made by selecting the start face and an end face to bisect the overall length, the mid plane will not work as the pattern length changes. The faces are removed that were used to generate the plane to begin with once the pattern count changes, so how is the software now going to know what faces to use to create a bisect plane? It will not just randomly grab faces.

In this case of how the part is set, it would be better to use parameters and formulas to define where the mid plane needs to be, or alter the original sketch and have it be dimensioned offset from the origin the correct amount so that when an overall length is updated via parameters or however the part was made, the origin plane would remain in the middle.

Hope that helps clarify

[janelson33]

Thanks for the tip regarding the flat pattern. I don't even need it, so it's been deleted now and it definitely has better performance!

I tried using Parameters to make an Offset Plane and now I'm wondering if this can be done with the parameter I intended. Since I want to make the Offset Plane update on the fly with my other Parameters, I've tried linking it to the Linear Pattern as you'll see below.

Parameter Cannot be Used

I've provided this shot of my linear pattern window so you can see where that variable is in the Linear Pattern Window.

Variable Location in Linear Pattern

I thought maybe, just maybe it had to do with the feature being named the same as the parameter, but it wasn't affecting it. I also thought it might have something to do with it being negative/incomputable as a number thus it was like, "Hey this dimension is impossible dude!" That also does not seem to be the case. It just seems like I cannot use that parameter.

I almost stopped typing this because I thought I had it figured out. As you can see CORE_WIDTH does not even work as a User Defined Parameter in my Parameter Window. Thoughts?Why are you The Devil?

[janelson33]

Wow I think I just realized why not after scrolling past one photo...the CORE_WIDTH parameter has no units, so I can't have a unit-less parameter multiplying a unit-less value, correct? I guess I'll have to figure that one out now!

[janelson33]

The only point I was trying to make is that a mid-plane is a mid-plane is a mid-plane. As we know, the way it is made in the software is by selecting two faces that you want a plane in the middle of.

I figured that with a linear pattern, the software is smart enough to look for changes and homeostasis all at once. To me, that means I need to be more flexible/adaptable/stable as a mid-plane created off of the linear pattern feature.

The way I have my math for the pattern means that an edge, just like the original plane was made from, will literally always be there. I know it's not Instance 32's Surface, but hell Instance 15's Surface is the exact same, this seems like a solution, let's do that!

The way I have laid it out means that there is no error in this scenario! I believe most people would always prefer this to having to be like, uhhhhhhh, what happened? I thought I used my parameters, equations and dimensions correctly.

I really wish my method did work since the parameter I want to use is unit-less and a PITA to integrate, as you can see from my reply to Johnson above.

[blandb]

Core_width is the count field in the pattern, so it will be unitless, it will not be a distance. You can use say "CORE_WIDTH*FIN_PITCH" or whatever to make it work.