If you have done much detailed design in SPEL you will have run into Circuits.
Circuits are needed if you want to hook up a power cable to a BUS, CELL Local Panel or even a Junction Box.
A circuit is a programming object that when created is a child of one of the objects mentioned above.
The problem, in my opinion, is that while BUSes and CELLS etc. are actual physical things a circuit is not. At least not in the case of detailed electrical design. It is a given that if you connect to a starter or a CB in an MCC Cubicle that there is a 'circuit' there but you would never detail it out in your design. In fact, the cable schedule and any other deliverable will be mostly concerned about the cubicle or cell and the load being fed from it.
The only case where this is not true is in a distribution panel (For Example 120/208V). There your detailed design will include what circuits you are using in the panel. If you are using single phase 1-pole circuit breakers then you would use one circuit. If you are using a two phase 2-pole breaker to feed a 208V load then you would need two Circuits. Which, by the way, you can't do in SPEL. One Circuit, one CB. You can't have more than one circuit associated with any one breaker which makes panelboards with 2 and 3 pole breakers almost impossible to distinguish unless you create reports that use VBA to fix this problem outside of SPEL.
It all comes back to how the programmers of SPEL created the object model and how in the real world things actually go together.
One of the uses for the Circuit that I have used which works really well on MCC's is naming the Feeder Circuit in the Cell the same as the load it is feeding. That way if you have to manually connect the power cable up you can just look for the circuit with the same load name.
Obviously, the downfall of this strategy is that if the load name changes then the circuit is wrong which may not be a big deal because the Circuit itself should not show up on any deliverables.
I thought about creating a rule that would automatically change the Item Tag of the Circuit to the Load that it is attached to but the problem with that is that it wouldn't work for my panelboards where I wanted the Circuits to be numbers.
The conclusion I think that I have come to though is that the problem is with how power distribution in SPEL is completed.
All power distribution in SPEL is designed using PDB's. But really, different distribution boards need different requirements.
In my opinion PDB's should be broken out at least into Panelboards, MCC's and Switchgear.
For Panelboards you would have Circuits but no Cells and you would be able to associate Circuit Breakers to multiple Circuits
For MCC's you would not even have Circuits. You would connect Power, Control and Instrumentation cables directly up to your cells as needed. The program would know that there is a 'Circuit' connection due to a power cable connection
For Switchgear it would be similar to MCC's but you could be able to have Incoming Power to the CELLS. With switchgear you may have more than one feed to a 'CELL'. Sometimes you may need a 125VDC and 120VAC power feed to the same CELL that the power feeder may be attached to. Currently, you can't attach an 'Incomer Circuit' to a CELL that already has a 'Feeder Circuit' in it. The only way that I could get around that was to create a Local Panel with the same name as the Switchgear Cell. But then you end up having two pieces of Equipment with the same name.
Along with this is the use of Circuits in Local Panels and Junction Boxes. I think that the program should know if a power cable is connected to the LP or the JB and should already know what BUS it is being fed from.
I think the circuits add more complexity and a whole level of data management that really is not necessary. If you leave the Circuits as their default Item Tags it is almost impossible to connect up the cables manually.
Have other SPEL users ran into this or found creative ways of using Circuits in SPEL?
I would be interested to hear what others have done with panelboards in SPEL as well.