Future of iFeature support

[guilloryt]

Morning,

We recently upgraded to Inventor 2018 from Inventor 2014. To date our design team has leverage iFeatures quite heavily and see it as an essential design technique that provides extemely high degree of efficiency/consistency.

In recent meetings, we have been having discussions on how we might be able to better leverage iFeatures in our mfg processes with cam automation. During the last sesssion one individual suggested that Autodesk may be considering depreciating support for iFeatures.

Would anyone have any guidance on what future plans Autodesk has for iFeatures to ...  possibly depreciate it or alternatively have they introduced any enhancements since 2014 ... or planning some improvements for the future?

Appreciate any guidance that you can offer.

Thanks

Tony

[YuhanZhang]

Hi Tony,

For iFeature, we will continue to maintain this feature, I don't know any plan to depreciate it yet. As you are using iFeature heavily and you upgraded to Inventor 2018, have you found any problem with it? Or have you any new requirements for it?

[guilloryt]

Afternoon Rocky,

No issues with using iFeatures in 2018 that I know of personally. Only one senior mgr mentioned he had heard some comment that iFeatures may be depreciated. So I felt compelled to post for more details.

We are engaged in a major Corporate level effort to automate the generation of both the Inventor models and also downstream Cam mfg processes using those models.

Currently, we have successfully developed a custom .Net Inventor API app (something like an advanced iPart process) that we call FOP (Family of Parts) to generated member models from a master design. 

The simple fact that we are generating member Cad models all sharing a common set of brep top refkeys, allows us to achieve a high level of Cam automation since the Cam system has quite good support to retain details of digitizes made on the brep refkeys. 

However the engineering design team is also using iFeatures for many parts.  They are creating the iFeature each one at a time and are not using table driven iFeatures. Typically they will manually insert/place each iFeature into the part model each time. The result is that the refkeys for iFeatures are not consistent between any two members.

Would you know if it is possible to somehow place an iFeature in a master design and then to parametrically drive the underlying geometry/sketches for the features created by the iFeature? 

Has any new support been added for iFeatures since 2014?

Thanks for quick response

Tony

[YuhanZhang]

Hi Tony,

We do have iFeature APIs to edit the placed iFeature object in a document, if you can provide a simple sample data and let me know which parameters you want to update, I can check how API can help you to improve the efficiency.

From API side, I don't think we have big changes for iFeature APIs since Inventor 2014, if your project needs iFeature UI and API functions to enhance please let us know.

[guilloryt]

Rocky,

It may be a bit complex to try and communicate clearly by email.. but will try.

Our app is similar to iParts but has key custom methods to allow us to also switch out any derived components, change hole/threads properties and generate drawings, Basically a table of parameters that we can generate family member models from a single master model. I

n the app we have a custom parameter type that can be defined easily by the user for each Hole feature. We use this custom hole/thread parameter object to change hole definitions for each member part when we generate member models. In the UI we have custom editors/methods that provide similar UI experience for user to easily define the hole/thread props as needed for each part.

After seeing your previous post I took another look at iFeatures, found several examples on the web and see our App can as is easily drive the iFeature parameters of the master model and use those parameters to adjust geometrical dimensions. This looks very promising for our use. To me this is bit of surprise how easy it is. I am on the mfg side and really have not spent much time with design of iFeatures.

However the majority of iFeatures our eng dept use are bolt circle patterns around bores/pockets. Controlling the dimensions of pockets/bores would be easy enough I think.

But we would have an issue with fully supporting driving place iFeatures from a table since  we would also need to be able to modify the Hole/Thread definition of the holes in the placed iFeature?

Is there some API method/mechanism that I can use to access/modify the hole/thread properties of a placed iFeature?

Thanks

Tony

[guilloryt]

Rocky,

In a nutshell, with iFeatures placed in our master model are there any api methods we can use..

1. To get a reference to the hole/thread properties contained in each placed iFeature to retrieve/evaluate the "default/current"  Hole/Thread properties.
2. Then at runtime based replace the hole/thread properties in the placed ifeatures with new/modified TapInfo/ThreadInfo object.

Thanks

Tony

[YuhanZhang]

Hi Tony,

For #1 question, you can firstly in UI create an iFeature definition(.ide file) for HoleFeature and check which parameters are  supported in the iFeature definition, then you can query and edit the parameters after placing it.

For #2 question, after an iFeature is placed, you can only edit it using the parameters(iFeatureInputs), you can't edit it using the TapInfo/ThreadInfo object directly because the iFeature is not recognized as a HoleFeature even the iFeature is extracted from a HoleFeature.

