Table driven iFeatures -assistance

[G60Dub]

Hello all

I have a situation whereby I need to optionally compute or suppress geometry/features in an iFeature.   Whilst I am confident at creating iParts and iFeatures individually  I have, to date, never had to author a table driven iFeature.

I've had a look at the Inventor help regarding Table Driven iFeature and perhaps as its a Friday I cannot make head nor tail of the guidelines.   Are the any other examples out there that I can refer to?

To set the context of the questions above - basically I have a couple of iFeatures that I need to amalgamate - I have two different seal profiles (currently individual iFeatures) that I need to optionally drop onto the surface/entry point of a cavity iFeature.   I cannot drop the iFeatures separately into a part as the second placement fails - seal or cavity or vice versa.   So as such I need to make a cavity iFeature where I require the ability to select 3 possible sealing options on the suface - 2 different seal profiles and a third with no seal machining at all.

[G60Dub]

Okay I've figured out that I can set the feature properties to suppress the specific feature/s if I specify a zero value - This I can export to the iFeature to then control whether a feature appears or not.

The above solution is however, not verbose enough for my users - I need a Yes/No for the entire feature.  I tried setting a boolean true/false as a user parameter at the part level and then either setting the respective feature active or not in a small iLogic rule dependant on the True/False value but this doesn't export to an iFeature.

So... is there any mechanism whereby I can set a Yes/No Value in the initial feature parameters that allows the entire suppression of a feature from a Yes/No at an iFeature insertion? 

[johnsonshiue]

Hi! I believe "Suppress" or "Compute" should work too.

Many thanks!

[G60Dub]

Cant seem to get the Suppress/Compute to propagate through to the *.ide!

[johnsonshiue]

Hi! I am sorry I totally forgot that feature suppress/compute is not supported in table driven iFeature. What I proposed does not work any way. I am sorry for the confusion.

I am wondering if this would be a good workflow for you. Actually, you could consider using iPart instead. Think of iPart as a collection of geometry. You can build up the part in a way that it is like a tool. When you try to insert the feature, you simply derive the desirable iPart member as a body. You can use Direct Edit -> Move -> Body to relocate it. Then use Combine command to join or cut it. Would it work for you?

Many thanks!

[G60Dub]

I understand iParts pretty well but do not follow with regard to the workflow you propose.

In the meantime, I read that another member had a similar issue a number of years ago and they nailed with using conditional logic suppression of the mutually exclusive features: https://forums.autodesk.com/t5/inventor-forum/suppress-compute-in-a-table-driven-ifeature/td-p/34911...

I think this would work for me so I set the part to an iPart with three rows:

No top seal and two different top seal machining details

I then set the two top seal features as revolutions and set conditional logic to suppress one feature whilst the other is active, hence selecting the respective row successfully switches between; no seal detail, seal 1 and seal 2.

However, I'm still missing something obvious and simple as I'm assuming I need to have both revolve features un-suppressed at time of extraction to an iFeature...  So I'm almost there but overlooking something hilariously obvious with the conditional logic so I've attached the part here for peer review.

[johnsonshiue]

Hi! I believe the workflow discussed in the thread is kind of a hack. It uses revolve angle to control whether or not a revolve is done. It is not truly controlling feature suppress/compute within an iFeature. It may work in some cases but it may fail. I don't think you should use the workflow.

My point about using iPart is as a replacement for iFeature, when iFeature runs into limitations. Think of a part or an iPart as source of geometry. You can use iPart to generate variations of geometry (controlling features). Then you simply derive an iPart member of desirable geometry into the new part (as if you insert an iFeature). Then you can use Direct Edit -> Body -> Move to relocate the derived body. Lastly, use Combine command to join or cut the main body with the derived body.

I hope this makes more sense now.

Many thanks!

[G60Dub]

Hi Johnson

Many thanks for taking the time to reply to this.  I am however still unsure as to exactly what you refer to when you say 'Then you simply derive an iPart member of desirable geometry into the new part (as if you insert an iFeature). Then you can use Direct Edit -> Body -> Move to relocate the derived body. Lastly, use Combine command to join or cut the main body with the derived body.'   

Would you be kind enough to indulge me to elaborate/expand on the proposed workflow a bit more?

[johnsonshiue]

Hi! My proposed workflow is essentially treating iPart members as toolbodies. I assume you are familiar with Derive workflow. Think of Derive as a way to insert the feature (iPart member). You have a bunch of iPart members and each represents "features." Instead of inserting iFeature as feature, you derive the iPart member file as a new body. Once the body is derived, you can relocate it to wherever you want.

What release of Inventor are you on? I can create a simple example demonstrating the workflow.

Many thanks!

[G60Dub]

HI Johnson

An example would be warmly received.  We are using Inventor 2019 Pro (We always wait until a couple of service pack updates have been released prior to migrating to the next years release)

[johnsonshiue]

Hi! Attached is a simple proof of concept. I used an iPart factory to create three variations of tools. Next I derived each member tool to the block part as a solid body. Then I relocated the body and cut it using Combine. Please take a look and see if it may work better than iFeature.

iFeature is still powerful. But, when the features get complicated, the dependency may be hard to manage.

Many thanks!

[G60Dub]

Ah...  Now I understand 😊  Many thanks for taking the time to clarify.

Our default workflow typically uses generated work features to align iFeatures - Cavities, seal ring profiles, oring grooves etc. so that the position of linked/related features can be dynamically updated by amending the parent workfeatures allowing all dependant child features to dynamically update their position.  At a glance I cannot see how one would link the derived parts to parent workfeatures; can this be achieved or is one restricted to performing arbitrary moves only prior to a cut/combine? 

[johnsonshiue]

Hi! I don't think Derive workflows allow that. Derive essentially is like carrying over the geometry from the source to the new part. The object position is based on the coordinate system in the source.

I think for most cases, you can still use iFeatures. But, for more complicated tools, I find this Derive workflow works better and more reliably.

Many thanks!

[ricardogallegosdextre]

I know this is a bit late but I do this hiding the 0 value of the parameter behind an extra column used as key (this column is created in the *.ide file in the "Other" tab in the iFeature Author Table). In this field I write the combination of supressions. So for example if I have 4 possible supressions, I define 16 rows with the possibilities noted in the extra field. When inserting the ifeature, I just choose from the dropdown.

If I want to be able to edit a parameter, in each row I right click the corresponding cell and set it as "custom parameter cell". That way when choosing from the dropdown, only the needed parameters are shown to be modified.