AB NetLinx information

Hi guys,

I'm currently working on a project with NetLinx. Based on the existing system architecture (refer to attachment), with 1 main CPU panel and 2 Remote IO panels;

1) is it possible to add another remote IO panel on CNet without interrupting/shutting down the existing critical system?

2) is it possible to add additional DNet devices without interrupting/shutting down the existing system?

3) is it possible to add additional DNet card into the Remote IO chassis without interrupting/shutting down the existing system?

The redundancy is using version 16.50. RSView SE is version 5.00

Hope to hear from you guys. Thanks.

I'll give you the same advice I give all my customers who ask similar questions: If it's really a critical system, build it and don't change it while it's running.

That being said, most of what you describe can be done.

The 1756-DNB modules with version 7 or 10 firmware support "online scanlist changes at runtime", so you can add devices to the DeviceNet network and insert them into the 1756-DNB's scanlist without putting the controller or the module into Program/idle mode.

Unscheduled ControlNet I/O connections can be used to add new Bulletin 1756 I/O connections during runtime without placing the controller into Program mode. I believe this includes the 1756-DNB module but I would have to test it to be certain.

The first thing you asked must be answered with "it depends".

ControlNet requires that the termination resistors be present at all times at the end of the copper cable segment. If you want to "add to the ControlNet", you will need to remove the terminator to add new trunk cable segments. In the usual sense of "can I add to the network" the answer is no, because you will have to disassemble a crucial part of the circuit in order to modify the circuit.

If you build your ControlNet with repeaters and configure it ahead of time with appropriate timing parameters to accomodate those repeaters, you can add ControlNet segments to the repeaters without placing the network into an idle state.

Ken,

Thanks a lot for your info and really appreciate it.

Based on your replies;
"ControlNet requires that the termination resistors be present at all times at the end of the copper cable segment. If you want to "add to the ControlNet", you will need to remove the terminator to add new trunk cable segments. In the usual sense of "can I add to the network" the answer is no, because you will have to disassemble a crucial part of the circuit in order to modify the circuit."
In order to overcome this, can I disconnect the end resistor for Channel A, when I'm done, I'll reconnect channel A. Then I'll repeat the same for channel B (with Unschedule network). Possible?

I'm not sure if DNB is able to work with ControlNet unschedule network. If you manage to test/know, please keep me inform, okay?

Thanks a lot.

Wow! Guaranteeing 100% uptime during a major network upgrade is a tall order. I can't think of many processes that are truly this demanding (not saying yours isn't).

As far as your architecture goes:
1. Your RSView SE node is the weakest link in terms of downtime. The dual switch Ethernet concept makes no sense for the one workstation. Adding a second HMI node connected to both switches should increase the durability of your system considerably.

1a. If the EtherNet path is designed as a backup communication method to the ControlNet (not sure if this is supported...Ken?) then you don't want the "two switch" system wired as it is. From that perspective you will lose communications if either switch fails.

surferb said:

Wow! Guaranteeing 100% uptime during a major network upgrade is a tall order. I can't think of many processes that are truly this demanding (not saying yours isn't).

As far as your architecture goes:
1. Your RSView SE node is the weakest link in terms of downtime. The dual switch Ethernet concept makes no sense for the one workstation. Adding a second HMI node connected to both switches should increase the durability of your system considerably.

1a. If the EtherNet path is designed as a backup communication method to the ControlNet (not sure if this is supported...Ken?) then you don't want the "two switch" system wired as it is. From that perspective you will lose communications if either switch fails.

Click to expand...

Hi,

Thanks for your reply. I agree on your 1st point too, probably this will be the next phase of the project.

While for point 1a. The ENet is not designed as CNet backup, the purpose of putting 2 switches there is, in case 1 switch failed, the other switch will still bridge the SCADA and the ENBT module.