cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Feature Failure with Repeating Patterns

jwickham-2
1-Newbie

Feature Failure with Repeating Patterns

Just recently I transfered from one division of my company to another. The first division used SolidWorks and the new division uses Creo. It has been over a decade since I used Pro/E so I am effectively a newbie. I am trying to create a structure based on a 3D array of a unit cell. Here is a screen shot of a portion of the cell created in Creo.

truss-pyramid+3.jpg

This is where I get stuck. This part must be mirrored a few times to create the actual unit cell. Since the mirror feature in Creo has no ability to revise the selections after creating it, I am trying to figure out how to pattern it with an axial pattern. When I attempt to do so, Creo gives an error stating, "Some features failed to regenerate." See the attached model.

Below is a screen shot from SolidWorks showing what the unit cell should look like, and another screen shot showing what the full 3D array should look like.

Truss+-+Pyramid+2.JPG

Truss+-+Pyramid.JPG

Any suggestions on how to make the patterns work?


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
ACCEPTED SOLUTION

Accepted Solutions

At least I learned a few things after a day's effort to understand the fact that Creo simply doesn't do "dumb solids".

Therefore, nesting cells of a feature in a part file is not really recommended although it would be interesting to see what customer support would do with this type of requirement.

Therefore, yes, if you needed this kind of structure, it is best done in an assembly just to manage CPU and memory if nothing else.

However, I did go Matt's route on this and hyped it up a little. There is an interesting patterning tip hidden in the attached file. A little trick that allowed the file to be fully parametric based on the maximum matrix size you need without any serious math to vary the patterns. 2 final trim features can size it up to odd matrices so the idea is that you can specify the cell size, the tube size, and the NxNxN matrix size (all N's being equal). Careful though... it is a CPU workout when you start going over about 5 for matrix size.

I left the attached example in a small state to minimize the file size. Just play with the 3 relations at the part level. The cube will expand form the center.

If you want the "Union Jack" to show up at the edges, use an odd value for the matrix "nest_size". The very center will always be a complete cell as outlined in the original post. A 2x2x2 matrix will grow from the center and therefore the outer cells will be divided in half all around the core cell. To avoid this, set the nest_size to 3 and trim away the extra bits.

borg_cube_II.PNG

And the glamour shot...

borg_cube.PNG

Enjoy!

View solution in original post

73 REPLIES 73

The typical response from customer support for such attempts is to group the features before patterning.

I might also suggest you make sure you are on Creo 2.0 release M090. There were some serious bugs related to patterns in earlier releases. If that is not an option, you might try some other methods to create the 1st structure. Most often it is a very innocent little constraint that causes patterns to fail.

I also find that assembly patterns are a little more robust.

I will have a look at your file and see if I can find the problem area.

Try using the Copy and Paste Special and use the transformation option instead of the patterns.

Inoram
13-Aquamarine
(To:jwickham-2)

I used assembly pattern to get this, so kind of cheating and it's not all one part. I did make the one cube in part mode, though with pattern and mirror, but I don't really like it. Also I think it depends on how parametric you want this in the long run.

truss.JPG

TomD.inPDX
17-Peridot
(To:Inoram)

Yes, I am running into the same problems. I got it to "duplicate" with the copy/paste option, which is still parametric. But the replication in general should be -much- simpler and more reliable.

BTW: How do you get a 3 dimensional pattern to work in one shot? Or can you only do this with an X-Y pattern and then a Z pattern?

Inoram
13-Aquamarine
(To:TomD.inPDX)

yes 2 patterns, not one shot.

This is the single cube.

I do have a completely different idea I want to try, though.

singlecube.JPG

Inoram
13-Aquamarine
(To:Inoram)

ok bad idea.

truss4.JPG

TomD.inPDX
17-Peridot
(To:Inoram)

...but it is likely the right direction.

At least I learned a few things after a day's effort to understand the fact that Creo simply doesn't do "dumb solids".

Therefore, nesting cells of a feature in a part file is not really recommended although it would be interesting to see what customer support would do with this type of requirement.

Therefore, yes, if you needed this kind of structure, it is best done in an assembly just to manage CPU and memory if nothing else.

However, I did go Matt's route on this and hyped it up a little. There is an interesting patterning tip hidden in the attached file. A little trick that allowed the file to be fully parametric based on the maximum matrix size you need without any serious math to vary the patterns. 2 final trim features can size it up to odd matrices so the idea is that you can specify the cell size, the tube size, and the NxNxN matrix size (all N's being equal). Careful though... it is a CPU workout when you start going over about 5 for matrix size.

I left the attached example in a small state to minimize the file size. Just play with the 3 relations at the part level. The cube will expand form the center.

If you want the "Union Jack" to show up at the edges, use an odd value for the matrix "nest_size". The very center will always be a complete cell as outlined in the original post. A 2x2x2 matrix will grow from the center and therefore the outer cells will be divided in half all around the core cell. To avoid this, set the nest_size to 3 and trim away the extra bits.

