In this edition of “Community Q & A” (formerly “Insight's Inbox”,) I discuss with one of our community members at automation.locals.com what might be causing one of his Data Highway Plus devices to keep timing out.
Note: To see a list of all our Data Highway Plus videos and articles, click HERE.
I'm having an issue that I hoping you could help with. I have DH+ communicating with multiple PLCs and HMIs.
I also changed out communication card on back of PVPlus but the issue remains. Also of note, the SLC 500 in question is not timing out with other PLCs on the network?
What else can I try? This set up has been working for years up to a couple of days ago.
Any suggestions will be greatly appreciated.
Good morning and thanks for posting your question.
Since the system has been running for a number of years without issue, it's likely to assume it's not a network wiring issue, however let's review some things to check just to be sure:
- Data Highway Plus should always only use Belden 9463 (or the Rockwell brand-labeled version, 1770-CD)
- All connections MUST only be daisy chained. This means absolutely no T's or Y's or Stars. The only exception is that you can use the official 1770-SC box to add a T to the network, but you must follow the strict instructions that come with it.
Note: I've personally seen new T's, Stars, and Loops added to a DH+ network that resulted in timeouts of devices on the network.
- You also MUST have a resistor between the clear and blue wires on each physical end of the daisy chained network. Depending on your network speed, those resistors are either 150 ohm or 82 ohms. While you can get away without resistors on a short network, you will run into issues without them on longer networks.
Note: All devices on the same DH+ MUST be set to the same network speed.
- Finally, it's also important to check for frayed and loose wires since this can also cause timeouts.
Following all of the above wiring rules, you should be able to eliminate any network wiring issues.
In fact, back in the 90's I had an integrator use these same rules to not only eliminate timeout issues, they were also able to get reliable communications with a network that exceeded the supported length by 2,000ft!
Once you review all your network connections, and feel that your Daisy Chain of Belden 9463 is pristine, it's time to look at the hardware.
If you physically replaced it and the replacement has the same issue, the first thing you could try is just replacing the DH+ wire running to it.
You could also try to see if the PVPlus worked when it was just the SLC-500 and PVPlus connected together. It they work when they are the only devices on the network, you can feel confident the hardware is working but there's an issue with the overall network. In this case you'd want to go back to the first part of this post and review the network wiring.
Some other issues I have often seen on Data Highway Plus networks is a lack of bandwidth.
For instance, sloppy programming of MSG instructions can “overload” the capacity of DH+ network. This often happens when PLCs on the network have their MSG instructions set to continuous, or when PLCs have multiple MSG instructions firing at once (instead of interlocking them.)
Another issue I've seen is PanelView programs that try to read data quickly from all over the data table of the PLC-5, SLC-500, or MicroLogix. Note that on DH+ data can only be read in consecutive blocks, so if your project is trying to read tags from all over the data table (N7:0, F8:0, N21:0, F22:0, etc,) each tag will require an entire packet. This is as efficient as sending a bus to pickup one person.
So I always tell my students to avoid reading from addresses located all over the data table of a PLC-5, SLC-500, or MicroLogix, which is also know as the scatter tag approach.
In those situations when the PLC Programmer has not done a good job organizing his data, network bandwidth can often be saved by using the COP and MOV instructions to reorganize the data you need to read into a new consecutive block of addresses so they can be read in large blocks by a single packet.
Note that this is mostly an issue with the legacy PLC-5, SLC-500, and MicroLogix. As I teach in my courses, Logix controllers actually do the work of building the data packets (aka Trend files) to be given to the HMI.
One last issue I want to mention which is rare but should be avoided. In the past you could overload the PVPlus communications by assigning a lot of unneeded devices in the “Target/Device” tab of the RSLinx Enterprise Communications Setup.
Often designers will do an online browse when setting up their shortcut, and then copy the entire online browse to the Device/Target tab. This can cause the PVPlus to try to connect to all those devices, even if there are no shortcuts for them, thus slowing the PVPlus down and filling the network with traffic.
So whether it's too many MSGs executing too fast in your PLC's, too many scattered tags (or tags being request too fast) in the PanelView Plus, or too many unneeded devices in the communications settings in the PVPlus, any of these could be eclipsing the bandwidth of your DH+. But I'd consider these as secondary issues to actually checking the physical wiring of the DH+ network.
Hope this helps – please let us know what you find,
That was a big help!
I found out that they have added red zone to our system while I was out for a couple of months, so our DH+ has been extended beyond its limits.
For now we have taken the cooler out of the communication net work to standalone, and so far no issues. We are looking into splitting the line to 2 part communications to hub back to our main system.
Thank you again!
If you have a question you'd like me to answer, please don't hesitate to post it to me at https://Automation.Locals.com.
- Top Ten Podcast Episodes - October 18, 2021
- Siemens S7-1500 Advanced PLCs Overview (P80) - October 15, 2021
- First Look: Retroreflective Sensor with IO-Link, Pepperl+Fuchs OBR7500-R100-2EP-IO - October 6, 2021