principles of selectivity between upstream fuses protecting a parallel conductor distrib circuit and the downstream fuses

Goodly morrow

Academic scenario:   a final circuit is protected by a 32A fuse/mcb and it is supplied by a distrib circuit that uses two parallel line conductors each protected by two 32A fuses

For selectivity,  if there is an overcurrent (overload or fault) on the final circuit near to the fuse,  can one 'simply' consider the distrib circuit fuses as one fuse (each summed as such)  ?

As there might not be 'selectivity' graphs for a 'summed' fuse/mcb arrangement,  what would one do ...  best ask the manufacturer ?

Thanks for any help in understanding, for my lacking brain.

Parents
  • i've sat with a pen, paper and calculator , doodling  various made up scenarios ...   for more than two conductors it can get a little tricky to say the least   - or, it proved my lacking mental ability at least  :-)      As BS7671 App.10  suggests,  especially for more than two conductors,  linked devices should be a serious consideration and one can see why !     For two parallel conductors, especially when overload protection is being provided (as well as fault), there is not much of an issue to worry about in most  circumstances (single phase particularly)  with one protective device as has been suggested (and it is like a RFC) ...     i'm still trying to hack the maths if a fault would clear two separate devices  (two parallel conductors) in various scenarios .     

    As an aside,  are there any [online] tools for parallel conductor 'maths'   (I presume that Amtech stuff would do it)  ...

    Thank you all for the previous comments.

  • Yes it's a mind-bender. In many practical cases, though, it's somewhat easier to specify the cables and the installation method such that current sharing is sufficiently even that a single upstream device can provide overload and fault protection. And of course then make sure that the installation method is actually followed through on site.

    I presume that Amtech stuff would do it

    Heck no. It's not much more than a glorified spreadsheet, albeit one that is useful for speed on conventional circuit designs. It is possible to specify parallel circuits but there's no means of calculating current sharing factors etc, at least on the version we run.

    Also, one thing that's not been mentioned (and I don't think is excplicitly covered in appx 10) is that if you have separate devices for fault protection on each parallel conductor, the fault withstand capacity of each still ought to be the total circuit prospective fault, because you'll see that in some scenarios they won't all clear at the same time, leaving the one "turning out the lights" having to break the full Ipfc.

  • What is the context?

    Is this really a problem in, for example, singles in conduit, or doubling up cores in SWA? Or are we really thinking about industrial installations where a single very large cable would be too difficult to handle, so is divided into smaller conductors?

Reply
  • What is the context?

    Is this really a problem in, for example, singles in conduit, or doubling up cores in SWA? Or are we really thinking about industrial installations where a single very large cable would be too difficult to handle, so is divided into smaller conductors?

Children
  • And how well balanced are the routes - the reason we don't need to bother bother with the neutral cores in split concentric, even at the level in the larger sizes when any one core would fuse let alone overheat, if it carried the  full current, is that the routes of the individual insulated wires  are very well balanced indeed by the design of the cable and the fact they are in thermal contact,

    I suspect there are very very few cases indeed where parallel feeds are the best solution and need to be done in a way that a common fuse or breaker is not enough, and where they are one really needs to be thinking about fusing and L-N current balance as well.Mostly folk would be able to use a larger cable or the run is controlled enough that a dangerous and undetected fault is acceptably unlikely.

    Mike.

  • the context is (was originally) in the OP.  i

    it is about the principle of [mainly] fault protection in parallel cores   I  suppose ...   and what is written in App10 ... but you already know that   from your previous reply

    in my reply above (to myself) -  i think it had already come to a conclusion at least for me.

    i've learned a bit so its been good.

    cheers