Persistent Unit Conversion Quirk in iLogic Parameters (Demonstration Included)

[manderson4AGLQ]

I'm hoping to initiate a constructive discussion about a recurring behavior I've observed in Inventor's iLogic, specifically concerning how parameters interact with units during calculations. Despite explicitly defining a parameter with a specific unit types, it sometimes appears to store or display a numerical value that corresponds to a different unit, which is unexpected.

My Understanding of Unit Handling & Workarounds:

I'm familiar with setting global document units, assigning specific unit types to parameters in the Parameters dialog, and I also understand that some users opt for entirely unitless parameters and manage all conversions manually.

However, the core behavior I'm trying to understand is when a parameter like ResultFeetParameter is defined as Length (ft), my expectation is that it would consistently hold and operate on values in feet. If it's part of a calculation involving parameters of different unit types (e.g., adding a Length (in) parameter to a Length (ft) parameter), I would expect Inventor to seamlessly manage these unit conversions behind the scenes, ensuring the ResultFeetParameter always maintains its value in feet. Instead, it often appears the raw numerical value assigned to such a parameter ends up on a different scale (like inches), indicating an underlying storage or calculation unit that doesn't align with the parameter's declared definition. This creates a need for constant vigilance and manual correction in iLogic code, particularly when values are displayed in Message Boxes, checked in the Parameters dialog, or linked to drawing annotations. It feels like an additional layer of manual overhead that could ideally be handled more robustly by the software.

I've attached an example of this behavior.

[JelteDeJong]

Based on your example file, it looks like parameters are always shown in document units in this case, inches. That makes sense, since calculations are easier and more consistent when all values use the same unit. ( I think iLogic is created for doing calculations)

If you need to work with the specific units assigned to parameters, consider using the Inventor API instead of the iLogic API. It’s a bit more complex, but offers much greater flexibility.

' Get the active document as a PartDocument
Dim doc As PartDocument = ThisDoc.Document

' Access a specific user-defined parameter by name
Dim parameter = doc.ComponentDefinition.Parameters.Item("ResultFeetParameter")

' Log the parameter expression — includes units as a string (e.g., "25 ft")
Logger.Debug("Expression: {0} <-- unints are provided by the Expression", parameter.Expression)

' Log the raw value of the parameter — always in internal database units (e.g., cm for length)
Logger.Debug("Value: {0} <-- unints are not provided but always in database units. For length units this is always Cm", parameter.Value)

' Log the string representation of the units assigned to the parameter (e.g., "ft", "mm", "cm")
Logger.Debug("Units: {0}", parameter.Units)

' Get the UnitsOfMeasure object, which handles unit conversions
Dim uom As UnitsOfMeasure = doc.UnitsOfMeasure

' Translate the parameter's unit string to an internal UnitsTypeEnum value
Dim outputUnit = uom.GetTypeFromString(parameter.Units)

' Convert the parameter value from database units (cm) to the parameter’s own units
Logger.Debug("Value converted to parameter units: {0}", uom.ConvertUnits(parameter.Value, UnitsTypeEnum.kDatabaseLengthUnits, outputUnit))

' Convert the parameter value from default display units (usually the same as database) to millimeters
Logger.Debug("Value converted to mm: {0}", uom.ConvertUnits(parameter.Value, UnitsTypeEnum.kDefaultDisplayLengthUnits, UnitsTypeEnum.kMillimeterLengthUnits))

You might also want to have a look at my blog post: "Parameter, Document and Database Units"

[manderson4AGLQ]

Thank you for taking the time to reply, and I appreciate your explanation and the Inventor API code example. I definitely would love to start learning more of these lower-level API calls for advanced customization and reliability. 

However, this leads to a fundamental question regarding the intuitive design for everyday iLogic users: If, for accurate and reliable display or use in any calculation we must consistently resort to lower-level API calls to manually convert from internal database units to the parameter's declared unit, then the practical benefit of explicitly defining Unit Types (like Length (ft)) directly in the Inventor UI becomes less clear.

From a user's perspective, it feels like this shifts a significant burden of managing fundamental unit integrity onto the user, requiring a level of programmatic vigilance that seems disproportionate for such a basic CAD concept. 

My hope is that the system could, ideally, ensure that a parameter explicitly defined with a unit type (Length (ft)) correctly holds, processes, and displays values consistent with that declared unit, handling background conversions transparently. This would greatly enhance the user experience and reliability of iLogic automation.

Thank you again for the ongoing discussion.

[WCrihfield]

Just dropping in a Link to one of my Inventor Ideas posts about this topic, in case you might be interested in reading through it or voting for it.  There are a couple replies under it from Mike Deck, a long time Autodesk employee who has been helping us with Inventor API stuff since this forum first began.  It does not look like this will be implemented any time soon because that idea post is already several years old, and still only has 11 votes as of my posting this reply.  But the general idea of wanting to always be interacting with parameter values in the same units as the parameters are set to certainly goes back much farther than that.  Some idea posts that had been around for a lot of years without much activity (votes or replies) seem to get retired, then lost in the shuffle.  Other idea posts which may have duplicates or others that are similar enough can get grouped under a newer idea post, where there votes and replies get combined into one collection.

The idea below was labeled:  "Add Property/Method To API For Parameter Type Objects – Get/Set Value In Parameter/Document Units".  Kind of long and odd to read for folks who are not involved with Inventor API or iLogic...probably why not many folks found it, read it, and voted for it.  🙄

https://forums.autodesk.com/t5/inventor-ideas/add-property-method-to-api-for-parameter-type-objects-... 

[manderson4AGLQ]

Thank you so much for taking the time to reply to my post and for bringing your 2021 Idea post to my attention. Reading through it, along with the discussion with MjDeck, has been incredibly validating regarding my feelings on this issue. It's clear this is an area that would benefit a significant number of Inventor users. I've already upvoted it and had a coworker read it over, and he's also added his vote.

I've learned to account for Inventor's internal preference for centimeter conversions behind the scenes, and I understand the technical reasoning for why iLogic might default to document units to simplify internal calculations when equating values from different units.

However, as you articulated so well, the discrepancy arises when the program outputs or displays values (e.g., in debug loggers or message boxes) using the document's unit rather than the parameter's assigned unit of measure. This is where a clear user expectation is not met. When debugging a rule, outputting a value in an unexpected unit can absolutely lead to human errors and wasted time, which is very frustrating.

Our workflow, for example, primarily involves designing in inches, so our document settings are appropriately set. However, we frequently deal with elevations and other dimensions in feet, relying on Inventor to handle these conversions seamlessly. The current behavior adds an unnecessary layer of complexity and vigilance to our automation efforts.

It's genuinely reassuring to find a clean and reliable workaround confirmed (using explicit API conversions), and especially to know that this is a well-recognized issue for many users. I'm still relatively new to iLogic and actively learning its API and other aspects of VB to automate our workflow with Inventor. I truly enjoy the process, and understanding these nuances is part of that journey.

I will certainly urge anyone reading this post to upvote it, as greater visibility for this enhancement would be a tremendous benefit to the user community.

Thank you again for your valuable insights and for shedding so much light on this topic.