DH+ Communication Problems

We have a few machines connected via DH+ and we have lost communication with them. This is an intermittent problem and usually goes away. The fact that it comes and goes tells me that there is a loose connection somewhere. I have went through and checked all the connections and they seem fine. The DHRIO module status says that CH A (the channel for our DH) is OK and indicates a solid green light. Most of the time this lack of communication only lasts for 10 min or so, but this is the second occasion that it has been out for over an hour. So regardless that the connections seem okay, and the module indicates that the channel status is OK, we still have no communication in RSlinx. I wouldn't think that RSlinx is configured wrong because it works fine on most occasions. But, i could be wrong. If anyone has any input and/or suggestions, please get back to me. I thank you all for your help in advance for any help you can provide.

If I were at Tech Support, I'd ask:

What kind of controllers; all ControlLogix, or PLC-5 and SLC as well ?

What kind of RSLinx interface; 1784-PKTX, 1784-PCMK, gateway through Ethernet and a Logix backplane ?

Do other communications on other networks stop ?

Is there messaging between controllers that fails, or are you just examining connectivity between RSLinx and multiple controllers ?

Does communications restart spontaneously, or do you perform a power cycle ?

What Series and Revision is the 1756-DHRIO ?

Has the ControlLogix system been checked for the backplane ATMEL ASIC chip issue ?

The 1756-DHRIO has counters that keep track of statistics for the network channels, as do all PLC-5 and SLC-5/04 controllers. Check those for evidence of noise or other problems.

Visual inspection is insufficient for any network connection. If you can't get an oscilloscope onto the network, definitely take the time to disassemble every connector, clean and trim the wires if necessary, and reassemble the screws and plugs securely.

All the controllers, 5 total are SLC 500.

The RSlinx is interfaced through our ethernet.
1756 DHRIO is bridged with a 1756 ENET Card. Both are in the
Control Logix Backplane.
No other communication stops. Our Ethernet Network is working fine.

The Panelviews that are connected to the SLC's via the DH are operating normally. They communicate with their respective Processor. RSlinx will not communicate with any of the controllers on the DH.

Communications start responding spontaniously, without intervention.

The 1756 DHRIO is Revision 2.21 and series B

I am not familiar with the ATMEL ASIC chip issue

I will check the network channels for noise.

Thanks

Here is some diagnostic information from our bridge........I don't know enough to make much sense of it.
-----------------------------------------------------------------------
E N 3 6 0 M A C S T A T I S T I C S

22388 input packets 23876 output packets
0 FIFO overruns 0 FIFO underruns
0 input frames dropped 0 output frames dropped
0 framing errors 0 SQE test errors
0 CRC errors 0 retry failures
0 frames too short 0 frames too long
0 excessive deferrals 0 receive collisions
11 deferrals 0 late collisions
9 single retries 1 multiple retries
1 carrier sense error
0 packet fragments
0 network storms

C O L L I S I O N H I S T O G R A M S

[ 1] 9 [ 2] 1 [ 3] 0 [ 4] 0
[ 5] 0 [ 6] 0 [ 7] 0 [ 8] 0
[ 9] 0 [10] 0 [11] 0 [12] 0
[13] 0 [14] 0 [15] 0 [16] 0

-----------------------------------------------------------------------
I P S T A T I S T I C S

22768 packets received 25028 packets generated
0 fragments received 0 fragments generated
0 datagrams reassembled 0 datagrams fragmented
0 bad header checksums
0 unknown or unsupported protocols
0 packets too short 0 not enough data
0 bad header length 0 bad data length
0 incoming fragments dropped
0 time out 0 no memory
0 packets forwarded
90 packets not forwardable
0 redirects sent
-----------------------------------------------------------------------
T C P S T A T I S T I C S

0 discarded because packet too short
0 data packets retransmitted 0 completely duplicate packets
0 bytes 0 bytes
86 out-of-order packets (378 bytes)
82 duplicate acks 0 acks for unsent data
0 bad checksums 0 bad header offset fields
0 retransmit timeouts 0 persist timeouts
0 keepalive probes sent 0 keepalive timeouts
0 packets (0 bytes) of data after window
2 packets with some dup. data (126 bytes duped)
0 embryonic connections dropped
0 connections dropped by rexmit timeout
0 connections dropped by keepalive
0 connections dropped in persist
0 packets received after close

ldrewes said:

The fact that it comes and goes tells me that there is a loose connection somewhere. I have went through and checked all the connections and they seem fine.

Click to expand...

Ken makes some good points about information to gather but I'd like to add a few things that I've ran in to.

Is the "blue hose" ran correctly, i.e. is it being ran along any noise generators like a VFD? Is it parallel to any high voltage wiring or segregated, if so it could be picking up noise. Are termination resistors used on both ends of the network?

Check the publication titled: "Data Highway/Data Highway Plus/Data Highway II/Data Highway-485 Installation Manual".

OEM's had "daisy changed" the DH+ network where I used to work. We had a lot of intermittent DH+ failures. I modified to a trunk and drop and used Station Connectors.

You might want to check out Rockwell's Knowlegebase:
Answer ID: 36830 and pay close attention to Answer #1, "Must have solid Network" and all the documentation it references.

Keep hammering on it and you'll eventually find the culprit.

bbopn said:

Is the "blue hose" ran correctly, i.e. is it being ran along any noise generators like a VFD? Is it parallel to any high voltage wiring or segregated, if so it could be picking up noise. Are termination resistors used on both ends of the network?

Click to expand...

While I agree that this would definately be a culprit, this DH+ network has been in place for at least 7 years...since i've been working here. Nothing that drastic has changed as far as putting in new equipment that might interfere with the signal. It just started going out every once in awhile about a month or two ago.
Just in the past hour the DH+ decided to start working again...so we are good for now but plan on still trying to figure this out.

ldrewes
I think when the DH is out go down to one of the plc's and hook to its port leave DH connected and try and get on line with who active
It might narrow down were your problem is.

Divide up the network and see if its happening on one half.


tom