Redundant controlnet using 2x 1756-CNB not 1756-CNBR?

[ckchew666]

Hi,

Currently I'm working on a project with redundant media (CNET) architecture for CLX. Attached is the architecture proposed by the Rockwell distributor to us, instead of using a 1756-CNBR, the proposal is using two units of 1756-CNB. I've not come across such architecture, does anyone if this is a workable architecture? Reason being is to have communication when either of the 1756-CNB is faulty (like the Siemens profibus).

Thanks....

 

[Oakley]

I don't see how this can be equivalent to CNBR's.


The CNBR is redundant media. If CHA detects a fault, then it switches to CHB.

What you have depicted is multiple CNETs. Ownership of the IO would be via a single CNB. If it stopped, it doesn't just switch to the other.

So ... long story short, I don't believe so. Ask your distributor how it can be such.

 

[LJBMatt]

I believe each controlnet would be able to transmit input information but single CNB can have ownership over outputs. Oakley is correct in that it is not equivalent to CNBRs. Not to mention you would have to duplicate all your I/O tags in the PLC because you have 2 separate CNB networks and not redundant media on 1 network.

 

[ckchew666]

Oakley/Matt,

If we are putting one CNBR at the remote rack, if the CNBR is faulty, thus all the I/O at that particular rack will not be able to obtain by the CPU, right?

If Channel faulty it'll switch to another channel, i understand this.

The architecture shown above means two separated CNET network according to Oakley, we cannot pull/send data at the same time by using two CNB? You mentioned something like ownership, meaning the IO in that rack can only be 'own' by one CNB, thus other CNB will not be able to control these IO when the first CNB faulty?

 

[Oakley]

Not saying that it won't work, but why are you trying to do this? Is your process SO critical that it is worth the hassle? You would probably be better off keeping the application simple and having spare CNB's if there is/was a failure. I've never had a failure of a card, and my systems have been operational for 5 years.

 

[ckchew666]

Not saying that it won't work, but why are you trying to do this? Is your process SO critical that it is worth the hassle? You would probably be better off keeping the application simple and having spare CNB's if there is/was a failure. I've never had a failure of a card, and my systems have been operational for 5 years.

Oakley, yes the system is critical, is a monitoring system for chemical/gas leaking. The client won't bother how much hassle to setup the system, just that they want the lowest posibility failure of system. My concern is I do not know how much hassle it'll be to setup 2 CNB, or will there be any stability/conflict/compatibility issue during operation/switchover, which bother me much.

Hope you understand my situation here. Thanks.

 

[LJBMatt]

The CNBR is for redundant media and I'd say you have a greater chance of losing the network than a card failure IMO. Now I'm not saying 2 CNBs won't work, but it creates a lot of complexity and I don't know how you will handle the 2 controlnet bridges controlling your I/O in your remote racks. I'm not sure with 2 CNBs if both can be a bridge to your rack outputs at the same time. Also if you have a network failure or CNB failure your code will be responsible for handling the detection and changeover.

If these inputs and outputs are mission critical instead of redundant CNB's I'd swtich to redundant remote racks with CNBR's. That way if any card in the remote rack fails you can cross-check with the other remote rack. If that is what you are displaying above in your pic then I would just switch out to CNBRs as your bridge to simplify the complexitiy you already face.

 

[Oakley]

If it is that critical, then you still have a single point of failure within your IO (which has a much greater chance of failure). Investigate SIL or even TMR.