borg_cube_II.PNG

And the glamour shot...

borg_cube.PNG

Enjoy!

Wow, that is a very creative way to model the part! Thank you very much Antonius.

The large matrices are a CPU workout for sure. I created a 5x5x5 matrix, then patterned it a few times. The linear pattern would only pattern one additional unit in one direction without giving errors, so it took three pattern features to make a 10x10x10. It was certainly a lot faster for the CPU than modeling a 10x10x10 to start with. This should be large enough for any of the parts we are going to make.

borg_cube_large.jpg

Happy I could help, Jeff. It seems the problem is in the parametric where the copy want to find features that were blended with other features. It really is a poor example of "Geometry copy" that should simply copy geometry, but in Creo's case, it still want to do operations. At least, that is what it is acting like.

Patterning the diagonals is still a bit iffy. I am using a "normal" fill pattern to pattern the tubes at a diagonal. I could only test up to 5x5x5 on my CPU. If anything, this diagonal pattern needs a closer look.

Inoram
13-Aquamarine
(To:TomD.inPDX)

Antonius, looks good, I was thinking that would be the next step, but I am wondering if you can put even more of it into the relation/equations?

TomD.inPDX
17-Peridot
(To:Inoram)

It is a pretty simple solution and I am certain it can take on some efficiency improvements. However, it is simply a bunch of pixy stiks replicated. There has to be a way to make it more efficient.

I took another look at the efficiency of the cube.

I applied a "Hail Mary" value to the diagonal's pattern fill section by making the width 2x the "big_cube"

In fact, you only need 2x "big_cube" minus "cube". This removes a superfluous copy at the corners.

Overall it didn't change the regeneration time by much, but worth noting.

d<nn>=(2*big_cube)-cube in the relations of 6 patterns

However, this effort did prove that the model is robust to any whole number value for nest-size.

This is the logic behind the fill pattern of the diagonals:

  • You cannot make the "diamond" fill-pattern required normal to the axis of the diagonal rods.
  • There is a tilted square pattern if you look normal to the cube.
    • The pattern dimension is the diagonal offset which is the diagonal of the 1/2 the cell size. (mini_diag)
  • The diagonal rod fill-pattern fills "laterally" along the normal cube.

borg_cube_III.PNG

borg_cube_IV.PNG

I did try a few other things and they failed miserably. The first thing was to try pattern-geometry copy. This threw out errors and, although the feature count went down dramatically, the regeneration time was still atrocious. There is still a lot of geometry checking going on.

What I don't understand is why the Pattern Option -Identical- is grayed out for all the patterns except the first one. This should resolve a lot of the regen issues. In theory, this would make a blind copy regardless of geometry checks. This use to work wonders in Unigraphics NX. I'm in Creo 2.0 M040 so I don't know if anything has changed in this regard in later versions. This is probably worth a support case to find out the reasoning behind it.

I would really like to invite one of PTC's gurus to have a look at this. Download the above file and set it to 9 replications (nest_size) and see just how much effort this requires. The regeneration seems to be never-ending! What is a better solution to improve regeneration times?

1:34:00 to regenerate a 9x9x9 cube. 2383 features 305Mb on save (wireframe display)

This is using a pattern - copy geometry for the 3 "normal" columns.

Ram was well managed during the regeneration. This is on an i7 2.40ghz processor.

borg_cube_V.PNG

This is the benchmark for alternate config options. Again, this has to be improved somehow. After reading more on patterns, every intersection of patterned geometry is evaluated. Only the 1st pattern can use "identical".

Edit: There is no difference whatsoever regenerating the file using the pattern - copy geometry vs. the normal pattern. Both regenerations took 1:34:00. The new feature count is 3103. The file size is slightly larger at 326Mb.

Instead of circular section rods, try octagons or other regular polygon. I'll wager the speed becomes freakishly fast. Whether it does or not, I'll be surprised.

Also, are you looking at memory deltas or just file size?

Windows Sysinternals Process Monitor v3.1 is pretty handy to keep an eye on what is happening and it comes in a no-install, run from the web version.

David, I did do a quick test in this manner to see if it makes a big difference. So far, no, it didn't but that was not a conclusive test. It should be easy enough the change the master sketches from a circle to a square since it is only used in 6 original instances.

I will test this again but I want to see if using relations a little differently will make a difference. Right now I have relations at the feature level. I wonder if using some of them at the section level will make a difference. I get a lot of ModelCkeck notices about multiple use of the same relation. I did check that there are no relation errors. During the processing, I get a lot of "Model Intent Unclear" errors.

But when you do this in assembly mode, no problems. It acts quickly and responsively.

In general, I can nest up to 5x without to much problems. It is certainly not linear.

I did watch watch my memory in the Task Manager. It was pretty steady only bumping up a little when it grabbed the next "batch". It never went into the virtual memory mode.

Attached is the latest version. Funny how it seems to grow the more I work with it. Nothing has really changed Lot's of bagage in these files!

