DH+ Problems

Hi all,
I wonder if anyone can help:
I have a DH+ network with 18 nodes on itand one particular node (5)will NOT communicate.
It talks just fine to its local PanelView (node 15) and also it comes back communicating if I disconnect the last leg of the Network containing 4 of the nodes.

The terminating resistors are in place and the physical cable topology is correct (daisy chain).


Any ideas ?

I am guessing this is a 5/04 that isn't communicating?

What speed are you running at? Is your total cable length maybe too long for that speed?

Dumb question but the last leg you are disconnecting doesn't have a node 5 on it I hope.

Anytime I have a DH+ problem the first thing I do is go around and double check every last one of the phoenix connectors at the devices. About 80% of the time that seems to be the problem and it isn't always the connection at the device giving the trouble.

Duplicate node?

SLC_Integrator said:

Hi all,
I wonder if anyone can help:
I have a DH+ network with 18 nodes on itand one particular node (5)will NOT communicate.
It talks just fine to its local PanelView (node 15) and also it comes back communicating if I disconnect the last leg of the Network containing 4 of the nodes.

The terminating resistors are in place and the physical cable topology is correct (daisy chain).


Any ideas ?

Click to expand...

New or existing application?

If existing, I would check the integrity of the DH+ cable from node #5 and beyond. I once had an existing application where DH+ started timing out due to one connection biting into the insulation of the Blue Hose and eventually losing contact with that wire.

Ian

DH+ needs terminating resistors at each end If you have a terminating resistor in the middle between the other two then one end can appear to drop off the network.

On the troubled SLC5/04 you can try to clear S:2/15 (Comms servicing select) and maybe also to set S:33/7 (Message servicing select).

You acn also try to stick one or more SVC instructions in the code a couple of places.

Warning: your scan time may increase.

edit: I assumed that it was an SLC5/04.
It is always nice to have such details sorted out in the OP. It saves us having to guess.

edit again: Ooooh "SLC Integrator". Now I get it. Then I guess my guess was OK after all.

Thanks for all the suggestions.

It wasnt a duplicate node, there were only 2 terminating resistors (one at each end) it turned out to be:

Ground whisker on Node 6 was touching the blue wire and giving us fits.
Re-checked all the terminations, found it and everything came up fine.


P.S. 'SLC' stands for Salt Lake City (I hate SLC500s lol) Theres irony.

After messing with DH+ I think I still prefer Ethernet IP, and uploading/downloading PV1000 over DF1 is HORRIBLY slow. Especially when you have 12 to change

Glad you found it. Like I said 80 % of the time it is a connection issue.

I personally like DH+ if it is used as it was intended. There really is no simpler network that I know of to connect and set up. My biggest beef with it is those darned phoenix connectors.

This thread inspired me to get out my shiny new Cleverscope and a pair of PLC-5 controllers. I connected their Channel 1A ports together with a 5-foot length of "blue hose" and took scope captures in three conditions: with no terminating resistors in place, correctly terminated with 150 ohm resistors, and with a single tiny "whisker" of the shield touching the blue-insulated "#2" signal conductor.

Often you'll hear "put a scope on the network and see if there's anything unusual", but I'd love to see a mug book of bad and good network signals so I can compare.

Anybody out there have a big (or small) DH+ that they'd like to connect to a scope (I can loan you mine if necessary) and post the results ?


Figure 1. Normal DH+ signals.


Figure 2. Unterminated DH+ signals.



Figure 3. 'Blue' conductor shorted to shield.

Ken Roach said:

This thread inspired me to get out my shiny new Cleverscope and a pair of PLC-5 controllers. I connected their Channel 1A ports together with a 5-foot length of "blue hose" and took scope captures in three conditions: with no terminating resistors in place, correctly terminated with 150 ohm resistors, and with a single tiny "whisker" of the shield touching the blue-insulated "#2" signal conductor.

Often you'll hear "put a scope on the network and see if there's anything unusual", but I'd love to see a mug book of bad and good network signals so I can compare.

Anybody out there have a big (or small) DH+ that they'd like to connect to a scope (I can loan you mine if necessary) and post the results ?

Figure 1. Normal DH+ signals.

Figure 2. Unterminated DH+ signals.

Figure 3. 'Blue' conductor shorted to shield.

Click to expand...

