Fully Connected Bridged Network Topology Problem

Hi Everyone,

I have a three c-bus network installation with three bridges and I am struggling with finalising a fully connected network topology due to a near/far side bridge allocation in toolkit.

Generally, I would like the topology to look like this from the C-Bus training manual:

My three bridges are physically wired and configured in exactly this way in a fully connected (ring) topology. i.e.

PCI--->Local--->Bridge1--->Remote1--->Bridge2--->Remote2--->Bridge3--->Local (connected back to Bridge1)

However...

In toolkit, my CNI which is connected to my 254 local network assigns as appropriate NEAR SIDE (NS) bridges to the two remote 252 and 253 networks which have a FAR SIDE (FS) allocation to their bridges. My understanding is that the NS/FS allocation in the bridge configuration is allocated in the direction moving away from the CNI/PCI to each subsequent remote network. i.e.
CNI--->Local--->NS/FS --->Remote1--->NS/FS--->Remote2--->NS/FS etc.

When I try to install the bridges and add each subsequent network, I run into the problem when coming back to the local network from Remote2 that the network is already created. So I then configure the bridge via editing each side of the bridge with its address corresponding to the adjacent network.

However, the "gotcha" here is that I end up with a bridge with two Near Sides.

CNI--->Local--->NS/FS --->Remote1--->NS/FS--->Remote2---> NS/NS !!! --->Local

I tried adding each bridged network and not physically connecting the Remote Network back to the local until the very end, but the NS/NS bridge problem occurs.

When you look at this bridge in the topology selection in Toolkit the Device Address is missing even though it is configured appropriately. with a 252 address pointing back to Network 252. There is also no Far Side option and if you mouse click on the numberless Far Side, it shows device "0" on the adjacent Main 254 network.





Bridge without device number even though it is specified as 252



Result when mouse clicking on the unnumbered far side of the bridge

I managed to login to a remote network using a CNI directly connected to that network and defined the NS/FS correctly. However, when I went back to the now NS/FS bridge in the 254 network, it then presented as a "device mismatch" because the database wants to see a FS bridge, but the network sees a NS bridge...

So...have I got this completely wrong, am I missing something simple, or does his just not work as specified?

I want all of my networks to route their GA status to each of the other networks and I understand that this is the way to do it.

Any ideas from the Bridge Guru's out there?

Thanks in advance.

Jason

 

A couple of questions...
-Are you using multiple networks for distance issues, number of units (max current) issues or some other reason?
-Why do you want/need to configure as a 'ring-route'? Just a point, it's not a great idea to do that with networks and will bring you untold pain.
-Is there a reason that you want/need to go two networks deep and not just have your second and third networks connected directly to your main (local) network.

 

Thanks for your reply.

The three networks are on three different floors and I have more than 255 devices, close to 255 Groups in the lighting application 56h and I have a second lighting app defined on 57h that is also almost at 255 Groups.

The power requirements push me well over the 200mA max current for a network so I am at three networks due to this. C-Bus cable distance is not a problem.

I have two colour C-touch's on the main network with the other two networks having DLT's only so nor remote routing elements. I want to route all group traffic for all applications between all three networks no matter which network initiates the group level change. The Groups across the networks have the same name so that if the Group changes on one network, I want it to change on the other networks. This currently seems to work one way only on a "C-Bus backbone network topology" (level change on local network ---> level change on remote network)

I have a separate CNI attached to each network, but this is mainly for backup and won't help with my group routing requirements. I do not use an "ethernet backbone topology".

As mentioned, I did have a "C-Bus backbone network topology" of a main local network with two attached remote networks each via two bridges, but even with the correct configuration for routing "All Applications" via the bridges to "Adjacent Network" and "Other Remote Network", group level changes instigated at the remote networks were not being seen as corresponding level changes in main network.

For example, watching C-Gate log messages, if I turn GA 125 on application 57 OFF in the Main (Local Network) 254, I see the following transmission of messages to the remote networks 252 & 253

