Being Inventive

You’d like to see the volumes for all of the members of an iPart at once

This came up recently with a customer where they’d like to see all of the different volumes at one time for an iPart’s members. This could be used for mass or other property. The only limitation is your creativity with it.

The scope is: we want to get the volumes for all the elaborated members of an iPart factory at one time and this rule does that when we add a custom “Volume” parameter to the iPart table, trigger the rule to fire on any parameter change and edit the table via a spreadsheet. Problem: Cubic inches (or any other distance type) doesn’t have a predefined enum.  So we need to use a workaround and build up a string that defines the desired units.  There is the issue of the unit type changing from document to document so we won’t want to hard-code the unit value but instead be able to set it dynamically. We also want to make sure that, if the parameter exists, we’re not duplicating it and it’s correct for the current member. Here’s how the code looks:

'Dimension a variable for user paramaters

oMyParameter= _

ThisApplication.ActiveDocument.ComponentDefinition.Parameters.UserParameters

'test to see if the parameter is already there and, if so, that it matches the correct

'volume of the member using the embedded if/then/end if block

Dim param As Parameter

   On Error Resume Next

   param = oMyParameter.Item("Volume")

   If Parameter("Volume") <> iProperties.Volume Then

   Parameter("Volume") = iProperties.Volume

   End If

   On Error Goto 0

'If it doesn't exist, create it so that we can add it to the table. We have to concatenate

'Units of measure as a string b/c there is no enum for ^3 inches but no problem, it still

'can be had and dynamic the way we'll set it up

If param Is Nothing Then

'Get the document's units of meausure, comcatenate that with a volumetric string of ^3

'in order to show the units as volume units

Dim uom As UnitsOfMeasure = ThisApplication.ActiveDocument.UnitsOfMeasure

Dim volUnits As String = uom.GetStringFromType(uom.LengthUnits) & "^3"

'Set a parameter equal to the current properties volume adding the units of

'measure in volume units from above

Dim Vol = iProperties.Volume

oParameter=oMyParameter.AddByExpression("Volume", Vol, volUnits)

End If

iLogicVb.UpdateWhenDone = True

‘Then, once this rule is run, it’s just a matter of adding the new “Volume” user

‘parameter column (from other) we’ve created to our iPart table – just once.

I’m sure there are probably other ways to do it but it really works out pretty well with very little actual code. As a note, when you change members, you’ll get a dialog that you should answer yes to, that states the values in the active row do not match. It is asking you if you'd like to update the table with the new value before continuing. Answering yes will reflect the volume for the new member's cell value in the table in both the iPart table in Inventor as well as in the Excel spreadsheet.

Once they've all been activated and the dialogs have been answered "Yes", your values will be reflected in the table/spreadsheet.

 

-Daren

 (1st line of code edited with underscore to fit in the provided space)

Adding Multiple Components in iAssembly Table in batch mode

You want to convert your assembly in an iAssembly.

You have many components that need to be configured for Include/Exclude.

If you don’t want adding them one by one in iAssembly table, you can try the steps below.

• Convert the assembly to iAssembly and click OK for closing the iAssembly table

• In the Manage tab, Author, switch to “Edit Member Scope”

• Select multiple components in the assembly browser, right click and select “Exclude”

The columns corresponding to the selected components will be added into iAssembly table.

Then, you can switch back to “Edit Factory Scope” and Edit the iAssembly table for making the adjustments.

Ale

Updating assembly after changing material or density in iPart

There is something weird going on when changing the material of an iPart after it has been consumed in an assembly.

I have seen some heated discussions recently on this subject in the newsgroup and this triggered my attention.

You can argue that it is a defect and I entered it as such in our defect database. But in the meantime let's explain the behavior and what to pay attention to.

Here is the symptom of the problem: you will get a wrong assembly BOM after changing material properties in an iPart.

For discussion sake let's assume you changed the density from an erroneous value of 10 g/cm^3 to a more plausible value of 5 g/cm^3.

You will see the following (correct) iProperties of the individual iPart member

But on the other hand, the assembly BOM continuous to report the erroneous (double) mass value for the iPart:

How come? Here is the detailed workflow that can get you into this situation.

1. Create an iPart with some members

2. Save the iPart

3. Start a new assembly

4. Insert an iPart member in the assembly

5. Save and close the assembly

6. Open the iPart factory and make another material active (or change one of the properties of the active material e.g. change the density)

7. Save and close the iPart

When you reopen the assembly, it is not being flagged as being dirty and the original material or the origin material properties continue being used at the assembly level.

The key trick to avoid this situation is to do something extra in step 7 when you save your modified iPart.

If you include a Manage > Rebuild All step before saving the iPart, your assembly will be flagged as being dirty on open and the new or modified material is correctly used in the assembly.

To play it entirely safe , I would even suggest to do a "Rebuild All " , followed by an "Update mass properties" and finally shift select all iPart members and use the "Generate files" context menu to regenerate the iPart members on disk.

Too late for me personally but hopefully this will save the younger generation from some undesirable premature grey hairs.

Bob

Adding a little class to threaded iParts

You’ve made an iPart with a hole and thread feature that can change sizes between ANSI Unified, Metric, etc. and added the thread information to the table so the part will update and the thread specification changes based on the thread. But when you change to from one member to another with a different standard, you get the following warning:

You’ve got the right thread designation and type, the tap drill size is correct or at least close so you shouldn’t be seeing this warning, right? Yes, with a catch. After the switch you’ll also see the thread warning in the browser:

So you check on the thread specification and change it to the correct designation. Next you go to edit the table to double check and are faced with the following warning:

If you choose “Yes” you’ll get the warning when changing back to a different thread type and it may even change all your thread types in the table. So what can you do to get it to recognize the thread specification? Add the thread class to the table. For instance, if it’s an ANSI English thread, you can change the class to “2B” and use “6H” for metric holes. If you’ve got a number of rows, you can edit in Excel and use the drag copy to set all the values to the appropriate rows.

Now, once you verify and click “OK”, you’ll notice no more warnings as the thread specification switches as you change members.

I hope that’s helpful. Happy New Year!

-Daren

iPart Origin work features visibility

You have created an ipart and purposely left some origin work plane and axis displayed for alignment purposes upon insertion, but, when you insert an ipart member into a new assembly the work feature do not display and the option to turn the  visibility on is not available.

This should not be a problem for positioning the ipart member in the assembly, because even if the Origin work features are not visible you are still able to select them in the browser for defining constraints.

By the way, if you want to display the Origin work features inserting the ipart member in the assembly you have three options.

1. Create an imate for each Origin work feature you want to display, selecting it.

Then, add the imates to the ipart table.

After that, inserting the ipart member in an assembly, the work features will be visible.

2. Create user work features which are coincident with the origin work features.

Then go to the "Work Features" tab on the iPart Author dialog, add a column to your iPart table for the new work features, and set the table values to "Include".

3. Define, at least one column in the iPart, as Custom Parameter Column.

In this way, the option to turn the ipart member origin work features visibility on will be available in the assembly environment.

Ale

Excel Starter and Inventor

In the Inventor 2012 System Requirements, we can read this concerning Excel:

…

Microsoft® Excel 2003 through 2010 for iFeatures, iParts, iAssemblies, thread customization, and spreadsheet-driven designs

…

There is however one exception to this system requirements paragraph that is not mentioned explicitly and we just found out about this exception via one of our beta testers: the free Microsoft product called "Microsoft Excel Starter" cannot be used with Inventor as a replacement for the full Microsoft Excel (which is of course not free).

The explanation is relatively simple.

Microsoft Excel Starter comes with the OEM version of  Microsoft Office 2010 (named Office Starter 2010) and gets installed as a "virtual application".

Because of this, the app does not register itself in the Windows registry.

And this means that Inventor cannot find Microsoft Excel Starter via the Windows registry and thus iParts/iAssemblies, iFeatures and threads will not function properly with Inventor.
You will have to upgrade to the full Excel product to make things work.

Conclusion: there is no free iLunch.

 

Adding iPart properties in text on a drawing