Well, David, I would have made the same bet, but sure enough, we would both have lost.

I rebuilt the model from scratch just to see if there was a simpler way. I went very basic with sketch-extrude-pattern, 6x and a final trim. Copy Geometry patterns failed where conventional patterns didn't so each direction is made the same way. No internal sketches or datums; relations applicable to the sketches were applied in the sketch; relations to features were in the features; and there were very few top level relations.

When I first filed it, the file side was near 2.5Mb. The more you play with the file, the bigger it gets. I was able to save a stable version when it was still in the 4mb range. Once I ran the 5x matrix, and brought it back to 1x, the file had ballooned to 9mb!

I changed the 6 sketches replacing the round rods with square rods (changed the circle to construction). Sadly, even the square rods took quite some time to regenerate 1018 features to get a 5x matrix. Not having timed them side by side yet, I'd say they are equal.

I've attached the latest round version which is still fairly small and "clean". Have a go if you like.

I called this one Matrix to distinguish it from the other.

I also included the square version. All I changed is the 6 sketches and updated the diagonal planes with a point axis.

I might try a curve-only version just to see if this is simply a geometry thing or something that is inherent to patterning.

It makes sense that the file size with a wireframe display stored would go up - there are more edges. I was hoping that planar surfaces would result in faster intersection calculations and lower tesselation generation for speedier creation. Perhaps PTC has removed optimizations like that in favor of a single routine that treats all curves and the surfaces they generate the same. Maybe adding more, simpler curves to a section just doesn't help.

This is why I asked PTC to include detailed feedback to monitor the memory and cpu usage for each feature and for each part and assembly.

David, I reset the cube to a matrix of 1 before saving. The wireframe count in the file should have been identical.

There is simply way to much baggage being saved in our file. In only one version of Creo 2.0 we could see it all. And we have discussed removing it manually. We need a simple "purge history" that we can use on our files.

Here is one that is efficient since it is only wireframe (sketches). It also cannot be trimmed to a cube...

But I can nest this to a 25x matrix without issues.

matrix_wireframe.PNG

Now try something with the attached file.

Change the relation "matrix" to 20; regen; change matrix back to 1; regen; save. Look at the file size difference! The idea is that you really don't want to save the file if you ever generate the large version. The 25x matrix file went from 1.2Mb to 53mb even though it was only the single cell at the time of save.

Inoram
13-Aquamarine
(To:TomD.inPDX)

How did you do the first test? Just load your borg-cube model and change the nest size to 9?

TomD.inPDX
17-Peridot
(To:Inoram)

Yep... And then you go and eat dinner... enjoy a movie... and come back to see if the cube is baked for desert

Actually, I was checking alternative ways to make the cube. Normal patterns and copy-geometry patterns take just as much time. So the file I posted before is a good specimen to test your computer's horsepower with PTC.

Matt, see above. I've added 2 clean versions in reply to David.

Just change the value of "matrix" in relation to 1, 3, 5, 7, 9... etc. On my computer, 5 is tolerable but 7 and 9 just go out to lunch. I will be testing them on the 9x matrix tomorrow to see if they are still 1:34:00 even though they are "different" in implementation. I'd really like to get to the bottom of this one.

Inoram
13-Aquamarine
(To:TomD.inPDX)

yeah, something is different, yours said 2383 features, when I regen it, it was 3219 features.

TomD.inPDX
17-Peridot
(To:Inoram)

When you use geometry copy patterns, they read as one feature. But that doesn't make is faster.

The independent pattern part was 3103 features. I am not sure where the other 116 features would have come from.

1:28:00 at 3106 features in Matrix.prt on a 9x9x9

Inoram
13-Aquamarine
(To:TomD.inPDX)

I did not have time to mess with this today. BUT I see you posting about file size, which is an issue, but I am more concerned with the horrible regen times. And it does not even peg the CPU, not even on one core, so it seems to be limited somewhere else.

TomD.inPDX
17-Peridot
(To:Inoram)

We have had the baggage discussion before. This file just tends to highlight it.

As for regeneration time, in part mode, it is doing a lot of work intersecting geometry work. And this part has a lot of that! If they were surfaces, they don't merge on their own, so that would be an option if you didn't need to batch-trim all those to the cube shape.

I think Jeff helped is find the geometry that can bring Creo to its knees. I am sure this is only the 0.01% of us that really needs a solution for this kind of element. However, as you can tell by my efforts on this, it is certainly worth the investigation to try and shed some light on this. How to proceed forward from here, well, I guess that is up to each of us.

I for one still want a purge history capability to clean up such files. But I suspect I'll be turning several shades of blue before that happens.

TomU
23-Emerald IV
(To:TomD.inPDX)

1:04:00 to regenerate 9x9x9 matrix (borg_cube.prt).

File size: 693 MB

Creo Parametric 2.0 M080

Intel Core i7-4770K overclocked to 4.3 GHz (Gruman Creation GC-i7K4)

Announcements
NEW Creo+ Topics: Real-time Collaboration


Top Tags