Repeat Region Table Filters...continue on next line?

[LawrenceS]

I am getting an error because evidently there is too many characters on one line for an OR statement in the repeat region table filters.  Does anyone know how to continue on next line or another work around? E.g.

• &asm.mbr.DESCRIPTION==*O-RING*,*BACK*UP*,*D*RING*,*SOLO*SEAL*,*PAR*BA*,*D*SEAL*

The above line is an example of too many characters on one line and Creo not accepting it...even after I delete the spaces (which oddly helps even though Creo will put the spaces back in when you hit ok...very fickle).

It would also be nice if we could do OR statements for different parameters...but maybe that is asking too much. E.g.

• &asm.mbr.name == 600*,&asm.mbr.DESCRIPTION==*o-ring*,*back*up*ring*

[TomU]

Do you have active maintenance?  I'm willing to create a support case and ask if you don't...

[LawrenceS]

I appreciate that @TomU, thank you!  Unfortunately I did open a case back in February, 2019 and they said that it was not possible ("Works to product specification" 😖), nor did they provide a usable workaround.  However, I thought I would through it out on the forum because I have seen PTC not be able to answer something but the users find better workarounds.  In this case it appears there may be no decent workaround.

[KenFarley]

The only thing I can think of, and I admit I kind of hate it, is to have an additional parameter in the parts, something like "useInTable" which is a boolean (Y/N) parameter. This seems nice, but the part I hate is I'd then have to add a relation to all the parts which determines the boolean value based on the part's DESCRIPTION. Why don't I like it?

(1) I've gotta jump into all the parts to add the parameter and the relations.

(2) I don't know what will happen if there are parts that don't have the given parameter - will the table fail? Experiments or advice from someone who has done this type of thing are needed.

(3) If I later find I need another criteria to be used, like I want to add "VALVE" to the okay descriptions, I would have to revisit all the parts and update the relations.

So, as implied, not an elegant solution, more akin to using a brick as a hammer, but it might work.

[MartinHanak]

---

@KenFarley wrote:

The only thing I can think of, and I admit I kind of hate it, is to have an additional parameter in the parts, something like "useInTable" which is a boolean (Y/N) parameter. This seems nice, but the part I hate is I'd then have to add a relation to all the parts which determines the boolean value based on the part's DESCRIPTION. Why don't I like it?

(1) I've gotta jump into all the parts to add the parameter and the relations.

(2) I don't know what will happen if there are parts that don't have the given parameter - will the table fail? Experiments or advice from someone who has done this type of thing are needed.

(3) If I later find I need another criteria to be used, like I want to add "VALVE" to the okay descriptions, I would have to revisit all the parts and update the relations.

So, as implied, not an elegant solution, more akin to using a brick as a hammer, but it might work.

---

Hi,

maybe using component parameter is the right solution. In this case user do not have to modify models, parameters are saved in assembly, only.

To make it easier to fill component parameter with specific value, user can develop auxiliary application which reads filtering conditions and assigns appropriate value.

[LawrenceS]

@MartinHanak, I don't think I understand your suggestion.  I am not sure how/where to modify component parameters if not in the component models.  I know no other way of doing this.  Also I am not sure what you mean by an auxiliary application.  Can you explain a little more for me?  Thanks!

[MartinHanak]

---

@LawrenceS wrote:

@MartinHanak, I don't think I understand your suggestion.  I am not sure how/where to modify component parameters if not in the component models.  I know no other way of doing this.  Also I am not sure what you mean by an auxiliary application.  Can you explain a little more for me?  Thanks!

---

Hi,

in attached rr_2019-11-21.zip (Creo 2.0 files) you can find example of component parameter.

• DESCRIPTION ... part parameter, saved in part file
• cpar1 ... component parameter, saved in assembly file

If requested functionality is not available in Creo, user can develop "auxiliary application" using programming API (Toolkit, J-Link, VB). In your case the app could:

• cycle through list of all components
• for every component read DESCRIPTION value, check the rule and set CPAR1 value to Y (if rule is satisfied, otherwise set N)

Then you will be able to filter repeat region using single parameter ... CPAR1

[LawrenceS]

At this point I don't think it is worth it to modify all our components to add a parameter.  This is a challenge with change state control and checking in/out.  Unless I misunderstood you, for our situation and the number of parts we have, I think the medicine would be worse than the sickness! 🙂  

[Mahesh_Sharma]

@LawrenceS 

As per current limitations for application 80 is the character limit for a line. Exceeding the limit will report error about line 2. 

Existing Idea : https://community.ptc.com/t5/Creo-Parametric-Ideas/character-limits-for-parameter-values-CS32012/idi-p/454577

EDIT: Having parameters in 2 different lines, as illustrated below, seems to work.

&asm.mbr.name == Cylinder,crankshaft
&asm.mbr.name == ENG_BLOCK_REAR, ENG_BEARING, ENG_BLOCK_FRONT

[TomU]

@Mahesh_Sharma, 

Is there any type of line continuation character that will work for repeat region filters?

[Mahesh_Sharma]

I don't think so.. 

[LawrenceS]

Thanks for the reply and suggestions!

• Yes, I guess it is 80 character limit for this one too.
• That idea is closed/archived and the one that was linked by Toby is not an idea at all but a discussion.  I commented on the page to the moderator so hopefully the will fix one of them...then I can vote on it...
• The code that you wrote across 2 lines will work but is not equivalent to one OR statement as when it is on 2 lines I think it interprets it as AND.  SO for example what you wrote would be interpreted as:
  • (cylinder OR crankshaft) AND (eng_block_rear OR eng_bearing OR eng_block_front)

[Mahesh_Sharma]

@LawrenceS 

Here is the original Idea to vote.. https://community.ptc.com/t5/Creo-Parametric-Ideas/Remove-the-80-Character-Barrier-for-String-Parameters/idi-p/464138

[BenLoosli]

I am not seeing what it is that you are asking for.

Your line:

&asm.mbr.DESCRIPTION==*O-RING*,*BACK*UP*,*D*RING*,*SOLO*SEAL*,*PAR*BA*,*D*SEAL*

Only contains 58 characters to be assigned to the Description parameter.

Are you trying to do an IF-Else type of Description?

Give an example of what your final output should look like and your proposed input to drive those results.

[TomU]

@LawrenceS made additional comments here:  https://community.ptc.com/t5/Assembly-Design/Filter-Repeat-Region-by-Two-Conditions/m-p/636830#M20176

[LawrenceS]

@BenLoosli ,

No, I am not Trying to do an IF else statement in the Filter. 

I think it is 80 characters for the entire line including the parameter and including spaces...but even so I checked again and the code I posted is actually 79 characters and does work with all the spaces.  I tried to create part of it from memory after I made a modification and it looks like I forgot part of it.  Purely as an example though if you add anything else Creo will not accept it. E.g. 

&asm.mbr.DESCRIPTION==*O-RING*,*BACK*UP*,*D*RING*,*SOLO*SEAL*,*PAR*BA*,*D*SEAL*,*P*SEAL*

What I would be trying to do is say everything with any of the the above keywords in the description go in one section of the table (1 repeat region), anything that doesn't have those key words goes in another section of the table (second repeat region in the same table).

[TomU]

I know you're not excited about it, but I still think repeat region relations are the cleaner solution.  Everything is contained in one place, the're very easy to write, and you don't have to make any changes to the existing parts or assemblies.  @MartinHanak gave a good example of how to do this here.  Let me know if you need an example created for your actual conditions.

[LawrenceS]

I was going to try and use the relations but then I remember why I abandoned it.  It gets much more complicated trying to handle wild cards.  E.g. *P*SEAL.  I think it could be done using 2 different searches then comparing where they occur relative to one another, then returning a result based on this.  However this would have to be done for each criteria and I think can get complicated fast.