Hope this clears. If you have any more requirements please let me know.

[guilloryt]

Can you offer options I can use to specify the hole/thread properties after it is placed iFeature?

Only way I see I can do it is to create a table driven iFeature and add the columns for the hole/threads to the table.  When I create the table automatically all the named parameters are added as columns in the table. I am not able to remove specific parameter columns from the table designer.

 Possibly I am not understanding how the table is supposed to be used. But appears to use it, I would have to specify all combinations of dimensional parameters and hole/threads in the table prior to placement?

Are there techniques I can use to have all dimensional parameters and hole/thread props available to edit in the model after the iFeature is placed?

Thanks

[YuhanZhang]

For a non-table driven iFeature you can get the info using the iFeatureDefinition.iFeatureInputs and change the values, below VBA code can print some of the info if you open a part with non-table driven iFeature in it:

Sub getiFeatureInfo()
    Dim oDoc As PartDocument
    Set oDoc = ThisApplication.ActiveDocument

    Dim oiFea As iFeature
    Set oiFea = oDoc.ComponentDefinition.Features.iFeatures(1)
    
    Dim oiFeatureDef As iFeatureDefinition
    Set oiFeatureDef = oiFea.iFeatureDefinition
    
    If Not (oiFeatureDef.IsTableDriven) Then
        Dim oInput As iFeatureInput
        For Each oInput In oiFeatureDef.iFeatureInputs
            If oInput.Type = kiFeatureEntityInputObject Then
                Debug.Print "-----Entity Input------"
                Debug.Print oInput.Name
                Debug.Print oInput.Prompt
                
                Dim oEntityInput As iFeatureEntityInput
                Set oEntityInput = oInput
                Debug.Print "Entity input type: " & oEntityInput.EntityType
            ElseIf oInput.Type = kiFeatureParameterInputObject Then
                Debug.Print "-----Parameter Input------"
                Debug.Print oInput.Name
                Debug.Print oInput.Prompt
                
                Dim oParamInput As iFeatureParameterInput
                Set oParamInput = oInput
                Debug.Print "Parameter expression:" & oParamInput.Expression
            ElseIf oInput.Type = kiFeatureSketchPlaneInputObject Then
                Debug.Print "-----SketchPlane Input------"
                Debug.Print oInput.Name
                Debug.Print oInput.Prompt
                
                Dim oSketchPlaneInput As iFeatureSketchPlaneInput
                Set oSketchPlaneInput = oInput
            ElseIf oInput.Type = kiFeatureVectorInputObject Then
                Debug.Print "-----Vector Input------"
                Debug.Print oInput.Name
                Debug.Print oInput.Prompt
                
                Dim oVectorInput As iFeatureVectorInput
                Set oVectorInput = oInput
 
            ElseIf oInput.Type = kiFeatureWorkPlaneInputObject Then
                Debug.Print "-----WorkPlane Input------"
                Debug.Print oInput.Name
                Debug.Print oInput.Prompt
                
                Dim oWPInput As iFeatureWorkPlaneInput
                Set oWPInput = oInput
            End If
        Next
    End If
End Sub

You can map the iFeatureInput to the HoleFeature's dimensions to see if they can satisfy your requirements.

For a table driven iFeature, you can't directly change the iFeatureInputs, but only change the iFeatureTableRow, also here is a VBA sample to do it, you can open a part with a table driven iFeature in it and run the code to check the result:

Sub switchiFeatureTableRowSample()
    Dim oDoc As PartDocument
    Set oDoc = ThisApplication.ActiveDocument

    Dim oiFea As iFeature
    Set oiFea = oDoc.ComponentDefinition.Features.iFeatures(1)
    
    Dim oiFeatureDef As iFeatureDefinition
    Set oiFeatureDef = oiFea.iFeatureDefinition
    
    If oiFeatureDef.IsTableDriven Then
        Dim oTableRow As iFeatureTableRow
        For Each oTableRow In oiFeatureDef.iFeatureTable.iFeatureTableRows
            If Not (oiFeatureDef.ActiveTableRow Is oTableRow) Then
                oiFeatureDef.ActiveTableRow = oTableRow
                Exit For
            End If
        Next
    End If
End Sub

Hope above clears and helps.

[guilloryt]

Morning Rocky,

The examples you provided will be very helpful. However, I do not see any methods I could use to modify the hole/threads of an existing .ide thru the api.