This one came up again the other day through a partner and it’s a little misleading in some parts of the workflow so I wanted to clear it up. When you have a drawing containing multiple versions of an iPart, you sometimes want to add text showing the version of the iPart instead of using a general table. No problem, I’ll just add text, choose the model property “Part Number” and change the “Component:” field to the version I want and it’ll add the text for that version you may be thinking:

But as soon as you place the text it shows a different version:

So what’s going on? The text is associated with the first-placed view of the version in the file and using that as its reference. So how do we get the text for the version we want? The best and easiest way to do this is click on the view you want the text associated with, start a sketch and add the text with the model property data that way. Then, it will be associated with that view and its Part Number property:

Happy Inventing,

Daren

How to handle this family of parts

You have a bunch of parts.

They all are similar, but have some different lengths that can range within an interval.

You want to be able to place these parts in your assemblies and get the correct parts list. 

Using a “normal” ipart is not an option, because the parts can differ of small length increments within the interval, and the ipart will end up with a very large number of rows.

The custom ipart seems like the best solution for this.

You can create an ipart with three rows and define the lengths columns as Custom Parameter Columns.

 

When you insert the ipart in the assembly, you can specify the desired values for the lengths.

 

By the way, if you want to include the length values in some iproperties of your parts, as, for instance the Part Number, this is not a solution, because, when you insert the part in the assembly, specifying the length values, the equation in the Part Number property field doesn’t update accordingly.

 

In this case, the solution is publishing the custom ipart in an user CC library, setting the lengths columns as key columns.

 

Then editing the Family Table, you can edit the Part Number column properties and set an expression as, for instance, the one in the image below.

 

So, when you need to insert the part in one assembly, you can do it from the Content Center, selecting the option “As Custom”, specifying the desired values for the lengths and saving the file in the desired location with the desired name.

 

The Part Number property of the file will be set correctly.

 

In case, later on, you need to edit the part you have published, you can open one member of the family with the command Open from Content Center and the option “As Custom”.

 

Make your changes and save the file.

Then, in the CC Editor, select the user library in the Library field, select the family, right-click, Replace Family Template, and select the file you have modified.

 

Ale

Tweaking generic tables

*** Update: per request of a reader I added dual unit and split header support for parts lists as well. The new macros are marked in red.

For some users, generic or general tables are an under-appreciated beast in Inventor.

Fig 1: Location of General table on the ribbon

Part of the reason could be that generic tables can morph into completely different type of tables, depending on what data you feed into them.

1. When you have no view selected, a generic table allows you to bring in an Excel or CSV file and do parts list work.
   Tip: it can be a good alternative for the regular parts list command when you are dealing with large assemblies.
   A parts list generated with a generic table will load much less data and consume less memory when working with LOD views in your drawing.
2. When you have a view of an iPart or iAssembly selected, the generic table allows you to document the various configurations in the iAssembly or iPart.

In this blog post I wanted to concentrate on the usage as explained in b) and more precisely what you can do to format the generic table to fit your needs.

I wanted to address two limitations of the table with just a couple of lines of VBA code.

Displaying dual units in a general table

Dimensions and hole notes have the capability of displaying dual units. However generic tables do not have that capability.
This problem was brought up recently in this newsgroup post.
How do you add a dual or alternate unit to one of the columns in your table? Take the example of the iPart with 3 members as shown in Fig 2

 

Fig 2: Simple iPart with corresponding general table

To add another unit to the table, copy and paste this text in a new VBA module in Inventor's ApplicationProject (typically called Default.ivb). When working with a parts list, use this text instead.

Change the line that says

    headertext = "Column 4"

To whatever the column header text is in the column you want to treat. In our example, I replace it with

    headertext = "LengthA"

Now select your table first and then run the macro called "dual_units_table".

The macro will look at the alternate unit used in the linear dimension style of your active drawing standard and use that unit as second unit with this as result

Fig 3: Same iPart general table with inches added as dual unit

Wrapping column headers in a general table

This problem was brought up in this newsgroup post.

What if the column header text in your table is getting too long and you want to wrap the header into multiple lines?

Inventor does not let you enter a hard carriage returns in the Format Column dialog unfortunately, as can be seen in Fig 4.

Fig 4: Long heading but no way to wrap it to the next line

