Formatting Flat Pattern Extents iProperty?

[fredform]

Hi,

So i found this idea post and was at first very happy to have discovered that there is a clean way to map the flat pattern extents to an iproperty, that will update automatically without relying on ilogic or crude event triggers.

Unfortunately, this was short lived as there seems to be no way to format this iprop?

The "=<SHEET METAL LENGTH>" relies on document Modeling Display Settings with no way of switching off the unit string. Pushing these iprop values with 3 decimal places to the parts list will drive both our production team and my own OCD crazy. Am I out of luck here or is there something I'm missing?

I feel like if the flat pattern extents values would have instead been exposed as parameters in the flat pattern view we could export/format them just like any parameter (even made calculations if needed).

Best,

Fredrik

[Radwan-Almsora]

You are completely right that the standard iProperty expression method (=<SHEET METAL LENGTH>) behaves as a hardcoded string formatting workaround, pulling units directly from the raw modeling environment options without built-in options to trim decimal points or drop unit strings.

However, you are not out of luck. You can achieve perfectly clean numbers in your parts list by utilizing standard parameters instead.Why Parameters Exist for ThisThe flat pattern dimensions actually are automatically exposed as document parameters in Autodesk Inventor, but they only populate once a flat pattern has been generated for the sheet metal component.

By default, Inventor generates three hidden parameter dimensions for a flat pattern:FlatPatternLengthFlatPatternWidthFlatPatternArea

Step-by-Step Formatting WorkaroundYou can bypass the limited iProperty expression entirely and format these variables using standard parameter export settings

Open Parameters: Click the \(\mathbfit{f}_{\mathbfit{x}}\) Parameters button on the Ribbon.Find Flat Pattern Parameters: Scroll down to the bottom of the table to locate FlatPatternLength and FlatPatternWidth.Check Export: Check the box under the Export Parameter column for both values. This exposes them as custom user properties.

Format the Output: Right-click on the equation or parameter row and select Custom Property Format.

Adjust Display Rules:Change the property type to Number.Set your desired decimal Precision (e.g., 0 or 0.1).Uncheck Show Unit String to clean up the "mm" designation.

Update Your Parts List: Map these newly formatted exported custom properties into your drawing BOM/Parts list style columns.

If you want to save time across your department, you can configure these custom properties directly inside your Sheet Metal .ipt templates. They will remain inactive on new parts but will automatically activate, format correctly, and populate the moment a designer creates a flat pattern layout.

I belive this was answered here: 

How to remove the mass unit string in the Inventor drawing document

Determine the unit of the value of the iLogic function SheetMetal.FlatExtentsArea in Inventor

SheetMetal.FlatExtentsLength and SheetMetal.FlatExtentsWidth return values in centimeters instead of... 

don't forget to click the Accept Solution button

[fredform]

Hi Radwan,

As far as I can tell there are no such parameters (FlatPatternLength / FlatPatternWidth), neither in the standard Sheet Metal modeling environment or the Flat Pattern itself - Can you attach a screenshot showing me how you found them?

This is all I got in the form of Sheet Metal parameters

Parameters in modeling environment:

Parameters in Flat Pattern:

I'm using Inventor 2025.

[WCrihfield]

There are actually already 'standard' built-in iProperties for both types of values present in every document, but they will obviously not have valid values in any other type of document than a sheet metal part, and may not even get valid values assigned to some of them within a sheet metal part until there is actually a flat pattern in the part to get those values from.  They can be found using a relatively simple code routine that iterates through every Property in every PropertySet in the document while logging their Index numbers, names, PropID's, and TypeName of their values.  I will attach a PDF I published a few years ago, exported from Excel, where I wrote that type of data into from a code routine, then formatted further manually, to use as a handy quick reference.  The first 4 PropertySets will always exist in every document.  The first 3 PropertySets are all populated with what I call 'standard' iProperties, because they are always present in every document, whether they have valid values or not.  Many are ReadOnly, but obviously some are Read/Write.  And there are several different value types, including 'IPictureDisp', which is used in 2 places to store images for internal use.  Anyways, there 2 groups of iProperties related to sheet metal sizes or flat pattern extents, both of which are within the third PropertySet named "Design Tracking Properties".  They are as follows:

Index = 44 ; Name = Flat Pattern Width ; DisplayName = FlatPatternExtentsWidth ; PropID = 63 ; Description = Flat Pattern Width in cm ; Value Type = Double
Index = 45 ; Name = Flat Pattern Length ; DisplayName = FlatPatternExtentsLength ; PropID = 64 ; Description = Flat Pattern Length in cm ; Value Type = Double
Index = 46 ; Name = Flat Pattern Area ; DisplayName = FlatPatternExtentsArea ; PropID = 65 ; Description = Flat Pattern Area in cm^2 ; Value Type = Double

Index = 47 ; Name = Sheet Metal Rule ; DisplayName = SheetMetalRule ; PropID = 66 ; Description = name of sheet metal rule used ; Value Type = String

Index = 49 ; Name = Sheet Metal Width ; DisplayName = SheetMetalWidth ; PropID = 68 ; Description = Flat Pattern Width in Document Units ; Value Type = String
Index = 50 ; Name = Sheet Metal Length ; DisplayName = SheetMetalLength ; PropID = 69 ; Description = Flat Pattern Length in Document Units ; Value Type = String
Index = 51 ; Name = Sheet Metal Area ; DisplayName = SheetMetalArea ; PropID = 70 ; Description = Flat Pattern Area in Document Units ; Value Type = String

So, you can use the ones with 'Flat Pattern' in their name, which have a Double type value, then just convert their values from centimeters to whatever other unit you prefer, if necessary.  You could have a stable set of custom iProperties to hold onto their converted values that are formatted the way you want.

[fredform]

Hi Wesley! Thank you for the document, this is a very good resource that for sure will come in handy! But as for my problem, I don't really see how I can use these properties to map the FlatPatternExtents without setting up an event trigger to watch for any change in geometry/parameters? I can make an ilogic rule that directly reference these propertysets and properties but what will actually trigger it?

My concern is that adding an iLogic rule to our Sheet Metal template and triggering it via Event Triggers could create problems down the road. I'm worried Inventor might unnecessarily mark released files as modified ("dirty"), even when nothing meaningful has changed. I also wonder about the performance impact of having hundreds of sheet metal parts all running the rule at the same time.

While I could make an external rule or run a rule from the top level assembly I feel that this also becomes kinda crude and messy. Should users have to remember to run it before creating the drawing or BOM? If they forget, incorrect values could end up in the parts list. Ideally, each sheet metal part would have a direct parametric link between its flat pattern dimensions and the iProperties used in drawings/BOMs—no code or event triggers required. <SHEET METAL LENGTH> almost solves this, but the lack of formatting options makes it fall just short, seems like a missed opportunity to me.

[WCrihfield]

You are right about it being a tricky situation, as far as using iLogic rules & event triggers to keep those types of custom values accurate.  I'm sure the scenario is a bit different at each company, but for us, when we save (most) new documents (created from one of our many templates), we run an external rule on the 'before save' event that asks a series of questions.  These are just for 'clean-up' tasks, like optionally deleting inactive custom ModelStates, suppressed features, unused sketches, and such.  But usually the last two questions are, "Do you want to suppress all internal iLogic rules?", and then "Do you want to delete all iLogic 'Event Triggers' settings for this Document?".  If the user chooses yes, it runs the appropriate rule that simply iterates through all internal iLogic rules and suppresses them...&/or deletes the special, hidden PropertySet containing the settings for the 'This Document' portion of the iLogic Event Triggers.  We generally do not (or at least try not to) leave any iLogic stuff 'live' when save a document for the final time, because we no longer want anything to change in it.  We also never leave anything 'Adaptive', for the same reasons.

For some odd reason, I briefly though that after we add a column to the BOM for a custom iProperty that represents a numerical value, we had options or settings in a context menu somewhere that would allow us to format it (specify precision, and even alternate units), but I think I was thinking about the 'Format Column' functionality when manually editing a PartsList in a drawing, instead of a true assembly BOM.  If/when I need to show that type of info in a drawing, I also tend to use a custom code-based solution (either on-demand or 'triggered', depending on the situation), instead of relying on those iProperties.  It measures things, creates or updates UserParameters, exposes them as custom properties, sets their formatting, and such.  But that's probably just because I interact with code a lot everyday, and like having more control over such things.  I would definitely like to see those built-in iProperties be a bit more flexible, as far as formatting &/or units, but at the same time, I know better than to hold my breath for it to get changed.