I'm having an issue with the filenames assigned by Rulestream when I place a standard assembly from a Solid Edge spec.
If the Solid Edge spec contains a SINGLE .asm file as a template, and I specify the working filename from a property so that it does NOT use the Rulestream default filename convention, the components in the .asm file retain their original names. This is exactly what I want.
However, if the Solid Edge spec contains MULTIPLE .asm files where I select one based on a property, and I specify the working filename from a property so that it does NOT use the Rulestream default filename convention, all of the components in that assembly are being assigned the Rulestream names (that is, all the "extra" stuff in parentheses like "ETO000038-1-879-1"). I don't see why this is the case. Clearly the specified property was used for the subassembly filename, but why the subparts all got the added characters is beyond my understanding.
The subassembly CHA-1705-6-RS.ASM was placed by Rulestream from a list of templates.
Note that its filename was assigned as specified from a property (that is, NOT the default <BASENAME>-(<PROJECT ID>-.....))
ALL of the components that were contained in it (that is, components that exist in the imported assembly, not "placed" separately by Rulestream) get the Rulestream default characters attached to them. Not good.
The subassembly cha-1522-rs1.asm was placed by Rulestream from a Solid Edge spec that contained only this single assembly file in the template list.
Note that Rulestream placed the assembly with all of its components with the filenames as they were imported. This is the correct action.
Any thoughts on how to get the multiple template example to work correctly?
I have a similar problem. The SE spec has a part file with a part copy placed in it. The part copy body is always renamed with the Rulestream suffix in the release folder. I have not been able to find a way around it yet.
Yes, your problem sounds similar. Supposedly this was fixed for assemblies in 8.15.1 (their reference in Release Notes is D-05439). However, it still doesn't work, so I'm not sure what was "fixed". This problem wreaks havoc with my ability to check in assemblies to our PLM system because the default Rulestream filenaming convention does not fit our system standards.
Thanks for first checking with the Community to see why the correction we provided wasn't working for you. That's a good use of the Forum! I saw your post and asked the team to take a deaper look.
They were able to replicate the behavior you are seeing by moving their test template assembly to any Part Family other than the one at the top. In other words, in our testing where the assemblies were in a simple application and placed in the Top Level Part Family everything works as documented in the 8.15.1 release notes.
Why this doesn't work when we move these same assemblies to any other level in the Product Strucure needs to be figured out and corrected. We currently await an assessment from Development from which I will be able to provide an estimate on when we can deliver a correction.
I'll update this thread as we progress this issue.
After three months, is there any hint of a solution to this issue?
Note that the example I gave shows that this issue also occurs at the Top Level. The issue appears to occur when there are multiple templates in the spec where a single one gets selected by a property. As I indicated, the arbitrary filenaming plays havoc with our PLM system, since the format of the renamed files violates our filenaming standards.