20240821-191417 730 //JYOUNG/254/57/125 56fc8d20-419e-103d-9714-844bbd28ccca new level=0 sourceunit=3 ramptime=0 sessionId=cmd3 commandId=14856
20240821-191417 730 //JYOUNG/253/57/125 1c240840-41cb-103d-b094-844bbd28ccca new level=0 sourceunit=-1 ramptime=0 sessionId=cmd3 commandId=14856
20240821-191417 730 //JYOUNG/252/57/125 c0bbb590-41a0-103d-ac3d-844bbd28ccca new level=0 sourceunit=-1 ramptime=0 sessionId=cmd3 commandId=14856

As a result, the corresponding GA turns OFF in both remote networks as expected and this can be seen in the Groups in each network in Toolkit.

If, however, I turn the same GA back ON in the remote network 253, the message doesn't pass back to network 254 and the GA 125 on Application 57 remains unchanged on the main network:

20240821-191957 730 //JYOUNG/253/57/125 1c240840-41cb-103d-b094-844bbd28ccca new level=255 sourceunit=254 ramptime=0 sessionId=cmd3 commandId=14866
20240821-191957 766 cmd3 - Response: [14866] 200 OK: //JYOUNG/253/57/125

I'm unsure how to interpret the 200 OK message here? I cannot find a reference to "766" response above in the C-Gate manual. 756 is the last entry in the 76x reference w.r.t. PCI Sychronisation Events

So. changing GA's in the local network are routed to the remote networks, but not the other way around. I was of the understanding that a fully bridged network would solve this problem! Am I misunderstanding this from the C-Bus documentation on bridging and packet routing?

On the surface, a fully connected topology ticks all of the boxes, whay can't I configure it?

Cheers

Jason

 

I understand (now) what you are trying to achieve. I also see that Toolkit is giving some very confusing near side/far side feedback on units.

So, maybe try this... Ignore the near side and far side descriptions that are being served up in toolkit (for now anyway). The unit address of each bridge must match the network address of the intended destination. My testing on a project showed similar results to you but I manipulated the unit addresses manually so that...

Network 254>>>
Bridge 1 has a unit address of 253 - the network address of Network 253
Bridge 2 has a unit address of 252 - the network address of Network 252

Network 252>>>
Bridge 1 has a unit address of 253 - the network address of Network 253
Bridge 2 (other side of bridge 2 from network 254) has a unit address of 254

Network 253>>>
Bridge 1 (other side of bridge 1 from network 254) has a unit address of 254
Bridge 2 (other side of bridge 1 from network 252) has a unit address of 252

The unit address is an important parts of where messages are directed. By doing this and making sure the 'send to adjacent network' box is ticked in both sides of each bridge, each message should be sent to both adjacent networks across multiple applications even from CGate (not just C-Bus units).

I've tried this only in theory. My understanding of network messages was explained to me by the father of C-Bus (Don Terrace) many, many years ago. Keen to hear how you go.

 

Thanks for having a play in Toolkit and I am happy that you could reproduce the Near/Far Side issues. Have a look at the topology and you may even see the dreaded unnumbered one-sided bridge that points to Address 0.

What you have described in your last post, is what I have configured and what is documented in the Schneider C-Bus Training Manual on page 21. However, it seems to contradict Newman's comment on an earlier post from 2009 about the same question asked for the same reasons for having a fully connected network:

https://www.cbusforums.com/threads/fully-connected-networks.5171/

Here he states that "Toolkit will also prevent you from configuring your Bridges in this way." So Toolkit does not let you create a topology that is a documented "be-all-and-end-all" topology w.r.t. to message propagation in the C-Bus training manual!

I will keep playing to see if I get anywhere. Thanks again for your detailed, fast and insightful replies. I greatly appreciate it. I will go back to the "C-Bus Backbone" topology if I have no joy, but I investigated the fully connected topology in the first pace because the backbone topology didn't pass messages back from the remote networks....

Cheers

Jason

 

No probs Jason

I've just had another look at the bridge dialogue. I was always of the understanding the 'send to adjacent network' and 'send to other remote network' options were mutually exclusive. The dialogue indicates you can send to adjacent network and (also) a remote network (you did mention this in your original post).
Something is not right with this. Not too sure who we can poke on this these days.

 

I really spent a lot of time on this, drawing the topology, noting serial numbers, rechecking cabling, moving bridges around, reading the training manuals and help files, I thought it would not be too difficult. It's just like any other ring topology network concept. But it wasn't meant to be...

Never mind. I will keep trying...

Thanks again

Jason