Is it possible using the api to get a reference to the hole/threads directly in the existing .ide and update/modify them?

Is there any documentation on the structure and methods available with iFeatures?

Thanks

Tony

[chandra.shekar.g]

Hi @guilloryt,

Acceptable iFeature input in iFeatureDefinition are listed below.

iFeatureEntityInput -> The iFeatureEntityInput object represents the positional information of an iFeature. The iFeatureEntityInput object is used both to describe and specify the geometry necessary for the placement of an iFeature.

iFeatureParameterInput -> The iFeatureParameterInput object contains the information associated with a parameter of an iFeature.

iFeatureSketchPlaneInput -> The iFeatureSketchPlaneInput object represents the sketch plane input information of an iFeature. The iFeatureSketchPlaneInput object is used specify the geometry's and other data necessary for the sketch plane input of an iFeature.

iFeatureVectorInput  -> The iFeatureVectorInput object represents the vector input information of an iFeature.

iFeatureWorkPlaneInput -> The iFeatureWorkPlaneInput object represents the work plane input information of an iFeature.

Thanks and regards,

[guilloryt]

Morning Chandra,

Appreciate the response. The items you list appear to be some of the standard methods available to manipulate iFeatures.

I am asking if anyone knows of any alternative techniques that are possible?  

Table driven iFeatures seems interesting, but in my testing appears somewhat limited for our use.

Certainly with a Table driven iFeature we could specify Hole/Thread properties.

• But in testing found that once you define the Table, automatically all of the input parameters are added to the table. Which would mean we would have to populate the table with every combination of dimensional input parameters and hole/thread properties needed and in many cases this would not be reasonable.
• The utility of the Table would be bit better for us if we could simply add only the Hole/Thread props to the Table and have the Input Parameters behave same as before we defined the table. In that way we could select the Table row containing the correct threads, then in the .ipt modify the iFeature Input Parameters as needed.
• The best approach for our processes would be if after placement of the iFeature we could modify any input parameter and/or Hole/Thread properties.

Ideally, we would like to get a reference to holes/threads contained within the place iFeature and update it with a new ThreadInfo object? Does anyone know definitively if this is can be accomplished?

Alternatively, would it be possible somehow to modify the cell values in the placed iFeature table?

Reason for asking, in early days we used iPart tables for some of our Cad automation. We used iParts mainly to leverage support for ft suppression, changing threads, etc along with an external data store. The way we used it was to reference/open the internal iPart excel sheet (which in our process only had one default row) and modify the values of cells as needed, then triggered an update. But seeing that iFeatue tables and iPart tables are different animals for sure.

Thanks

Tony

[chandra.shekar.g]

Hi @guilloryt,

@YuhanZhang already mentioned about possibility of TapInfo/ThreadInfo object in iFeature.

"After an iFeature is placed, you can only edit it using the parameters(iFeatureInputs), you can't edit it using the TapInfo/ThreadInfo object directly because

the iFeature is not recognized as a HoleFeature even the iFeature is extracted from a HoleFeature."

You can add this wish list at idea station using below link. Based on the votes for this idea, it may be considered in Inventor future releases.

https://forums.autodesk.com/t5/inventor-ideas/idb-p/v1232/tab/most-recent

Thanks and regards,

[guilloryt]

Morning Chandra,

Really appreciate the info and your time.

For certain we will submit this item as an enhancement request.

As an interim approach would it be possible to switch out the iFeature reference file?

In our automation tools, we support switching the reference file for derived components using oFileDescrptr.ReplaceReference. 

Which brings the question to mind.... Would the Inventor API have any similar methods as ReplaceReference that work with iFeatures  which we could use to switch the iFeature definition after it has been placed?

Thanks

Tony

[YuhanZhang]

Hi Tony,

After an iFeautre is placed, then what we can do is just to edit the iFeature(change the inputs) but can't switch the definition(.ide) file, so if your requirement is to 'replace' an existing iFeature, you need to delete the existing iFeature and place a new one. Usually different iFeature definition(.ide) files have different inputs(geometry to locate the iFeature, parameters to define the shape etc.), so just 'replace' an iFeature definition for an existing iFeature does not make sense. So currently the workaround for your requirement is just delete the existing one and place the new one. Hope it clears.

[gerald_engineers]

Over 7 years later and with the background that iParts are kind of deprecated due to ModelStates:

Does anybody know about the future of iFeatures? Is there now the risk for deprecation?