A more realistic table can be seen in the picture below .
How do you go from an unwieldy wide and space wasting table like this

to a more concise table like this

Just copy and paste this text in a new VBA module in Inventor's ApplicationProject and run the macro called "SplitHeaderCustomTable". When working with a parts list, use this text and run the macro "SplitHeaderPartsListTable" instead.
The macro will look at your first generic table and treat it automatically, so no need to select anything.
It looks for any spaces in your header text and splits the text based on the spaces.

Tip: if you want to wrap the first 2 lines of your header only and leave the remainder of the header untouched, simply change

    Const max_wrap = 3

To

    Const max_wrap = 2

I used this technique to keep the string "Dia. A" on the same line as it contains a space and would otherwise be automatically split.

Enjoy!

Bob

 

 

Emboss text in an iPart

It does not always have to be grease, metal forming, plastic injection, FEA calculations here at the mechanical division of Autodesk. Sometimes we have a sweet tooth and start daydreaming about being in the chocolate business :-)

Now that I caught your attention, I would like to use the chocolate industry as an excuse to discuss the problem of engraving or embossing the part number on a series of parts.
There have been heated discussions in the past about this topic on the newsgroups, here is just an example of such a discussion.
Each part in the series has to have a different  a different part number of course.
For simplicity sake, we assume that we use the part number as the text for the engraving and that it can be found in a sketch called "Engraving".

Note: all Inventor sample parts downloadable from this article are in 2012 format although everything explained here is valid for earlier versions as well, except for Solution 3.

 Figure 1 : family of parts with different emboss text

Obstacles

