Exploiting iMate bugs to achieve desired behaviour

[cadull_rb]

Using Inventor 2012, I have multiple composite iMates in an assembly with compatible definitions and would like to restrict matching to pairs with the same name. Unfortunately this doesn't seem possible (the order appears to be more important than the name).

I thought it would be nice to add a minimum offset limit since my composite mates do not fully constrain the components and they place on top of each other, making it difficult to check which mates are being applied. Unfortunately, when matched, the limit disappears and a fixed offset is applied.

Interestingly, the minimum offset limit must be the same for the iMates to be compatible, so I assign a unique limit value to one of the constraints in each matching composite pair. Now the iMates will only match as intended and I can use the place at all matching iMates option.

Hopefully this will be useful until iMates behave better, i.e. I hope a fix for the limits takes as long as an improvement to matching by name.

[johnsonshiue]

Hi! I assume you are using iMate Match List. Here is how it should work.

Part1:iMateA and iMateB

Part2:iMateC and iMateD

Assuming you would like to have iMateA to match iMateD, on the Match List of iMateA, you will need to add iMateD. Then when you place Part1 into an assembly containing Part2, iMateA will look for iMateD first. If iMateD is not present on any component in the assembly, it will try to match the next available iMate of the same type within Part2.

Please note that two iMates must be the same type (Mate or Angle, or Insert) with the same offset value in order to be matched.

If the above behavior is not consistent with what you are seeing, please provide an example and post it here or send it to me via email. I will take a look and see where the problem is.

Thanks!

[cadull_rb]

Please see the attached files that demonstrate the undesired behaviour. Each part has two composite iMates with compatible definitions. Rectangle has ShortSideComposite and LongSideComposite. Triangle has AngleSideComposite and LongSideComposite. The desired behaviour is that only LongSideComposite should match, but would at least expect it to match before any other pairing.

When placing in an assembly using the interactively place with iMates option, ShortSideComposite and AngleSideComposite match first. I am required to change the selected iMate for both parts before LongSideComposite matches.

Using the automatically generate iMates on place option, the LongSideComposite does match first, but I can only place one part at a time, cannot select where it goes (e.g. having two Rectangle parts and only want a Triangle on one of them) and it may also consume other compatible iMates that were intended for another part.

Changing the order of the iMate definitions will change the order of matches, but this is not useful as I will not necessarily be consuming all iMate definitions or adding parts to the assembly in the same order. The problem becomes harder to resolve as more parts with available iMates are added to an assembly, to the point where using normal assembly constraints is easier.

If we add a unique minimum offset limit to each composite, e.g. 1 mm for the ShortSide iMate, 2 mm for the LongSide iMate and 3 mm for the AngleSide iMate, then this value is discarded when matched and the desired behaviour is achieved. I'll leave this as an exercise to illustrate how painful it is to edit composite iMates.

[johnsonshiue]

Hi! Thanks for providing the example! Now I understand the confusion better. Unfortunately, the behavior you described is how I understand iMates work. It would be better if there is another option allowing Match List to work exclusively without attempting to match type in the interactive mode.

I will forward your request to the product team for further review.

Thanks!

[cadull_rb]

Thank you, such an option would help a lot. Given the long history of improvement requests for iMates, I really hope this area gets some attention.

For now I'll be able to use iMates effectively by using the exploit mentioned here and a bit of coding to promote unconsumed iMates in each assembly.