Phoenix Digital OCM/OCX/OLC Fiber Network

Happy New Year!
I have been dealing with an old existing fiber network for a few months now and totally forgot about bringing it up to the PLC Gods at PLCs.net!

There are 3 existing PLC5s each with an OCM for DH+, 1 existing SLC 5/04 with an OLC for the DH+ and now I am trying to add two ControlLogix PLCs with OCX modules AND DHRIO modules. I can't seem to get the new PLCs recognized on the network.

What seems to be happening is when the network is ALL connected (Redundant looped), the 5/04's OLC somehow cuts out the comm with the HMI (Varec FM, not a very "user friendly" HMI...very proprietary). There is ONE operator working at the site that remembered the "old" way to reset the system when this comm fail occurs...."You just unplug this connector and plug it back in." The connector he unplugs and plugs back in is the DH+ (Blue Hose) connection in the Phoenix Digital module. I think there must be some type of buffer that is instantly being filled up or fault table somewhere in that module. I haven't checked the settings of the dips in that module to find out if it is set for fault detection or trap mode. Reading the PD manual is like..well, you know...its hard to make sense.

My question is:
Has anyone ever used Phoenix Digital modules for a DH+ network? Using a combination of ALL levels of AB products? Are there any pointers I should keep an eye out for or know?
PLUS: Before the ControlLogix PLCs went on the network, I could go into the 5/04 with a KT Card and see ALL of the remote PLCs in RSLinx. If everything is configured and hooked up right, will those nodes just pop up in the RSWho?

Kinda long-winded but I would appreciate ANY help at all-----
----
Thank you,

T.J.

DH+ Help

Hi TJ,

I forget the module types from Phoenix Digital, but I use the stand alone, 1756-Logix Chassis, 1746-SLC Chassis, and 1771-PLC5 chassis types. At one time we had as many as 15 PLCs on one network. Presently, I have a 6 different DH+ networks in service. As a general rule of thumb, we have blue hose and fiber throughout the facility. The fiber is set up on a redundant ring topology. In a single network, I now have 1756 series (OCX I think), Stand Alone type, and 1746 models and don't experience problems. All that I use now are in the 850 frequency, but did have some 1300 models and no problems were seen. The main difference in these are the distance you can transmit over the fiber. I believe that all of mine are operating on a 57.6 kbaud rate. Previously, we used these same units for extensive RIO networks without problems. Have we replaced the fiber units... Yes but I probably had 50 units and the replaced units were more from physical environment problems (e.g water) rather than hardware deficiencies.

