Multiple diversity factors on a circuit

[Anonymous]

I have no idea why a circuit would have multiple diversity factors on a circuit.  I would dought that the multiple elemes on a circuit would be multiplied in one circuit.  I think technically, a individual circuit would go one way or another, not multiple.

I have other circuits which have more than 2 differant diversities on them.  I presume that is what this last column is all about.

[Martin__Schmid]

Feeder Circuits (between panels) will have all load categories that the 'child' panel 'sees'.  In your specific case, my guess is that the 'Other' is comming from Switches you have on the circuit.

[Anonymous]

Thank you Martin but actually they come from jboxes placed in the circuit, as I have illistrated in other posts.  The problem I face now is that when the reports get generated, the diversity factors are playing havic with spcific naming procedures not to mention how revit is handling those demand factors.  I am wondering, if lights is the primary demand factor for a circuit, and the load is divided among 3 or four factors (other and lights), how is the math done?  Is it still one number or do you multiply the factor for jbox (100%) and then lights (125%)?

I understand what you saying, but classifications can not be 2 differant factors.  I hope the illustrations define my point better than my words and I hope you fix this problem.  The classification are limited and specific, remove verbage saying it is anything but.

[Anonymous]

One other thing while I have youon the phone...  Is there a way to extract the data defined in these classifications to a data set?

I am looking for factors and names, even when defined by users.

[Martin__Schmid]

To fix the reporting problem (only wanting to see one load classification in your schedule), if the j-box doesn't already have a load category associated to the connectors, add it to your family, then assign the load category accordingly within the project.

As far as demand, there is no factoring that happens at the circuit level... the load on a circuit is the sum of the loads, regardless of load category.  The demand is only computed at the equipment.

I can understand why you would want a demand applied at the circuit level... however, since conventionally this information is only displayed on panel schedules (which schedule the equipment), that is where the functionality 'lives'. 

If Revit did apply demand at the circuit level, how would you use that functinality?

[Anonymous]

Yes this is where load diversities live in panel schedules.  What I think would would happen is one of two things.  As I think you are explaing to me that revit takes EACH device on the plan and gives it a divsersity factor then collectivly adds them based on which panel they are in, then collectivly for computing demands over 10,000 va for instance.  I house wiring that is fine and what we would normally do, but we don't normally go to those lengths when wiring commercial buildings.  We are also more carful about what we put on circuits based on this logic too, as you may know. 

We still want to see loads based on each panel.  That gets factored all the way upstream.

[Martin__Schmid · Accepted solution]

Each device has a load and a category.

The panel sees the total load for each category, whether connected tirectly to it, or if 'seen' downstreem from subfed panels.  Loads are always fed upstream as connected, the panels report both connected and diversified.

[Anonymous]

I am still very confused about the diversity factors and/or power factors when they show up on an schedule for electrical circuits.  What is apparent load as opposed to true load.  I would think that the apparent load would be load connected to circuit (it should state connected instead of apparent, very confusing).  I would think the "true" load would be calculated with diversities and maybe power factors on of these loads.

When true says zero while the apparent load says 10780 is insane.  Does anyone read or complain or care about this tripp?  If you are applying diversity factors at this point your calcs are seriously flawed (per each circuit as they appear to be doing).

Reword you confusing statements.

[Martin__Schmid]

True Load vs. Apparent Load has to do with the Power Factor; the ratio of True (Real) Load / Apparent Load = Power Factor..  thus, should have nothing to do with Dieversity.  However, to your point, the fact that you are seeing 0 is odd.  Can you provide a simplified version of this model containing a handful of circutis with 0 load, and a few where True / Apparent does not equal PF (i.e., circuts AMH 8 and 10)

[Anonymous]

Yes we calced power factor on some, but the zeros were really throwing us off.  I have no idea how these could have gotten there, UNLESS it has something to do with how the panelboard is connected.  MOSTLY these things are coming from panelboards but there are some which seem to be circuits.

Getting a partial revit will be very difficult I think.  See if the panelboards service could be causing a problem and let me know so I see about a partial.  Is there a method to cut selections and save to a revit?

[Anonymous]

I am wondering if it has anything to do with a 3 phase circuit, although some appear to be fine.  Circuits and panels, very confusing.

[Anonymous]

Determining panelboards from other circuits is very difficult.  Suggest you creat a unique load classification to show "panelboard" which canot be changed by users.  Not sure why your distances are recording zero length and say "other" like other common circuits.  A panel is not "other".  True a panel draws no current, in itself, but no reason to treat it like a common component.

The checks and balances here really suck.  changing this panel CUL to 3 phase caused the entire panel to loos all circuiting.

[Anonymous]

all circuits in CUL (sec2) had gotten disconnected too.

