DH+ Network Issues

[lxman]

Howdy All,

I am currently in the UK and am trying to replace an old PC based HMI. The original PC had a 1784-KTX which communicated to a PLC5/40V Rev. B Series E Enhanced over DH+ at 115200 on channel 1B. Communications were ok with the old setup, but the HMI had some issues which I needed to correct. The old PC was running NT 4.0, so I grabbed the source for the HMI and set about to replace the PC.

I purchased a 1784-PKTX, bought a cheap desktop unit and set it up with Win2K and set to work. The program modifications went well, the card plugged in and Windows recognized it, installed the driver, etc.

Then I came to the customer's site. On trying to connect to the existing "blue hose," I am having issues.

On the 1784-PKTX 3-pin phoenix connector I hook up pin 1 as clear, pin 2 as shield and pin 3 as blue. On the PLC5 end, I hook up with the same connection. Here's the rub. Whenever I plug into the PLC5, the green LED stops flashing (just stays off). As soon as I unplug the phoenix, it starts flashing again. I have tried swapping blue and clear, running blue to pin 1 on one end and to pin 3 on the other end, using 82 ohm resistors on both ends, using 150 ohm resistors on both ends, mixing, matching, swapping, etc. I cannot get this to work with the existing cable.

OK, not one to be defeated, I took the PC over close to the PLC and made up a short cable. BINGO! Now I can communicate with the controller. So, I presume that the issue is the cable and inform the customer that he will need to replace the cable in order to get his new HMI working. I depart into happy land and begin planning my return to the other side of the pond.

Well, this AM, I get a call from the customer. Now he informs me that the short cable will not even work, and he is seeing the same symptom. When the cable is plugged into the PLC5, the green blinking light stops blinking and goes dark until the (short) cable is unplugged.

Alright, I call AB tech support locally, and the technician I talked to sends me a tech bulletin excerpt and tells me that I need to hook up the following:

1784-PKTX end
1 Clear wire
2 Shield
3 Blue wire

PLC5 end
1 Clear wire
2 Blue wire
3 No connection

OK, I'll try this, but it seems a little confusing to me. I thought a DH+ connection to a 3-pin phoenix was the same wherever you were on the network.

Well, any further ideas from anyone on what could be going on?

Thanks much for your help.

 

[SNK]

How many nodes are on your network?
Are you on the high-end or low end?
Is your network terminated properly at the end of address? (the resistor)
There are quite a few things that need to be looked at, but basically you are allowed up to 64 nodes,
Termination resistor required,
How much traffic does your "New" HMI require to process?

 

[craigsimon]

Pretty basic here, but make sure the node addresses are not conflicting with each other.

 

[Oakley]

Make sure that your PKTX is set up to the correct baud rate.


Are you using a PKTX/A or a PKTX/B? What is the voltage of your PC motherboard? It will either be 5v or 3.3v.

 

[Mickey]

Just little confused about one thing. You said port "1B" on your PLC5/40,
that port by default is configured Remote I/O. It can be reconfigured as DH+. Double check the offline file and see how the port is configured.
See pic below for wiring. All three wires need to be connected. Note lables on terminals of the PKTX card and the PLC. The positions are the same but lables are different.
Resistors are required of course ( 82 ohms for your baud rate)

 

[lxman]

Excellent responses!

Let me try to iterate these point by point.

SNK

This particular connection consists of the PC, a cable and the PLC5 on the other end. Two of the other ports are used for RIO, 2A and 2B, but they are separate cabling, etc. I don't believe they interact in any way with this single DH+ run. As far as termination resistors, I've tried with, without, 82, 150, mix-n-match . . . I realize that it should properly be 82 on each end between blue and clear, but I'm just trying to make the darned thing work. As far as data points, it's minimal, probably 150 or so data points total.

craigsimon

PLC is node address 25, my PC is node address 77.

Oakley

