Bug related to Assembly Reference Pattern Both and pattern tables Creo 6.0

[GMMCO]

I have 16 years experience with ProE release 20 (~from 1999). My company recently upgraded to Creo 6.0, a big jump yes.

I've been doing assembly reference pattern both for 15 years and now there is a bug.  It works great in ProE release 20, but not in Creo 6.0

I did find this thread which may be the same issue, but not much else. 

https://community.ptc.com/t5/3D-Part-Assembly-Design/Components-missing-in-reference-pattern-both/m-p/561184

From what I can tell the bug is released to pattern tables. In the case of dimension patterns, the reference pattern both works great.  I used dim pattern on  planes, and then a dim pattern that was reference patterned to the planes. (pattern of a pattern)

Then for the assembly, when reference pattern type both is selected for a washer coincident with the first axis, the dots look correct like this:

and the washers come out correct:

Okay, now under a very similar scenario, but the planes are a pattern table pattern instead of a dimension pattern.  It works great on the part.

Then for the assembly, when reference pattern type both is selected for a washer coincident with the first axis, the dots look correct like this:

But the washer pattern is not correct. The quantity is correct at 12, but the 4th,5th,6th items are all coincident with the first axis. This makes interferences and no hardware on the last 3 holes.  What gives?  This is definitely a bug. I tested in ProE release 20 and it does not do this. Has anybody else seen this?  Any thoughts, ideas?

I also tested grouping the plane with the holes and doing a pattern table on that group. That works but I don't like doing this because you can't move things in/out of the group once patterned, so it is harder to maintain and work on. I like having a robust pattern table of planes by itself so the pattern doesn't need to be destroyed if I want to add/remove features. 

-JonA

[tbraxton]

I am not able to replicate the issue as presented in Creo 4 (m060) or Creo 7 (7.07). I do not have Creo 6 installed for testing. I have included a Creo 4 data set for testing. Inspect my version and confirm it is following the same model structure for the patterns. If not explain what the inconsistencies are and I will update the models on my end.

Open the assembly and test regeneration in Creo 6. It is possible it is an issue in Creo 6 but that would require some more testing.

When you did this in Creo 6 did you use a start part that was created in in Pro/E release 20? If so I would save a copy of that start part in Creo 6 and try this again. 

[GMMCO]

tbraxton-

Thank you for taking the time to help me and try for yourself. You've helped me figure this out. 

I've discovered the source of the bug and a workaround. Unfortunately the work around will likely break many dimensions on drawings, exploded states, sections on drawings, etc. 

The bug comes from the first entered row of the pattern table.  Should the idx be 2 or 1?  I was always trained that it should be 2, because it is the 2nd thing. Accordingly I have hundreds of parts in my library like this.  

This:

or This:

When the first entered row starts with idx 2, I get the assy ref pattern both bug:

files attached.

What's the generally accepted practice?  What is correct from PTC?  How can I let them know about this bug?

I'm not the only one who puts the first entered row as 2:

[pausob]

Well, I do see your point about the 2nd thing should have the index of 2.

On the other hand, this software was made by C programmers and so they count from 0, so the 2nd thing is at index 1.

And to be fair, the instruction was always there:

[GMMCO]

Gah!  I've been misinterpreting the 'indices start from 1' thing for 16 years. I thought that meant that the leader has an index of 1.  

Live and learn I guess. 

[pausob]

Hmm, now that you wrote this explanation, I see how that instruction can be misinterpreted.

Before, it was crystal clear and unambiguous to me.  I suppose it is an interesting case of how our assumptions can trick us.

[tbraxton · Accepted solution]

I am not sure it is a bug. I explain why below.

If you think it is then you can log a tech support call with PTC using this link.

https://support.ptc.com/apps/case_logger_viewer/cs/auth/ssl/log 

The documentation does indicate that the indices start from 1. Once you get past that the indices must be unique but not sequential. It comes from conventions used in programming (0,1,2....). This is displayed in the table editor and is in the help files.

• From the header in the table editor:
• Input placement dimensions and model name for each pattern member.
• The model name is that of the pattern leader or any of its family table instances. Indices start from 1. Each index has to be unique, but not necessarily sequential.
• Use for default value equal to the leader dimension and model name.
• Rows beginning with ’(@)' will be saved as comments.

[GMMCO]

Thank you for the feedback. 

I still think this a bug for at least 2 reasons

1) the mismatch between what the dots show and what the washer does

2) It used to work in Pro/E release 20 and now it doesn't

[tbraxton]

I agree that both of your points above are legitimate. My comment about not being a bug is that PTC would likely adopt the position that the software works to specification in this case (speculation on my part). If you have a model created in R20  that does not regenerate properly in Creo 6 then you have a strong case for having them fix this. 

The pattern preview and the fact that the pattern regenerates in Pro/E 20 are compelling. It is worth opening a call to see what happens. 

I am pretty sure that PTC changed the way that reference patterns work in the code since R20. This is based on some issues I have had with reference patterns that I did open tech support calls on.