[Martin__Schmid]

Can you clarify what it is you are trying to check/balance?  Are you just trying to create a schedule that reports only 'feeder' circuits?

Without seeing the project, I couldn't assess why the panel's circuit is reporting a load classification of 'other'...  

The expected behavior is that the circuit should report all load categories that it 'sees'.  I.e., in the attached, the two panel feeder circuits list Power and Lighting because they both 'see' those types of loads.

For the 'zero length', based on your screenshot, I'm not sure what circuits you are referring to.  The circuits that report a length of 'Not Computed' is because, as you can see in the Panel and Circuit Number columns, are not connected to anything... thus, there is no way to estimate their length.

In the case you change a panel from 1- to 3- phase, I am able to repro the disconnect... however, consider the converse.  What should happen in the case you change it from 3-phase to 1-phase...  what should happen to the circuits that are on the 'C' phase?  Or, for that matter, what should happen to 3-phase loads on that circuit?

[Anonymous]

Check/balance  I was able to use a three phase panel schedule template on a panel that was defined as 120V/1p (I assume this means phase)  That is 2 wires not including ground.  The CUL panel clearly stated 120/208v/3p at the top and displayed 3 phases.  Is this typical of the template that it reports the improper phases, which could not be more than 1 as it was defined in the edit family?  Why would it read voltage and not phase?  Only one very tiny indication the panel was defined as 120v, and without this schedule I never would have found it, could you have?

I am just trying to figure out this whole schedule thing so I can export a tab delimited file into my program and if the information is wrong, well that will cause problems.  As I have always said, if 2% of information is wrong, what 98% is right?

The point is here that if a panel is listed seperatly in the schedule, and you stated earlier that a circuit has the combined classifications of all circuits under it I assume, that includes panels? so if this were true, by your account that I would see other, lights, receptacles, etc... under the panel.  In point, if the panel were considered indivualy, then it would have its own classification.

I will have to give you the argument of the zero length, but I did make a lame attempt to circuit this to a default transformer device that doesn't like being connected to anything I can fix.  To much work to get default revit element to a usable state especially the transformer.  This schedule certainly makes a good checks and balances interface to make sure these the things we think are working, are.

I see what you aere saying and I would believe that but there never should have been a B or C phase in 120v/1p in the first place, but the schedule suggested otherwise.  See my first comment. 

[Martin__Schmid]

Oh, are you indicating 1-pole. Not single -phase (two-pole).

In what case would you have a 1-pole (single hot bus) panel? The panel schedule implemention is based only on 1-phase (2-pole, that is two hot busses) and 3-phase (three hot busses), and as you have found, there isn't even a check if the panel happens to be 1-pole.  I have seen this request in some countries, but thus far, I've only heard that it is infrequently used, and is generally only found on existing buildings that are being upgraded anyway.  If you have a commonly found use case, I would be interested in hearing about it.

The parameter in the Panel Schedule you are showing is reporting the service/system it is connected to (it would be possible to connect a 1-, 2-, or 3- pole panel to a 3-phase system...) so this appears to be working as expected.  If you want to schedule the 'number of poles' of the panel itself, you would simply need to make the Type Parameter you are using to assign the Number of Poles as a Shared parameter so you can schedule it.

[Anonymous]

lol, that's what I am saying.  It was defined a 120v/1pole panel.  I have no idea how, but I changed it to 3 phase.  Thats when the circuits got lost.  There is no way this could have a 3 phase panel schedule TEMPLATE defined to it if there were checks and balances in place, US or timbuckfu.  Fortunatly this schedule helped find, but you must look to hard to find the error.  Consider this a bug report too.

How can I determine how there zero true load factors are appearing.  Can I send you the 120 meg file?  Got an ftp?

thanks.

[Martin__Schmid]

no FTP, but Buzzsaw... I will need your email address to send you an invite... if you can email me your info to :

martin dot schmid at autodesk dot com

As far as the panel becomming 1-pole, that isn't a bug per se... you have the flexibility to define it as 1-, 2-, or 3 as you see fit.  However, as indicated, there is no support for 1-pole panels in panel schedules.  There is no 3- vs. 2-pole panel template.. there is simply an option whether to hide the 'c' phase in a 3-pole schedule.. so the 3- and 2- pole use the same template, and perhaps the same solution is applicable if you happen to have a 1-pole panel.  It seems the problem here is actually there may need to be a way to retain circuits if the phasing of the panel changes.  I noticed we make the 'Number of Poles' param non-editable if it is an instance property, so it seems that attempt at protecting the user from the issue isn't enough (since in your case, you set it as a type param, which was still editable).

[Anonymous]

let me do that tommarrow.  i am pulling out now.