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.
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.
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.
And the glamour shot...
Enjoy!
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.
yes 2 patterns, not one shot.
This is the single cube.
I do have a completely different idea I want to try, though.
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.
And the glamour shot...
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.
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.
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.
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.
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!
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.
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.
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.
