Since we got the ability to use calculated values in labels I developed a system for calculating occupancy loads. To that end, I wanted to create a schedule that users could look at to verify what they're seeing in the plans without switching back and forth. Here's the formula in our tag:
if(not(ManualOccLoad), roundup(Area / OccFactor / 1 SF), OccupantLoad)
Where:
ManualOccLoad is a shared, project parameter (this is for rooms) of the Yes/No type (why I won't say Boolean in a moment)
OccFactor is a shared, project parameter of the integer type
OccupantLoad is a shared, project parameter of the integer type
Area is the default Area parameter.
The idea is if the manual checkbox isn't checked, just calculate the value from Occupancy Load and square footage. If it is, use the manual entry as is.
But that same formula does NOT work in a calculated value in a schedule. For all project parameters of the "yes/no" type they are set to a "blank" state. The formula in a label is fine with that. In a schedule it doesn't capture the "blank" state.
Any ideas on how to work around this? Is it something that has been fixed since 2019? Is there a reason why we can't filter for that "blank" state or use a conditional?
Sort by the Y/N parameter, uncheck Itemize... then tick or untick the box in one go.
By the way, you can drive a lot of Occupancy parameters by a Key Schedule that may just render the NULL issue moot.
Gray condition means that the Yes/No isn't activated. To activate it, you need to manually set it.
Yes, you can do that... but it shouldn't be necessary. And users tend to be hesitant utilize that workflow regardless how many times I show how useful it is. The tag works perfectly fine with the exact same formula and without "setting" that value. I suspect the same problem would show up if I tried a conditional like: if(OccupantLoad>0, OccupantLoad, <calculate value>)
Key Schedules (in 2019) can't utilize shared parameters. Project Parameters (not shared) can't be used in Tags. And regardless, if one instance of an occupancy type is using a calculated value, and another is using a manual override, a key schedule wouldn't circumvent the calculation problem.
Why does it work in a label and not a schedule? That's the question. I completely understand how the parameter works.
@DilloinPDX wrote:Why does it work in a label and not a schedule? That's the question. I completely understand how the parameter works.
It doesn't.
Can you tell me how to replicate whatever it is that you are doing to make it so?
I'm using the exact same formula in a label inside a tag as I'm using in the schedule. In the tag it works. In the schedule it is not. Very simple.
Here it is in the label with the formula. And a screen shot in use providing the needed values. If I check the manual override (set the value to YES) the manual value is used. I've had it in use for over a year. Note the room selected has neither yes or no set for the override.
@DilloinPDX wrote:I'm using the exact same formula in a label inside a tag as I'm using in the schedule. In the tag it works. In the schedule it is not. Very simple.
Doesn't make sense to me. What version of Revit?
what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.." instead of "if (not(Yes-No),..."? I imagine it reports correctly, if you have been using it.
This is revit 2019.
There are 3 shared parameters.
Occupant Load - number
Occupant Factor - number
Manual Occupant Load - yes/no
Since these are rooms, these are all project parameters.
Create a room tag. Create a label with a calculated value of a number.
Here's the formula to use.
if(not(Manual Occupant Load), roundup(Area / Occupant Factor / 1 SF), Occupant Load)
Add these same shared parameters to your project and apply to Rooms category.
Place a NEW room. Change Occupant Factor to whatever.
Tag using the tag created above.
Occupancy value will be displayed correctly as Area/Occupant Factor (rounded naturally).
Put something in "Occupant Load" in the properties of room. Nothing should change
Check "Manual Occupant Load". Value in tag will update with value from Manual Occupant Load.
Uncheck "Manual Occupant Load." Value reverts to calculated value from Area/Occ Factor
I don't need to test. You both have provided empirical evidence. I agree it's strange. For that reason, I don't trust it 100%, so it won't be changing my workflow (e.g. activating the YES-NOs I create).
@barthbradley wrote:what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.." instead of "if (not(Yes-No),..."? I imagine it reports correctly, if you have been using it.
For the tag, I kinda don't care. It works.
For the schedule I've tried multiple versions. None will capture the condition when Yes/No is neither Yes or No.
I've tried using
if(and(not(YesNo), (YesNo)), calculate, override)
if(YesNo, override, calculate)
if(YesNo, override, if(not(YesNo), calculate, override))
None of these do anything different.
On the database side, if you use snoop, it isn't a true "null" as someone once told me. It is just "blank" or "un set".
@DilloinPDX wrote:
@barthbradley wrote:
what does the tag report is the conditional statement omits the "not" (e.g. "if (Yes-No,.." instead of "if (not(Yes-No),..."? I imagine it reports correctly, if you have been using it.
For the tag, I kinda don't care. It works.
For the schedule I've tried multiple versions. None will capture the condition when Yes/No is neither Yes or No.
I've tried using
if(and(not(YesNo), (YesNo)), calculate, override)if(YesNo, override, calculate)
if(YesNo, override, if(not(YesNo), calculate, override))
None of these do anything different.
On the database side, if you use snoop, it isn't a true "null" as someone once told me. It is just "blank" or "un set".
Schedules have existed since the dawn of Revit so their calculated parameters algorithm are based on the old database structure and rules.
Calculated value labels in tags were just introduced a few years ago so they are based on the new and improved database structure and rules.
Source: trust me dude.
I understand your point. I just don't share your assessment. YES-NOs have two values in my mind's eye - not three. My expectation is that NULL would drive nothing. The fact that it does, is perplexing to me. But even a broken clock is right twice a day.
Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.