Hi Ken

Probably a dumb question, but how did you connect your scope. I am more of an electrician than an electronics expert and not exactly sure how you would go about this. I'm guessing you put one of your channel probes to either the white or blue wire, and the ground attachment to ground, but im not sure.

That's a really good question, because it means you're thinking about the signalling method. I'm not a EE either, so folks who know this better than I do can chime in and I'd like to learn more.

DH+ is a differential signalling system that measures the voltage difference between the #1 and #2 signal conductors. These are usually named by their insulation colors in the standard Belden 9463 cable (blue and clear).

These voltages have to be measured relative to something; they aren't relative to one another, or this would be a single-ended signalling mechanism.

So as I understand they're relative to the chassis ground. There is a high-impedance connection between the shield pin and chassis ground.

DH+ uses Manchester Encoding, which measures the timing of the signal's falling and rising edges. This is one of the reasons that DH+ is so remarkably resistant to noise and bad installations. Sometimes you have to convince longtime users that they have to follow the installation and termination rules because "it's always worked no matter how I install it".

In short, I connected my two scope probes to the blue and white wires and clipped both of my ground alligator chips to the side of the 1771 chassis.

My scope is a 2-channel 100 MHz Cleverscope USB/PC-based oscilloscope. I am looking for more uses for this in the teaching, troubleshooting, and technical selling aspects of my job. I really like its screenshot ability already !

The Good, The Bad and The Ugly

Ken, those are some good traces. I had seen a set of traces from a GTS (or was that a GMS) on my DH+ problem described in this post:



http://www.plctalk.net/qanda/showthread.php?t=10666&highlight=dh+fault#goto_threadtools



AB sent someone out here (multiple times) to try to solve this problem. So far, this problem has not been fixed. During the troubleshooting phase, the AB tech hooked up a sniffer to the DH+ and watched the data stream. The interesting part was when I went to assemble edits, the trace went all over the place. He described it as similar to a data storm. I never did get a copy of the traces but they were very interesting.



Since then, I have more slc 5/04s (over 190 of them) on a DH+ system (15 nodes on a channel) with a contrologix gateway. In this system I was able to duplicate the problem of causing a DH+ communication fault when editing the online program. This system is much different than before in that IFIX is used to gather results (before it is a custom VB application using OPC in RSLinx) and used the ABR driver from Intellution and the TPC driver in RSLinx. This combination causes the processor communication channel to fault when doing online edits. The only problem is that on my original system (which is still chugging away), I don’t have any other driver to use. In addition, that system seems very specific on certain processors that would fault out where others would never (and still haven’t) fault out.



I guess to make a long story NOT any more longer (too late to make it short), I would be willing to try to capture the waveform of the DH+ when performing edits so you can have something “not good” to look at. I don’t have a fancy O-scope that can capture this but the GTS still might have the traces. I can give you his name if you want. If you would like me to capture the waveform, it will probably have to be during our winter (Christmas) outage since it severely affects our production to have to cycle the processor.

Thanks for spending the time to analyze our little problem.

Now I have a good picture of what DH+ SHOULD look like!

Ken Roach said:

This thread inspired me to get out my shiny new Cleverscope and a pair of PLC-5 controllers. I connected their Channel 1A ports together with a 5-foot length of "blue hose" and took scope captures in three conditions: with no terminating resistors in place, correctly terminated with 150 ohm resistors, and with a single tiny "whisker" of the shield touching the blue-insulated "#2" signal conductor.

Often you'll hear "put a scope on the network and see if there's anything unusual", but I'd love to see a mug book of bad and good network signals so I can compare.

Anybody out there have a big (or small) DH+ that they'd like to connect to a scope (I can loan you mine if necessary) and post the results ?

Figure 1. Normal DH+ signals.

Figure 2. Unterminated DH+ signals.

Figure 3. 'Blue' conductor shorted to shield.

Click to expand...

I would like to borrow your scope, I have several plants that I have installed DH+ networks in. It would be interesting to see how they are performing. Or give me the details on the model and the set-up and I'll purchase one.

Hi,

Here are some screen saves of a real life working DH+ installation. The first 2 are a network with 19 nodes @ 57.6K baud. The next one is a network with 36 nodes @ 57.6K baud. Notice the larger network has a slight voltage decrease.








BD