Revit Architecture Forum
Welcome to Autodesk’s Revit Architecture Forums. Share your knowledge, ask questions, and explore popular Revit Architecture topics.
abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

Calculated Values in Tags issue

14 ANTWORTEN 14
Antworten
Nachricht 1 von 15
tgrantdelawie
1246 Aufrufe, 14 Antworten

Calculated Values in Tags issue

Hello, 

We are trying to set up a calculated value in a tag with a few more options. For our egress plans, we have to show 3 types of information for doors and stairs. 

Egress Quantity: Number of Persons (filled out by user)

Egress Width: Width of Door or Stair minus door leafs/handrails/jambs (filled out by user)
Required Egress Width: This is where the formula comes into play - Egress Width * [Value from Code Table] - this value is typically .2 or .15

I can get the calculated value to come out, but it usually displays a small number for Required Width - like 2". We want to have a condition set that if the calculated width is under 32", it will just display 32" Required Width. 

I have tried a =IF operation, but I continue to get "Inconsistent Units" everytime. 


Here is the formula:
Egress Width * .2 =IF(Required Egress Width < 32, 32, Required Egress Width)

Could it be having issues because the Required Egress Width is really not a parameter persay, but a calculated value in the tag? 

Thanks!

14 ANTWORTEN 14
Nachricht 2 von 15
barthbradley
als Antwort auf: tgrantdelawie

Divide by 1 usually resolves my inconsistent units errors 

 

 

Required Egress Width/1

 

 

Nachricht 3 von 15
ToanDN
als Antwort auf: tgrantdelawie


@tgrantdelawie wrote:

Hello, 

We are trying to set up a calculated value in a tag with a few more options. For our egress plans, we have to show 3 types of information for doors and stairs. 

Egress Quantity: Number of Persons (filled out by user)

Egress Width: Width of Door or Stair minus door leafs/handrails/jambs (filled out by user)
Required Egress Width: This is where the formula comes into play - Egress Width * [Value from Code Table] - this value is typically .2 or .15

I can get the calculated value to come out, but it usually displays a small number for Required Width - like 2". We want to have a condition set that if the calculated width is under 32", it will just display 32" Required Width. 

I have tried a =IF operation, but I continue to get "Inconsistent Units" everytime. 


Here is the formula:
Egress Width * .2 =IF(Required Egress Width < 32, 32, Required Egress Width)

Could it be having issues because the Required Egress Width is really not a parameter persay, but a calculated value in the tag? 

Thanks!


If you setup parameter types properly as below then there is no need to divide by 1.  Otherwise, divide by one to iron out the different unit types.

 

Egress Width & Required Egress Width: Length parameters

Egress Quantity: Number parameter

 

Formula:

Required Egress Width = Egress Quantity * 0.2"