The first obstacle is that sketch text CANNOT be used as a variable in an iPart table.
The second obstacle is that although you can create a user parameter of the type text  or a custom iProperty of the type text, neither of these can be used as such in a sketch text.
Sketch text only allows the use of static texts or parameters with numeric values.
And as you might understand, static text does not really help when you want to  to create a series of parts :-(

I envisioned to use a macro or iLogic rule to copy the part number in a sketch text.
However when creating a family of parts that almost inevitably leads us to the use of iParts.
And here we stumble on a third obstacle: macros and iLogic rules automatically get expelled from iPart members :-( 

So the only place to safely store and run macros or rules is in the iPart factory itself.

The iPart members that get generated can thus have different engravings as long as the engravings are created by a macro/rule in the iPart factory BEFORE the iPart members get created. Here are three possible solutions.

Solution 1 : iPart + Excel + VBA

If you have a small family of parts, you could use a regular iPart and include all embosses in the ipart factory  and suppress the embosses you don't need in a particular ipart member.

You can decide to change the text in each emboss manually. Solution 1 is handy if you want to change all emboss texts from a central location, in this case I use Excel as that central location. A single linked Excel spreadsheet defines the text and in which emboss sketch it goes. It assumes that only one spreadsheet is linked into the ipt (the name is unimportant) and a single "dummy" text per sketch is embossed.

Pros: preview is available, use of familiar iPart technique
Cons: complex, needs programming although the code is quite reusable for other cases, extra file needed (Excel), complexer modeling, larger file size, not suited for larger families of parts

Putting it in action

Download and unzip the Engraving1.zip file.
Open the Engraving1.ipt file and simply run the macro called "Emboss_with_text_from_Excel".
After that you can activate each iPart member in the table to see if the results are as expected.

Click here to inspect the VBA macro

Note: the code only works if the Excel spreadsheet is linked into the part (not embedded) and the second condition is that in the VBA editor the Excel object library is loaded via the Tools > References menu.

 

Here is how I have set up the linked spreadsheet called "Engraving.xls"

 

Here is how the iPart is set up. To make the iPart table and the spreadsheet communicate correctly with each other, I made sure that my naming conventions for the features made sense.

 

As an example: the 3rd member in the table uses Emboss3 (all other embosses are suppressed).
Emboss3 uses sketch Engraving3 which on its turn uses the text "Leonidas 100 gr" as can be seen in the spreadsheet etc

The other advantage of Solution 1 is that it allows you to decide in which sketch the emboss text needs to go. This is necessary because every emboss will need to use a separate sketch to avoid confusion.

Solution 2 : iPart + VBA

This solution uses an iPart and a macro to generate members while stripping out the iPart table from the members to prevent wrong  information from being introduced in the members at a later stage.

Pros: familiar iPart technique, code is reusable in other cases, solution valid for all releases, suited for larger families of parts, generates all variations with a single command,
Cons: relatively complex, needs programming + iPart, no preview (iPart factory is not able to show the resulting engraving part)

Putting it in action
Open Engraving2.ipt
Run the macro called " ipart_member_generation"
After the macro runs succesfully, you will see 3 member files on disk with the correct part numbers as determined in the iPart table (Leonidas 100 gr.ipt, Godiva 250 gr.ipt, Neuhaus 500 gr.ipt).
The part number is also used for the engraving.

The macro automatically removes the table in the iPart members to always ensure a correct but static part number text. If the factory changes, simply rerun the macro to regenerate all members.

Click here to inspect the VBA macro 

Solution 3: iLogic

With the advent of forms in iLogic since release 2012, this is probably the simplest method.
I used 3 simple iLogic rules and 1 iLogic form to drive the different engravings plus a couple of parameters.

The only set-up that needs to be done is to create a multi-value text parameter that defines the engraved text and also the file name. I called that parameter "boxtype" and it contains three values.

 

Pros: simple solution , rules can be modified quite easily for  other cases, suited for larger families of parts
Cons: solution only valid for R2012 (due to the use of forms)

Putting it in action
Open part called Engraving3.ipt.
It has 3 rules and a form included in the part. Just run the form.
The rules allow you to set the box overall size, change the engraved text and save a copy of the file to a  new file name in the workspace.  

Rule 1: Update size values
This rule simply adjusts the size parameters depending on the value of the boxtype

boxtypetext = Parameter.Param("boxtype")
If  boxtypetext.Value ="Neuhaus 500 gr"  Then
   d0 = 150 mm
   d1 = 70 mm
   d2 = 50 mm
Else If boxtypetext.Value = "Goodyear 250 gr" Then
   d0 = 110 mm
   d1 = 70 mm
   d2 = 50 mm
Else If boxtypetext.Value ="Leonidas 100 gr" Then
   d0 = 100 mm
   d1 = 30 mm
   d2 = 25 mm
|End If

Rule 2: Change engraving and size
This rule changes the engraving by using the value of the boxtype text. I use an Arial 1 pt font.
I also run Rule 1 to make sure that the dimensions are up to date prior to changing the engraving.

iLogicVb.RunRule("Update size values")
boxtypetext = Parameter.Param("boxtype")
Dim odoc AsPartDocument
odoc = ThisApplication.ActiveDocument
Dim osketch As Sketch
osketch =odoc.ComponentDefinition.Sketches.Item("Engraving")
osketch.TextBoxes.Item(1).FormattedText ="<StyleOverride Font='ARIAL' FontSize='1'>"+boxtypetext.Value+"</StyleOverride>"
odoc.Update

Rule3: Save file as copy
This rule saves the results out to disk in the workspace and uses the boxtype text to compose the file name

You could ask yourself why I did not combine Rules 2 and 3. Well the save operation cannot happen in the same rule where a parameter change happens (this is a known limitation), hence why I had to create the extra rule for the save.

boxtypetext = Parameter.Param("boxtype")
Dim outputfile As String
outputfile = ThisApplication.FileLocations.Workspace +"\"+boxtypetext.Value +".ipt"
ThisDoc.Document.SaveAs (outputfile, True)  

Form:
I called it the "Chocolate box configurator" for lack of a better name :-)
The form allows you to select your configurations and preview the 3 size parameters before committing to the change.

 

The "Change engraving and size" and "Save file as copy" buttons correspond to the rules with the same name. The "Update" button corresponds to the Update size values rule.

The 3 size fields are read-only and are updated with the "Update" button after selecting a new boxtype.

I also removed the default "Done" button from the dialog and made sure that the "Change engraving and size" and the "Save file as copy" rules do not trigger automatically.
This way I have full control over when to update the engraving and when to create the file on disk.

Enjoy!
Bob