Checked baud rate on the PKTX. It is set to match. Your second point raises a flag with me. I have searched and found a couple of vague references about PKTX cards and a 5V and a 3.3V PCI bus and compatibility issues. When I bought the card, I called Rockwell tech support and asked them whether that would be a possible issue. The tech I talked to said he didn't think that it would. I don't think he really even knew what I was talking about, to be honest. So that sounds to me like a possibility. I do not remember the series of card (I think it was A, I won't know for sure until tomorrow). But if it was a 5V card and it had been installed into a 3.3V slot, could that produce the issues I am seeing? If the card required a 5V bus and it was installed into a 3.3V bus, would the card even activate? Wouldn't you see issues with the computer not even recognizing the card and the card not being able to communicate with RSLinx? Anyone have experience with that?

Mickey

Thanks for the pics. That would seem to support my original supposition that the wiring on DH+ to a three-pin phoenix is supposed to be standard (i.e. clear, shield, blue). And, yes, checked the port 1B configuration on the PLC5 and it is set for DH+, 115200 baud rate.

Thanks all for the thoughts.

 

[Gil47]

My number one guess is that you have a network that has terminating resistors on the ends and you are connected to a drop link from that network, on a cable exceeding, I think max is 20 meters (66 feet)

I have also seen a similar reaction on DH+ when some one inserted a third terminating resistor in the middle of the DH+ cable 300 meters one way and 500meters the other, this made 3 resistors on the DH+ network.
Each end worked at times but could not get traffic past the middle resistor.

On another occasion the DH+ network was plugged into an RS 232 port on a laptop causing issues, which pretty much stalled comms.

 

[cjawood]

Hi, my first post :}
you might try changing the Baud on the plc.
I dont see how it worked before at 115200.
Remember DH+ only runs at 57.6kbps.
and is quite stable at 57.6.
DH+ requires terminating resistors at the physical network cable ends. These resistors must be 150ohm resistors.
also you might try to change the adress to a lower number.
The maximum node address for DH+ is 77. That is 77 in OCTAL format. With octal DH+ addresses from 00-77 available you have a total of 64 unique address numbers.
hope this helps

 

[Mickey]

Hi, my first post :}
you might try changing the Baud on the plc.
I dont see how it worked before at 115200.
Remember DH+ only runs at 57.6kbps.
and is quite stable at 57.6.
DH+ requires terminating resistors at the physical network cable ends. These resistors must be 150ohm resistors.
also you might try to change the adress to a lower number.
The maximum node address for DH+ is 77. That is 77 in OCTAL format. With octal DH+ addresses from 00-77 available you have a total of 64 unique address numbers.
hope this helps

The above statement about baud rate is only true for channel 1A (dip switch settings) On older uints. Newer ones can also be 230kbps
The rest are software configurable, see pic below

 

[cjawood]

sorry,
I thought that the DH+ used 57.6.
I looked it up and found A 230.4 kbaud DH+ network needs to be terminated with 80 Ohms resistors.
What ver. rslinx are you using?
There might be a hotfix for it.
Here is one for RSLinx 2.50 - Intermittent communications on DH485 and 230kbaud DH+.
http://rockwellautomation.custhelp.com/cgi-bin/rockwellautomation.cfg/php/enduser/std_adp.php?p_faqid=34187&p_sid=IjLEqf8j&p_lva=22199

 

[lxman]

True Mickey

And, I have discovered a little "trick" along the way.

I have always assumed that channel 1A was preset to 57.6. However, the other day, I ran into one where 1A was set to 230.4. I played around a bit and figured out how to change this channel. To do it, you have to temporarily set channel 1A to be an RIO channel. THEN you can change the speed. After you have changed the speed to what is desired, change back to DH+ and the existing speed is "locked in."

I'm sure others knew about this, but it's the first time I've figured it out.

Of course, I'm sure this is probably only applicable to newer vintage processors.

 

[lxman]

RSLinx version

RSLinx version is 2.51

 

[SNK]

But have you solved your problem?

 

[lxman]

Not yet

I will be returning to the customer site tomorrow. I spent a good bit with AB tech support this afternoon discussing the situation (I got someone who seemed to know what he was talking about this time). After discussing the ups and downs, they are leaning towards a defective PKTX card. I am going to try a few other experiments to work this out. If I am unable to resolve it, I am getting an ethernet to serial adapter. I'll just hook to the channel 0 and DF1 over the info I need @ 19.2K. It's not the most glamorous solution, but it's a fairly simple HMI, so that should be sufficient.

Any further discoveries and I'll post them here.

 

[lxman]

Further Info

For those who may still be following this thread:

It looks like it's a bad 1784-PKTX card. As a final diagnostical act, I took my laptop with its 1784-PCMK, and hooked to the end of the cable that hooks to the HMI PC. It communicated fine. The setup of the PKTX card was recognized by the computer and RSLinx sees the PKTX card just fine (It will configure it, etc.). The only remaining link that appears to be possible at this point is the DH+ part of the PKTX card itself.

Through talking with AB tech support, I have been able to discover that there was once an issue with the newer 3.3V PCI busses and the older PKTX cards. But since this is a rev. B card, it is supposed to be compatible with 5V AND 3.3V PCI bus.

AB is shipping me out a replacement tomorrow. I'll replace it and hope for the best. I also have my serial/ethernet adapter in hand, just in case.

Thanks all for the suggestions and I'll post once more with the final result tomorrow.