Egress Width = if(Required Egress Width < 2' 8", 2' 8", Required Egress Width)

 

Annotation 2019-03-28 120421.png

Nachricht 4 von 15
barthbradley
als Antwort auf: ToanDN


@ToanDN wrote:


If you setup parameter types properly as below then there is no need to divide by 1.  Otherwise, divide by one to iron out the different unit types.

 


 

so basically what you are saying, is that divide by one will iron out or resolve inconsistent units errors when it is necessary to intermix unit types in formula calculations.   

Nachricht 5 von 15
tgrantdelawie
als Antwort auf: ToanDN

We did set it up previously (before I was at this firm) as part of the family, but now with the ability to do calculated values inside a tag since 2016 or 2017 - I was looking at it not being part of a door family, but as part of just the tag and would calculate the values from the tag, with some of the values being manually entered. 

The reasoning to move away from the parameters family is because someone in the office is going to use a door from a manufacturer (or just the wrong door completely) and then their egress plan wont work. Also - editing and maintaining a complete catalog of doors with shared parameters between them all can be a task in itself. 


Nachricht 6 von 15
tgrantdelawie
als Antwort auf: barthbradley

I tried the divide by 1 trick in nearly all locations, but it still wouldnt go. 

I was wondering if it was something to do with the fact that the "calculated value" isnt really a parameter in the tag, but more just like a field. 

Right now - the Egress width is set to a length shared parameter - and the Egress Quantity was a number. I tried using the Egress width as a number and the calculated value as a number and it still would not go.  

Nachricht 7 von 15
ToanDN
als Antwort auf: tgrantdelawie


@tgrantdelawie wrote:

I tried the divide by 1 trick in nearly all locations, but it still wouldnt go. 

I was wondering if it was something to do with the fact that the "calculated value" isnt really a parameter in the tag, but more just like a field. 

Right now - the Egress width is set to a length shared parameter - and the Egress Quantity was a number. I tried using the Egress width as a number and the calculated value as a number and it still would not go.  


 

If the Egress Width is a Length and the Egress Quantity is a Number then the Calculated parameter should be a Length.

If you change the Egress Width to a Number, then use Required Egress Width/1 in your formula. 

I would go with proper unit types for all of the parameters including the calculated one.  Read my post above carefully.  It shows how they work together.

Nachricht 8 von 15
tgrantdelawie
als Antwort auf: ToanDN


@ToanDN wrote:

@tgrantdelawie wrote:

I tried the divide by 1 trick in nearly all locations, but it still wouldnt go. 

I was wondering if it was something to do with the fact that the "calculated value" isnt really a parameter in the tag, but more just like a field. 

Right now - the Egress width is set to a length shared parameter - and the Egress Quantity was a number. I tried using the Egress width as a number and the calculated value as a number and it still would not go.  


 

If the Egress Width is a Length and the Egress Quantity is a Number then the Calculated parameter should be a Length.

If you change the Egress Width to a Number, then use Required Egress Width/1 in your formula. 

I would go with proper unit types for all of the parameters including the calculated one.  Read my post above carefully.  It shows how they work together.


Thats what I attempted, as you can change the unit type in the calculated value between the different ones. I tried as a number and a length and even created a new shared parameter for Egress Width as a number and tried that. 

I wonder if the issue is that the "calculated value" isn't really a parameter at all, and the =IF statement doesnt really apply to that calculated value of Egress Width * .2....if that makes sense. It works fine if I do Egress Width * .2, but when I try to add in the =IF statement, that is where it breaks. 

Nachricht 9 von 15
barthbradley
als Antwort auf: tgrantdelawie

can you explain what you mean by: "the 'calculated value' isn't really a parameter at all"? 

Nachricht 10 von 15
tgrantdelawie
als Antwort auf: barthbradley


@barthbradley wrote:

can you explain what you mean by: "the 'calculated value' isn't really a parameter at all"? 


Because the calculated value is only in the Tag. Its not a shared parameter loaded in - maybe it could be a shared parameter though with a formula applied.

I am creating the calculated value directly in the label editor and not pulling it from a list of available fields. 

Capture.PNG

Nachricht 11 von 15
ToanDN
als Antwort auf: tgrantdelawie

See the attached 2019 file.

 

Annotation 2019-03-28 152813.png

Nachricht 12 von 15
barthbradley
als Antwort auf: tgrantdelawie


@tgrantdelawie wrote:

I am creating the calculated value directly in the label editor and not pulling it from a list of available fields. 

 

I get it. Still, it's a "real" parameter. I doubt seriously that would throw an inconsistent units error. 

 

...are you using divide by one throughout?  Try using parenthesis with divide by one.  Like this:  (parameter name/1)

 

...or even brackets around the Parameter Name like this: [Parameter Name]/1  or this: ([Parameter Name]/1)

Nachricht 13 von 15
tgrantdelawie
als Antwort auf: ToanDN


@ToanDN wrote:

See the attached 2019 file.

 

 


Thanks for the file - that is how we got it working previously. 

I was wanted to see if there was a way without having to add a shared parameter to the door families, as that would take a lot of time invested in editing every door family that we use to add that parameter and ensure its functionality with families from Revit and manufacturers. Also ensuring that users are using the edited door families and not one that doesnt have the shared parameter. 


Nachricht 14 von 15
tgrantdelawie
als Antwort auf: barthbradley


@barthbradley wrote:

@tgrantdelawie wrote:

I am creating the calculated value directly in the label editor and not pulling it from a list of available fields. 

 

I get it. Still, it's a "real" parameter. I doubt seriously that would throw an inconsistent units error. 

 

...are you using divide by one throughout?  Try using parenthesis with divide by one.  Like this:  (parameter name/1)

 

...or even brackets around the Parameter Name like this: [Parameter Name]/1  or this: ([Parameter Name]/1)


I havent really tried the brackets - Ill give it a shot. Thanks! 

Nachricht 15 von 15
ToanDN
als Antwort auf: tgrantdelawie

If you want it as a Door Tag then the Calculated value parameter must rely on a shared parameter(s) presents in the Door family.

The way you described, some labels are manually filled and another labels by formula based off the filled labels, only works for Generic Annotation families.

Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.

In Foren veröffentlichen  

Autodesk Design & Make Report