Networks & 5100B Bridges again ....

Appologies for this ongoing subject but, have searched this site but found no definitive answer.

Senario: Three Network bridges connected in a 'Back Bone' toplogy the commonly connected side (Local near side) we'll call 'NetA', the far sides we'll call NetB, NetC and NetD respectively.

NetB contains two groups of PIR's, call them 'AA' and 'AB', they have to control Loads on NetC and NetD respectively.
The LGA's for the PIR's on NetB have unique but coresponding LGA's only on their respective target networks.

Is this senario possible?? because it appears that with all the briges (near and far side) connections set to application 'Lighting' and 'send to adjacent network' no load will control! But with the NetB(far side) set to send to NetC, PIR's 'AA' will control the Load on NetC and conversely, if NetB(far side) is switched and set to send to NetD, PIR's 'AB' will control the load on NetD. But obiviously this is an 'either or' situation, and not the desired funcionality, is this behavior correct, or am I missing somthing?

Thanks in advance,

Paul

 

The Bridges are working correctly, you are not missing something.

The network bridges only have the option to send to an Adjacent network or to some other Remote Network. The question you're really asking is "Can a network bridge send messages directly to 2 different remote networks?". It cannot.

You can solve this problem by installing a PAC on your backbone network, making sure that the 'Send to Adjacent' option is turned on, then writing some logic to send the desired lighting commands to the desired networks. The 'Send to Adjacent' option will make sure all lighting commands reach the backbone network, where the PAC would live.

 

The Lighting Application in C-Bus networks includes a regular 'Status Report' (MMI), which allows all units with matching Group Addresses to re-establish a 'connection'. This allows C-Bus units to resolve state differences in the event of intermittent communications, and is one of the reasons why correctly installed C-Bus has earned a reputation for reliability.

C-Bus bridges connect two C-Bus networks together. They pass installation messages, and can pass application messages between networks. While they can pass information from the network Status Reports, they do so only when requested, and the information in the status reports passed through bridges is not available to units on networks other than the originating network.

If a system is designed with C-Bus input and output units on opposite sides of a bridge (or a link of several bridges), then the 'status report' functionality is not available, and system reliability can suffer. It is always good practice, wherever possible, to keep input-output Group Address linked units on the same network, and use bridges only for exceptional cases. If bridges are used to separate input and output units, it's a good idea to have at least one input unit and one output unit on each side of the bridge link, so that the Status Report mechanism can be kept operational on each side (output unit Group Address contribution need not be associated with actual outputs - the Group Address could be assigned to a Logic Group, and Logic can be left off).

I understand that there may be instances where the physical distance covered in an installation exceeds 1km of cable, and the situation can't be avoided, but generally it is not good practice to put sensors on one network, and control loads on another network.

 

Many thanks to you both for your help.

I have to quickly say that I didn't design the installation, which is actually eight networks; seven on a 'back bone' + one 'daisy chained' and the senario I decribed is unfortunatley, numerous. The site is some 6 years old, and your right Don, it is unreliable and has been since installation, hence my involment now.

Uptill now the tasks have been centered on the basics, but now the network is up and stable, i've started the software regonfig, hence yesterday's question.

Now its a case of finding the biggest common denominator to get the majority of system running, after that i'll try and patch in the rest, and thanks Newman, the PAC's a really good idea!

Thanks once again,

Paul