Some quick thoughts that may help.
1. Check dip switches on all units and they should match (e.g. Baud and error behavior settings)
2. Check jumpers on the 1756 and 1746 models.
3. Check the ring topology and proper fiber connections. For example if you list your fiber devices around a circle and then look at your CHA cabling. CHA should be transmit to receive Clockwise, CHA receive to transmit counter clockwise and opposite for CHB. This way you have 2 paths to each fiber device.
4. You mention that someone was unplugging a DH+ blue hose to heal the network. I can visualize this because DH+ is a token style network and it heals itself. The way I think of this network is a token that is passed from node to node. The node has to have to token to talk. So if some node is grabbing and not releasing to token, communications on the network stops. There has to be some housekeeping on the network where it broadcasts who has the token. If the token holder doesn't release the token, well you get problems. If you eliminate (power off or drop off the network) the problem node, then the network heals itself and everybody else starts taking again. My guess is that you have a bad network node on the network and the segment that the operator is disconnecting contains the problem node. More of our problems seen with the DH+ network have been a bad SLC504 PLC or a bad PCI slot DH+ module. My suggestion would be to first eliminate any unnecessary nodes/devices on the network. Also, is it possible to break the network into smaller networks and still accomplish what your process requires (e.g. cut your problem in 1/2 and see which new network contains the problem node). Then use RS Who to browse the network and see if you can see any nodes coming and going (red x). Other suggestions would be to get a network data monitor and see who is either creating noise or not responding in a timely way. When it comes to the DH+ PCI cards, I don't recommend 3rd party units (I've simply changed too many of them).
5. Phoenix's tech support has been helpful to me in the past. If you have questions about their manual...give them a call and they can probably help answer any questions and maybe clarify what doesn't seem so clear.

You asked if the nodes would just appear in RSWho -- Yes. Check baud rates on all devices in the network (nodes and PD devices too). Double check the Blue hose termination and proper resistor (based on baud rate) and ensure that someone hasn't swapped clear/blue standard that you use. Before you add new nodes --- be sure not to duplicate nodes. Don't overlook the fundamentals...most problems can be found by reviewing these and ensuring proper cable, cable terminations, resistors, dip settings, etc. If it were me, I would probably be tempted to jump to the PCI card in the PC for our proprietary HMI and start there. I don't like to badmouth manufactures, but we had not so good of luck with those made by SST. If you have an extra 1 change it and see if your behavior changes..

If you are in need of some stand alone 1300 frequency units or 1771 chassis units, let me know.. I've got some that I would like to move at about 25% of replacement costs.

DH+ Madness!!!

Marvin,
Thank you for the suggestions. I have gone over the dip switch and jumper settings many times now. What I am fearful of when talking about those settings is that I tried something (when looking at the manual or just plain guess and check troubleshooting) and maybe forgot to get it back to the setting it was.....Yeah, I have spoken with PD's support and Joel there is VERY helpful and from everything he is telling me, I should be OK...

When you say that one node may be "holding" the token, do you think if it holds on to that token once it will do it again if I put it back in the network? I ask that because that is what I seem to be experiencing now. Just like you suggested, I made a smaller network of my two new 1756 nodes and one older 1771 node. As soon as I pulled the blue hose from the PLC5 CPU ChA port, I was able to get "A OK" on the ControlLogix DH/RIO modules. Meaning they could see another node on the network. Then, I could pull up RSWho and see one from the other and vice versa. So, we left the PLC5 CPU OFF the network and came back a day and a half later and the two couldn't see each other again. I don't know what would have caused the network to just drop out unless like you were saying, one node stole the token and kept it...but that would mean the new 1756 nodes would have done that.

We also just found out that the fiber used in some "spots" is rated for INDOOR USE ONLY. I don't know how they have gotten along this far but I have a feeling THIS could cause some intermittent problems too....would you agree? I have asked the electrician to verify the fiber network points and test each strand. He said he did and provided me with a ****tail napkin sketch of "most" of the network's fibers.

All in all, I think I have to put the ball back into the electricians court and have him get me a verified drawing of the ACTUAL layout of these fibers.

As far as the 1771 chassis units you would like to sell....yeah, we had replaced ALL of the PD modules in this network when we started so we too, have extras...

Take care,

T.J.

DH+ Droppouts

Hi TJ,

I'm guessing that the DH+ network has several fiber patch points between two adjacent PD modules. If this is correct, then your fiber testing should include all fibers from PD TX to PD RX terminals. Why? There is a spec that only allows so much dB loss between two fiber points. Exceed the spec and results vary. I like to put the fiber together how I intend to use it and then test the complete segment so then I am able to test the losses in all cables, couplers, terminations etc as a complete piece so that I don't exceed the spec. If you do exceed the spec then break up into smaller pieces to see if you have spares to juggle into your mix.

Fiber points to review
1. Use 62.5 multimode fiber throughout. Don't mix 62.5 and 50 fibers.
2. Patch points. Be sure to allow for thermal expansion/contraction and long bend radius on conduit. I'm thinking of a patch point where you have 2 ST fiber ends joined by a coupler. If you stretch this then your connection changes. Allow for a couple loops and strain free coupler locations
3. Indoor vs outdoor fiber. This really applies more to the outer jacket of the fiber cable. If the outer jacket has been damaged due to sun or moisture, then I would agree that this could cause problems. As a general rule, fiber is pretty tough, but once it is fractured, your done.
4. A good drawing is priceless. It would be good to try to get some idea of distances. The 850 has a shorter range than the 1300 frequency units if my memory serves me. This may be worth reviewing the spec on vs your application.
5. Patch panels/points....loose connections, poor or fractured terminations, somebody in the panel to physically move and possibly disturb????


My experience with the PCI PC DH+ modules.... I have had 4 in service over the years. 3 presented problems similar to what you describe and were SST units. I was never completely clear if this was a hardware problem or not, but it would cause delays on the network and unplugging them would "heal" the network. 3 of the 4 of these were solved by isolation to a stand alone network to a "bridge" PLC where this bridge PLC's only purpose was to send data to the problem children nodes. Fortunately, we only needed a few words so there wasn't much involved in programming and testing. I eventually changed the driver to an ethernet OPC driver and haven't had problems since. The 1 that is still in service without problems is a RSView32, SLC504, PD stand alone, PD 1756 style, and 1756-DHRIO module. The PCI card is an AB card and not SST.

The SLC 504's that I've had "fail" causing intermittent problems on the network or no connection at all on the network were solved by replacing the controller.

If your network consisted of PD units and (2) 1756-DHRIO modules and you are having dropped network, I would focus on the physical installation of the network for a close review. Then you may try to use the other DH+ channel on the 1756 modules (there are 2). If you have a Logix on each end, write a program to message some data back and forth over this network and see when it is failing (time, temp, ??). This may point you to test fiber strands at a different time to catch the extremes.

Hope it helps. These get to be frustrating problems.

Can anyone recommend an alternative to the Phoenix Digital OCM? We have 4 units which are 20 years old and are experiencing alot of intermittent outages and want to consider replacing them with something else.

These would be nodes to connect the fiber to PLC-5s on DH+.