h1

Structuring a Conditional Statement

March 27, 2011

Problem:
I need a label in my family that will monitor a numerical input and change its value as a specific number value limit of another label is reached.

Example:
Wire gauge values in a panel schedule change as the wattage goes up.  This would be one example where the numerical input (watts) is being monitored by the wire gauge (label) and will change at specific thresholds.

Solution:
The label requires a conditional statement that checks each wire gauge threshold and when a specific value is reached renders the appropriate wire gauge.

Targets:
NEC Table 310-16 sets the following AWG (wire gauge) values for 75 degree (F) temperature rated copper conductors

14 AWG = 15 amps
12 AWG=  20 amps
10 AWG= 30 amps

Formulas:
Watts / 120v = Amps

Variables:
CL1 = Circuit Load 1 (represents that manually input Volt*Amps VA or Watts for Circuit 1)

Label Value:
Wire 1 (represents the wire gauge value in the panel)

Conditional Structure for Wire 1 Label
    is assigned in the Type dialog of the family as follows:

if(CL1 = 0, 0, 
__This first logical check says if the value for the label CL1 = 0 then return 0 which is
__assigned to the label  Wire 1.  The comma after the last 0 is where you put in the
__results if the value is not 0 which is your  next conditional check.  In my working
__version I used the 0 value to drive a visibility control of a text  based label which
__had the value of “—“ since I did not want to see a 0 value for the wire gauge.

if(CL1 / 120 < 15, 14, 
__ The next logical check says convert CL1 to amps by CL1 / 120 (as per our
__formula) and if it is less than 15 set the value for CL1 to 14 for 14 gauge wire. 
__This conditional follows the previous giving us a  structure of
__if(CL1 = 0, 0, if(CL1 / 120 < 15, 14, 
__the trailing comma is looking for the results if the value is 15 or larger and is
__where we place the next logical check

if(CL1 / 120 < 20, 12, 
__ The next logical check is similar to the previous only this condition checks
__for amp values from 15 to  just below 20 and assigns the value of 12 to the label
__Wire1 giving us a structure of 
__if(CL1 = 0, 0, if(CL1 / 120 < 15, 14, if(CL1 / 120 < 20, 12,
__ Again we have a trailing comma so we  need another logical check or
__closing value.

if(CL1 / 120 < 30, 10,
__The next logical check is again similar to the previous but checks for the
__amp values from 20 to just below 30 and assigns the value of 14 to the label
__Wire1 giving us a structure of 
__ if(CL1 = 0, 0, if(CL1 / 120 < 15, 14, if(CL1 / 120 < 20, 12, if(CL9 / 120 < 30, 10,

At this point we need to address what the value will be if we exceed the 30 amp limit.  In reality this conditional statement has numerous more checks for 50, 65, 85, … 200 amp conditions but I’ve shortened this example.  In my working version of this I had the statement return a value of 100 if I exceeded the wire size limit of the largest breaker that would typically be put in an electrical panel.  I used the 100 as a trigger for the visibility of a warning label that resided right on top of the location where the wire gauge was on my panel schedule so it was obvious that a value was entered that would not be accepted by the panel. The final statement reads as follows:

if(CL1 = 0, 0, if(CL1 / 120 < 15, 14, if(CL1 / 120 < 20, 12, if(CL9 / 120 < 30, 10,100))))

Note that you need 4 )))) to close the statement, if you count the corresponding ( brackets you will also find 4 so you will need to balance the brackets to close the statement otherwise Revit will return a Boolean error warning. 

This is an example of a nested conditional statement.  The working version was more complex in that the Wire1 label had to check two different CL1 values.  One where the values were as input and another where the values were bumped up by 25% for continuous loading as is the case with commercial lighting circuits.

When you start to build this type of intelligence into your Revit families you will begin to see how long and complex the conditional statements can become but this kind of automation is very valuable for improved accuracy and quality control.  Also when you create these kind of families I highly recommend running a performance check on every formula driven label to assure it’s working properly.  Given the time it takes to create one of these gems you will begin to see why the B.I.M. operators that build these high performance components have issues with sharing their B.I.M. files or turning the B.I.M. over to the Owner.  Personally I strip these components from my B.I.M. model before I share it with anyone.  One word of warning.  Nested Conditional Statements rigorously test your ability to handle logic and will drive you crazy.
.
.

.

.

.

.

Seeing my Psychiatrist Tomorrow.
Carl

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: