DeviceNet Trouble SMC EX240-SDN2 Module

[BW2218]

I am hoping that someone here may be able to help me with a DeviceNet issue I am experiencing.

Background:
I am working on a retooling project in which we have decided to upgrade a test line from two SLC 1747-L553 processors / chassis / 1747-SDN module combos to a single ControlLogix rack with one 1756-L55 processor (FW 16.23) and a 1756-DNB module (Series B FW 7.1 - has the old manual config pushbutton on the front). In the original design, each scanner was communicating on its own physically separate network. The total number of nodes for the combined network is 39. The original 1747-SDNs were nodes 48 and 49 (no longer on the network as they were removed). The 1756-DNB is node 0 since node 0 did not exist in the original network. Our first attempt resulted in returning the 1756-DNB module that we received as it kept giving us a bus off condition even with a simple network that met specs. We have received another 1756-DNB that is working correctly. The baud rate is set at 500K. There are 11 1794-ADN Flex I/O adapters that all work correctly. The problem we are experiencing is with the 13 SMC EX240-SDN2 adapter modules. They are intermittently dropping the DeviceNet connection and then reestablishing the connection for no more than a second or two before dropping it again. We have reduced the network to a single SMC node coming off of a T tap with an AB terminating resistor at one end and the scanner coming off a 2nd T tap with an AB terminating resistor at the other end. Trunk line length between the taps is approximately 5m and the drops are each under 3m. Resistance CAN-H to CAN-L is between 60.6 and 60.8 ohms. Voltage is 23.9VDC between V- and V+. Voltage between V- and CAN-H / CAN-L is 2.8V for both with the scanner disconnected and only the one SMC node powered on the network. We have tried all three baud rates on this simple network to no avail. Same problem exists even at 125K. I found previous posts here which suggested setting the interscan delay higher. I have tried going as high as 100msec. I have tried changing the EPR from the default 75 to 100. I did this separately and together at the same time. I have cycled power to the rack and the network independently as well even though I didn't see any mention anywhere of needing to do that after changing these values.

At this point, I am guessing there is some sort of incompatiblity that exists between the old SMC modules and the "newer" 1756-DNB module, even though it isn't the latest and greatest one out there. I have called SMC but the guy I spoke to was baffled and transferred me which resulted in an answering machine and me leaving a message which I haven't heard back from yet. I have also emailed. I am hoping there is some kind of firmware fix I can download to the SMC nodes. Absent that, I guess I will be reverting back to the old SLC 500 system with the possibility of combining the two cards into a single rack.

Anyone have any other suggestions?

 

[Andybr]

At this point, I am guessing there is some sort of incompatiblity that exists between the old SMC modules and the "newer" 1756-DNB module, even though it isn't the latest and greatest one out there. I have called SMC but the guy I spoke to was baffled and transferred me which resulted in an answering machine and me leaving a message which I haven't heard back from yet. I have also emailed. I am hoping there is some kind of firmware fix I can download to the SMC nodes. Absent that, I guess I will be reverting back to the old SLC 500 system with the possibility of combining the two cards into a single rack.

Anyone have any other suggestions?

I would be very surprised if there is a compatibility issue. We do not have the same SMC units but we do have quite a few EX124U-SDN1 units on quite heavily loaded systems and they are extremely reliable. We must have around 100 1756-SDN scanners of various revisions in our plant and I cannot remember ever having a failure of any description since we started using them in the late 90's.
Almost all DeviceNet issues I have ever encountered have been down to poor installation. The most common issues have been failure to link the 0v line and shields to ground and reliance on poor quality plugs and sockets (especially the "Mini" type which are prone to issues with splayed female connectors resulting in intermittent failures). You might find the Woodhead DeviceNet Netmeter to be a useful instrument if you have a lot of DeviceNet systems to maintain.

 

[BW2218]

I appreciate the reply. I assume you meant to say 1756-DNB or 1747-SDN. I am not aware of any such thing as a 1756-SDN.

While I don't wish to exude over confidence, I am 100% sure it is not a network issue. As I mentioned, I have reduced the network down to the simplest form possible, at the slowest baud rate possible, with all the proper grounding, resistance, and voltage. The Flex I/O nodes were all communicating just fine before doing that but every single one of the SMC nodes were dropping their connections. The same problem persists at the slowest baud rate on a very simple network setup with just a scanner and one SMC node, so I am confident it is not a network issue. I have since heard back from SMC and they are working on duplicating the problem in their lab. I was told these older SMC modules have never been tested with that particular scanner as it is newer than the SMC modules. If they tell me they have it working perfectly with the exact same hardware in their lab, then maybe I will reconsider the network but I am highly skeptical of that at this point.

 

[Ken Roach]

This might not be solvable without a protocol analyzer.

I don't know the provenance of your hardware, but since you say you "returned" on old 1756-DNB and are building your system with an obsolete 1756-L55 controller, there might be some wear and tear on the wiring and connectors, too.

One of the most frustrating diagnostics I ever did was traced to a nice molded Turck connector that had been slammed in a door and had broken solder connections inside... it looked perfect from the outside.

The 1756-DNB did poll faster in later generations of firmware, but increasing the Interscan Delay should have eliminated any effect that had on the network.

Are the failures really "intermittent", or are they regular and cyclic ? Do the SMC adapters every run for minutes or hours without a failure ?

 

[Ken Roach]

This is a completely wild guess, but I'll describe a similar system problem I encountered once with a third-party adapter.

The I/O connection size in the scanner was incorrect, but the slave device still accepted the connection request instead of rejecting it. The 1756-DNB and the slave started exchanging I/O traffic and the DNB just ignored the fact that the input data frame was longer than it was supposed to be. I never did figure out what it was doing with the extra bytes.

A few hundred milliseconds later, the 1756-DNB got around to checking the Assembly Object Produced Size and Consumed Size attributes in the slave. When it found that they didn't match the scanlist, the 1756-DNB formally closed the Polled connection with a Forward_Close command.

The practical effect was that the I/O connection ran for a short period of time, then broke, then got re-established a few seconds later. Because the scanner got a valid response from the slave when it requested to close the I/O connection, it never had time to display an Error 72 or Error 77 on the scrolling display.

This might or might not be what's happening in your system, but the only way to diagnose it in my case was to get a protocol analyzer on the wire and watch the process happening.

 

[BW2218]

Thanks for chiming in Ken. It's nice to hear from a recognized guru. You are right that the dropped connection was cyclical rather than intermittent.

Unfortunately, I must sheepishly admit complete ignorance on this one. I failed to read through the manual with the assumption that I "knew what I was doing". It clearly states on page 14 that this model has a default dip switch setting which "notifies" the PLC it doesn't have any solenoid power by dropping the connection. Since this switch is in the default position and solenoid power is dropped when control power is turned off, it was cyclically dropping the connection like it is designed to do. Seems like a weird way to "notify" the PLC but I guess if I had read the manual I would have known that. I can only assume it was doing this before with the old SLC system but I am a contractor with limited knowledge of the history and nobody probably noticed it before. Funny that the SMC guys apparently didn't either but they probably assumed I read the manual.

As for the first scanner module, it was purchased as surplus and yes I finally narrowed it down to a bad network connector on the module. It was consistently giving a Bus Off error, but if I wiggled the connector, the scrolling display would kind of "wig out" and give me a combination No RX / Bus Off error. We had a replacement sent and it works fine. Such is life when faced with a nearly $0 budget for controls upgrading.