This was fun; here's another method that does not use the length feature...
The part parameter "NUM_IN_X" specifies the number of cells in each row, and also drives the number of members in 1st direction of the 2D pattern "NUMBER_GRID".
The number of members in the 2nd direction of this pattern specifies the number of rows...
Grid adapted to flow to right and down, also with variable spacing between cells.
Also noted that multiple regenerations are needed with this method if the grid size is increased...
Interesting that no such requirement if the grid size is decreased.
I seriously don't know how you guys figure this stuff out! That is awesome. How did you figure that out!
We tried this method originally but couldn't get the two directions to work.
I new the number of columns was the limiting factor of my method. Moving forward I am probably going to use this method.
Yours seems to have a better regen time than mine as well.
One more small refinement. I added a relation to tie the increment of the rows to the number of columns. As it was, you had to manually match the two. Now all you need to do is change the number of pattern instances to set how many rows/columns you want. Everything else follows (after a regen).
Roger, I just had to investigate what was making my method so much slower than yours. I figured that using itos() function in a relation was a real drag (for some reason I thought that the text feature in sketch had to use string type of parameters). Changing to using integers sped things up considerably.
Still, your solution with 3 features per group was still faster than mine with only 2 per group. I can buy that a sketch feature with 4 dimensions is more costly than a point and an analysis feature.
So, I worked on it and stumbled on this method: a 2D pattern of sketches using a PART parameter CELL_TEXT which is re-calculated in each CELL with a sketch relation:
it is fast, and does not require multiple regenerations. Take a look; vary the PART parameters NUM_IN_X and NUM_IN_Y to change the grid size, and vary the NUMBER_GRID pattern increments d8 and d11 to change grid direction and spacing.
One more note: the file size is at the beginning small (attached PRT file is ~150kB).
But then: trying a 35x25 grid, then changing back to a 5x4 pattern and then saving the part results in a ~5.8MB file?!?!; Does anyone else get the same result (my system is Creo 2, M150) ?
I like it. I've done something similar for other things - I guess I should have thought about it a little longer. I guess I was just taking the proposed method and tweaking it to make it work in 2D.
Personally, I would ditch the parameters and control everything from the pattern definition. It does require another regen after changing the pattern, but I like controlling everything in one place:
I'm not sure what is happening with your file size. I took mine, went to 35x25 and then back to 5x4 and the file size was 381 kB. Creo 2 M120. I almost always work in Windchill, so I don't usually pay much attention to file size to be honest...
I just used your video and it worked like a charm. However, I need to have one pattern as you show it 1-50 and then another pattern 51-100. How do I start the second pattern.
simply repeat the same procedure once again using following relation
foo=length:FID_1_COUNT + (10*(length:FID_10_COUNT - 1)) + 50
That was too easy. Worked like a charm.
I've got another one for you.
I need to make a another set of numbers. These new numbers are an exact copy (1-100) just shifted to the right by 11".
What I want to do is copy the existing, paste using original references, modify the HORZ sketch by 11", and watch all the numbers translate.
What I get is a locked up computer and/or pattern failure and/or partial pattern regen (meaning some of the pattern doesn't show).
Any idea on how I can translate just the text without the processing baggage?