Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
This seems to be a straight forward operation, but it's just not working in WF5. I created an extrusion and round, move copied it, then axis patterned the moved surface. I'm able to merge the extruded rivit with the wheel, but when I try to do an axis pattern of the merge it fails; no matter which object I select first. I've tried patterning individual features and groups, but the merge always fails.
The wheel spoke seen in the images were constructed the same way, and worked without any problem.
Could this be a bug with the software, or am I missing something here? Trying to merge every instences of the pattern is just way too time consuming.
These fail quite often. You have to know what has to be grouped in order to have a complete definition of the feature... and having said that, some features prefer to be excluded from the group. Yep, sometimes it is pure luck. If you have too much trouble, and you have maintenance, you can always put the customer service guys on the job.
If you create a reference pattern all references of the feature/group which are to the first instance in the referenced pattern, are replaced by the corresponding references in the second instance, and so on.
The two most likely reasons for the pattern to fail are:
1. One or more of the references that are not varied by the pattern do not exist at the place of an instance.
For example: If one half cylinder is selected as reference, the pattern may fail when it gets into the area of the other cylinder half.
This can normally be tested by trying to redefine/modify the original feature accordingly and see if it fails
2. One reference is "eaten up" by the pattern.
Merges are apt for this, as every merge elimiates the second selected quilt, merging its geometry into the first selected quilt. But also solid features may remove surfaces or edges.
For example: If multiple quilts should be merged to the same surface, it needs to be selected first, or it will no longer exist for the second instance.
The latter is the more difficult case, as it cannot be tested with the original feature. For troubleshooting I normally create a pattern of two and vary the offset or increase the number of instances until it fails, then check what has changed in comparison to the last successful regeneration.
Normally either a reference was lost or the references have changed in a way the feature geometry can no longer be created. No magical mysteries!
For example, if the contour of a flat surface is projected onto a sketch, the sketch will fail for a pattern instance that is rotated to be normal to the surface, as the projection will become a single line (actually multiple overlapping lines).
I've tried modifying the original patterned cylinder and checking as well as using different references, but no luck.
However, I did find something interesting; when I pattern the features indivdually, the merge pattern is somehow being reference to a different pattern feature earlier in the model (spoke cut-out). This looks like there's something wrong with the software.
I often dump the reference pattern and opt for the axis... this was a great add from PTC.
The other feature of the pattern that helps a lot is using a defined origin.
Gunter; I have once submitted a support case on this and they grouped all but one of the dependent features to make the pattern work. I asked why the last feature was not included in the group. The pattern failed when I included it and I asked why. I never received a reply.
I did use axis pattern, but the referenced merge was somehow not referencing the correct pattern. I ended up moving the new pattern feature before the previous pattern feature, and it worked.
Ok. This is definitely a PTC bug. I reordered the feature just ahead of the other pattern (spoke cut-out) and everything worked as they should. Just frustrates me that they charge so much for a tool that is this unstable. Oh, I usually figure out the problem before support can get back to me.
Yes, it is difficiult to know exactly how to get a -good- pattern. And in some cases, even scary as it may -look- good but be off by some small error. What good is fewer mouse clicks when you have to redo the feature many times to make it correct? We could really use an "pattern intent" engine to help correct geometry relations to allow logical patterns or even give the "Next Solution" options. This feature is getting stale and needs some new life added to it for the 21st century.
I doubt that it is a bug (I don't remember seing pattern references being mixed up in 20 years - plenty of other things going wrong with pattern during this time, but not this simple selection mechanism). There is normally a good reason, why such things happen, but it is not always easy to understand at first glance.
We have seen this often enough:
Of course I agree, that it would be nice to implement some means to warn the user of multiple possible ref patterns and explicitly ask, which to follow, but for such a thing to be worth implementing, we probably do not see this happen often enough.
If you really believe it is a bug, open a case with Technical Support. In worst case you will get an explanation of how the other pattern comes into play. Please post the news in this thread then.
Normally it is rather easy to overcome the situation, as you have noticed yourself:
I suspect that due to reordering the pattern, a geometry reference (surface or edge) now has a different parent.
If you cannot reorder, you can sometimes change the start of the pattern (if it is circular), because the pattern reference is taken into account only, if the leader of the pattern is referenced.
By changing start I mean for example: If you have a pattern of four starting at 0 degree, increment 90, start at -90 instead (or at +90 or +180). This way the pattern leader will no longer interfere with the leader of the other pattern.
Gunter Koch wrote:
<snip>
Of course I agree, that it would be nice to implement some means to warn the user of multiple possible ref patterns and explicitly ask, which to follow, but for such a thing to be worth implementing, we probably do not see this happen often enough.
...
Gunter, you said a mouthful here.
I can promise you that this happens more often than not even with very experienced users. Not only the reference pattern, but axial patterns fail all too often for some silly little reference in the feature being patterned.
Most seasoned users have learned that patterns will fail and they simply have to try and try again or manipulate the geometry in some way. A serious waste of mouse-clicks and the source of much frustration. If PTC doesn't already realize that this is an issue, maybe PTC should ask the user community.
A significant pattern enhancement could be a boon to Creo 3.0. Sometimes users just give up asking after a few decades. Can you imagine the response if you tried to take away axis patterns now that its been introduced
Any time the software has to make a choice, or is unsure, it should ask about alternate solutions. All too often I get a pattern that fails only a few instances within the pattern. A simple little change to the geometry fixes it even if the original, and several of the instances do not fail.
This one in particular was a complete failure. It would not allow me to pattern it with a largerer form tool fillet at the edges of the spherical feature which had nothing to do with the merged edges of the pattern. I spent a half a day to make this feature pattern correctly including several methods in creating the spherical dome. I ended up having to create the form tool feature 10 times rather than patterning a 10th section 10 times on the axis. I probably have 5 failed versions of this very same part all done differently, mostly because the pattern kept failing.
I have come across this bug -or whatever it is- in several releases now.
Try this:
BEFORE adding a new surface+merge pattern, suppress the other older ones! Create the new surface+merge pattern and now it will work. Then resume the 'old' ones and they should work as well.
For the next new surface+merge pattern again, suppress all previous ones and then create the new one...
Might sound funny but it worked for me in the past...
Yes, this is a typical case as I mentioned it in my post from Sep 6, 2013 4:40 PM.
It is a variation of my number two of the "most likely reasons for the pattern to fail":
A merge elimiates the second selected quilt, merging its geometry into the first selected quilt.
What is happening is, that your pattern in the original design is becoming the new parent of a referenced surface.
If you change the order to move the pattern after the "unwanted child", then a different feature will become the parent (the previous owner of the referenced surface).
As a rule the last feature that manipulates a geometry item (e.g. edge, surface) will become it's parent.
This is how the parametric referencing is working.
With the Reference Viewer you can see parent features and references. You should notice a difference, after you reorder the pattern.
And again: If you can send an example model, Technical Support will be able to either explain the situation in detail or open an SPR to have R&D investigate.
In an addition to this, when merging surfaces the surface ID is of great importance being the reference indentifyer.
As a rule always the first selected surface passes on its ID. So selection order does matter.
Mapping it to this case, even if the firt merge follows the rule and thus the ref pattern does NOT change the surface ID (checking surface ID of quilt with all merges and ID before merges), following merge patterns will fail.
This is against the logic...
Gunter,
In general, when things are done in order, the software should be able to figure out which feature/pattern to reference to. As you had mentioned, the order of selection will affect which pattern Creo chooses, but the reference merge still failed even when it choosed the correct pattern to reference. I've also tried grouping the features before patterning it, so there is no excuse to have just the merge fail. If the software doesn't know which reference to use, it needs to present the options.
When a workaround is needed, it usually means the software has a bug/deficiency. We shouldn't have to waste valuable productivity time to trouble shoot simple tasks like this.
Understand that not everyone will have the same problems, even on the same model. (I've been in situations where the model fails on one system, but regenerates perfectly on another). This will be a whole other topic.
I've just tried your solution, and it worked too. However, I had to supress the previous 2 merges instead of just one, as it will try to reference pattern to that previous merge.
I guess this is similar to me reordering/inserting the new merge pattern feature before those feature. Now we have 2 possible work-around to this problem.
Hi Nai,
i wrote 'suppress all previous ones'...
Antonius, Nai Yang and all,
I think I have to clarify what I meant in my previous posts, before discussion gets out of control:
When I said:
but for such a thing to be worth implementing, we probably do not see this happen often enough
I did not say that pattern as such are too exotic or that they fail too rarely. I just meant that it happens not too often that a pattern fails for the reason of two or more non-related patterns being referenced. And if it really is the case, it is not too hard to figure this cause out, if you are aware of having several pattern in place.
In fact from what I read from Nai Yang, I doubt that it is the case here either (of course I can't tell for sure, without having the model in hands). It is much more likely that a reference that was supposed to be used, has been eaten up by another feature, which also was patterned. But the second pattern was not appropriate as a reference for the ref pattern. In such a case, there would be no choice between two pattern and hence nothing Creo could ask you for.
Regarding the bearing cage shown in the picture from Antonius: If this geometry has been created with a form tool in sheetmetal, it is quite a task, even creating the original, first dome. I would not even have tried, because form features are pretty tricky about touching the boundaries of the surfaces they are added to. I'd rather try my luck with a solid or use surfaces and thicken them.
Since the part looks pretty symmetrical, I believe creating it should be a "piece of cake"! (please excuse the pun):
In general ref pattern is no miracle:
So normally you can easily check, whether a pattern instance should generally work with the patterned references by redefining the leader, applying the corresponding references.
Unfortunately there are two more things that can make a pattern fail:
Creo Parametric tries to diagnose and assist the user, as good as possible. However, all those examples above have in common, that there is nothing wrong or unclear with the pattern definition. Just the feature references specified by the user (directly or indirectly by pattern) are not practical for the geometry they are supposed to be applied to. So Creo cannot warn of anything or offer alternate choices, before the feature fails.
And still then it can hardly make useful suggestion as it does not know, what the user wants to achieve (pattern the feature, yes - but not how to pattern it, i.e. with which references to guide the pattern and how to merge it to geometry that is not there).
This is the point where only the user can step in and reconsider the design - sorry, that I have no other news!
And again:
If you cannot figure out, why a pattern fails, open a case with PTC Support. If the situation can neither be solved nor explained in TS, an SPR will involve R&D and if they cannot solve or explain the issue, they will have to implement a fix. And they do, as they always did in the past!
This is why I can pretty safely say, that it is nowadays very unlikely that a pattern fails due to a bug or deficiency. In 99 % of failures there is a reasonable explanation and you should not ask for anything less as an answer. In those rare cases left over, the software will be fixed.
So in either case there should not be any reason to complain (at least not for a long time, after it has been reported).
It is sheetmetal and it was the only realistic way to create the cage. It is actually a very simple quilt form feature.
This should probably be reserved for a different discussion, however.
edit: I have submitted the bearing cage as a support case. This is a nearly perfect test case for both sheetmetal forms and patterns. In this case, one instance of the pattern fails, yet I can make the exact same form feature from the patterned form quilt at the failed location. FYI, the form can be a semi-sphere or a full sphere. The rounds on the edges are part of the form feature.