DH+ Comm issue

[rta53]

I am going to a customer's site tomorrow to make a small programming change and to troubleshoot a possible issue with the DH+ network. The panel we installed several years ago has a SLC 5/04 and a standard PV1000. These were the only nodes on this DH+ network for years. A couple of months ago the customer asked me to change the node addresses so he could put the SLC on his existing network. I did that and now he says that when he connects his new cable to the SLC he loses communication between the SLC and the PV1000 for "some" of the analog inputs. Maybe this is possible but I would have thought the whole thing would go down instead of a few addresses. One thing he did not do was remove the terminating resistor at the SLC. I told him to do that since it is no longer at the end of the chain. I'm hoping this will fix his issue. Could this be causing the loss of data? Any other things I should look for?

 

[Ken Roach]

Make sure that the SLC-5/04 has a Diagnostics File defined for the DH+ channel, so you can evaluate the traffic and error counters.

It's possible that the "some analogs" are being read by the PanelView in a relatively long data table packet. In some electrically noisy or overterminated environments, short data packets succeed but long ones don't.

DH+ is amazingly forgiving of nonstandard cable and termination, but if you're having problems the first thing to do is to get the termination right. At 230.4 kb/s use two 82 ohm resistors. At 115.2 or 57.6 kb/s, use two 150 ohm resistors.

Place them ONLY at the two extreme physical ends of the network; terminating resistors are often at the PLC port but that's only coincidence because the PLC is often physically the first device in a daisy-chain.

 

[daba]

Some people don't "daisy-chain", but use a "trunkline" topology, using station connectors in the trunkline, and "droplines" to their devices.

Often I've seen the last drop be a significant length, and the termination resistor installed incorrectly in the "unused" trunkline port of the station connector.

Technically, the last station connector isn't the "end-of-line", it will always be the remote (device) end of the dropline, so the station connectors at the extreme ends of the trunkline aren't station connectors at all, just junction boxes.

In one noise-infested system, RA engineers were called in to diagnose a "bad" network. They eventually found a redundant, obsolete drop, about 40 meters in length, diappearing into a stripped out, decommissioned panel. Inside the panel they found a further huge coil of the DH+ cable, and the bare ends were lying on the panel base, which just happened to be filled with water !

 

[rta53]

Thanks for the info. When I went to the customer's site I discovered that there were no terminating resistors on either the SLC 5/04 or the PanelView. The customer later told me that he didn't think there were any resistors anywhere in the system and that things had worked "fine" for years. So Ken your statement about DH+ being very forgiving with nonstandard cabling and termination is very true. So the customer proceeded to connect his cable to the connector at the 5/04 and instead of losing "some" analogs the Panelview/SLC network just dropped out and the Panelview displayed a network error message. Also I lost communication to the 5/04 from my laptop and the DH+ led turned off. Then when he disconnected the cable, the Panelview and SLC started communicating again and I was able to get back online from my laptop. I suggested he temporarily run a new cable and make sure it was terminated properly which he planned to do later. There wasn't much else I could really do. He was not really sure what the node addresses of the other devices were so perhaps there was a node conflict. I ended up changing the addresses for the SLC and the PV to higher numbers but that didn't help. I couldn't really do any diagnostics because of losing connection when he connected his cable.