replacement of parts presenting family table in summer

[Tekkasoft]

hi guys and I haven't been writing for a long time, but I see you're always there, ready for everything.
I'd like to have a problem that I haven't been able to solve yet.

for example I have a "pezzo.prt" file that has a family table whose lines are also family table (insomma family table innestate).
when I create a set and insert the piece.prt into a particular configuration (guided by the family table)
I obviously have no problem.
if, however, in the relationships of the assieme I use the lookup_inst function (opportunely inserted in the pro/program file to cause the substitution of the "pezzo.prt" with its relative variant according to the parameters of the function) with more selection parameters and where the second belongs to a family table grafted, then the verification of the relationship does not go to good end.
In summary it seems that the lookup_inst function accepts more parameters but only if found in the first level of the family table.

Did any of you have this problem and solve it?
I trust you. . .

 

[AMinati]

I had the same problem. You can solve it by annihilating the "lookup_inst" function, i.e. first search the main level, then search within the subfamily table so found, but I found the very slender and difficult solution if you don't know what level you need to stop. I have dribbled the problem by appointing the various instances of the various levels appropriately and "build" the name of the instance to search through some parameters. in this mode pro/program goes safely (if the instance exists)

hoping to have been sufficiently clear

cordial greetings

aminati

 

[Tekkasoft]

Hi aminati
Thanks for the answer.
I didn't understand, though, how do you do recurrence research? Could you write an example?
greetings