Nasty: Pattern on Spline bug

[WHolzwarth]

This seems to be a dead-end street, and no way out. I've tried it with all versions, from 2010 to 2015. See file (2010).

I tried to pattern a point together with a corresponding workplane along a spline. If you mouse over the rectangular pattern, you can see the workplanes, and an array of workpoints. If you edit the pattern, you can see the members: 1st workplane and origin point.

1st bug: Not the origin point is patterned, but the end point of the spline instead.

2nd bug: Though the preview of the patterned workplane shows ok, all of them are placed in the same positon as the first one.

3rd bug: If Rectangular pattern1 is deleted, the spline changes it's position and look - starting point equal to end point.

Funny, isn't it?

Walter

[johnsonshiue]

Walter,

The file seems to be corrupted somehow. Look at the origin point. It seems to be detached from where it is supposed to be. If you do rebuild all, the spline will close itself. I guess it might be the reason the pattern does not work correctly. Do you recall how the origin point becomes detached?

Many thanks!

[WHolzwarth]

I'm surprised with this behavior, too, Johnson.

I'll do a new test with a similar setup tomorrow.

Walter

[WHolzwarth]

Here we go again, with an initially ok file from 2010. The same things happen with 2014, too. I didn't test 2015, but I think, nothing will change.

Try this:

-Edit Rectangularpattern1

- Click on >>

- Switch Direction1 to Adjust.-> Collapse

- Try to switch back to Identical -> No luck

[johnsonshiue · Accepted solution]

Walter,

This is an excellent catch! The culprit seems to be related to Adjust option in Rectangular Pattern. I don't understand why it behaves like this and it should alter origin point unexpectedly. I suspect it has something to do with involuted feature dependency: patterned feature is also a parent of the path.

In the meantime, you could create a grounded workpoint on top of the origin point. Then select the grounded workpoint instead of the origin point to pattern. It essentially cut the dependency.

Many thanks!

[WHolzwarth]

That did it, Johnson.

Consequence: Never ever use Origin members for pattern tasks

[johnsonshiue]

Hi! It is not true that the behavior discourages patterning origin work geometry. This is a specific case that Pattern Adjust does not handle well. So far it looks like the following conditions could replicate the same behavior.

1) Pattern path depends on a work feature which is patterned.

2) Normal to path workplane is also patterned,

In a sense, you have a situation that A (norma to path workplane) depends on B (path), who depends on C (origin point). But, only A and C are patterned. I guess Pattern Adjust got confused by this situation. The behavior is not right.

Thanks!