ControlNet Issues

Hi;

I have unsuccessfully tried to add a new ControlNet node to an existing network.

This particular network - named our "SCADA" network - connects a few ControlLogix PLCs to dual Cimplicity SCADA servers. This is obviously mainly for SCADA display, although there is a small amount of produced and consumed tags used between a few of the PLCs.

This network has worked fine, and remains so. However, when running RSNetworx connected to the new PLCs, the rest of the network is visible, except for the SCADA servers. When running RSNetworx from other PLCs on the network, all nodes are visible, but the new Primary PLC node intermittently drops in and out, thus preventing scheduling - the secondary PLC node remains visible.

Interestingly, if the new PLC is connected solely to the SCADA nodes, that network can be scheduled and works properly.

The existing CNBR cards are series D rev 5.50 (CPUs 1756-L55 rev 13.53), whereas the new PLC's CNBR cards are series E rev 11.3 (CPUs 1756-L63 rev 15.60). Could it be a firmware issue?

Also I have noticed that there is a jump in node addresses: the nearest node is 15; our new PLC is 20. Could this cause a problem? I should add that the SMax and UMax are set appropriately for these addresses.

Any other ideas?

Cheers.

Node numbering not an issue

Node numbering will not cause your issue, unless there are duplicate nodes. This sounds like a power/noise issue to me, especially if you have had no network issues prior to the the additions to the network. I am no in depth CNET expert, but have been a frequent user and have only seen issues like what you're experiencing once. The integrity of the cabling ended up being the culprit, specifically the termination points.

Cables

Thanks for the response.

The small new cable segment length was replaced with a temporary run to test this, but it made no difference. However, I suppose it is possible that the additional cable might not be quite the same spec as the existing segment cable, therefore leading to a mismatch that could prevent healthy comms to the new PLCs.

For interest, is there an AB procedure for adding a new node to a CNET architecture like that I have described? (Their manual explains it for adding new remote I/O.) I ask because if you add a new CNET module that holds the config of a different network, it will obviously fail to communiciate, could this bring the rest of the network down?

Should you always start RSNetworx from the current Keeper, or does that matter?

Thanks

You did not mention if you used a CNET tap to connect this new node ... and subsequently move the terminating resistor (assuming you added this node to the end).

Thanks Oakley;

We did indeed add a new CNET tap to connect this node. And, as it was at the end of the segment, the terminating resistor was moved to the 'new' end.

I should add that we have a fibre run connecting this part of the segment to another copper run. But this existed previously and never caused any issues.

Because ControlNet modules do hold onto Keeper and Signature data in their NVRAM, I always clear module memory before installing used modules. You can use the RSNetworx for ControlNet "clear keeper" function, or the Clear Keeper Utility, or (my favorite) use a ControlLogix controller to send a CIP command code 0x05 (Reset) to the module over the backplane.

Any fiber or copper repeaters need to be declared in the Network Properties because the low-level signal timing gets adjusted to account for the repeaters. This data is stored and shared in the same way as NUT, SMax, and UMax, I think by the Moderator node. If you are using non-AB repeaters (Phoenix Digital or Weed Instruments) they should be able to tell you how to manually put entries in the Media tab to account for the latency of their repeaters.

The ControlNet signal meter (1788-CNCHKR) is the very best tool for diagnosing ControlNet signal issues. Because it includes a passive ControlNet transciever, it can show you low-level signal conditions that won't show up in a protocol analyzer and can be very difficult to see with an oscilloscope. Most RA field service engineers have one and know how to use it.

Excellent reply, Ken, very helpful,thanks.

One of the investigation points is whether the fibre repeaters and cable run have been declared in the network properties - so I will definitely get that checked.

We don't have a ControlNet signal meter, but it looks a good investment.

It seems most likely that our problem is a result of cable/ installation issues or that the repeaters haven't been declared in Networx.

I will respond once we have a resolution.

Probable Cause

This issue has been investigate offshore. Just to reiterate the design: One run of coax segment with a couple of node drops, then a run of fibre to another coax segment with more node drops.

It was found that one of the coax segments has been cabled directly into the fibre connector (i.e. not via a drop cable.) It looks like this is what was causing the problems.

Thanks for the help.