Devicenet close connection on a node?

Hello, anyone really good with devicenet protocol? I've been troubleshooting an issue with a certain node on a network going down but recovering quickly; I'm wiresharking the data frames. I caught an event where I see a close connection service being initiated by the devicenet scanner card (1756-DNB rockwell) out of the blue. Any one have any ideas as to what may cause this service ?
picture:

https://imgur.com/a/jbcdpkz

thanks!

Most of the DeviceNet issue I've run into are cabling not following the design rules. Have you validated the design of the network with respect to trunk and drop lengths and termination?

The usual culprit is a polling timeout; you'd have to see the preceding Group 1 and Group 2 traffic associated with Node 7 to see that.

In general you'll see the Master sending out four Poll output frames (Group 2) without seeing any Poll input frames (Group 1) from a particular slave before the master will declare a Timeout on the I/O connection.

You see a "poll response" right there in the frame that you've marked as OK. But you'd have to check the time between that "poll response" and the previous one and be sure it's faster than 4x the RPI.

What make and model of device is the slave ? Is it ODVA conformance tested ?

What software are you using to capture that data ? I presume it's not really Wireshark.

In my experience, D-net is about as stable as a teenager that just got dumped by their first true love. If it is not throwing a hissy fit right that second, don't look at it, don't talk to it, and do your very best to not touch it, or the calm you are currently enjoying will quickly go away.

With that said, if this is an established system that has some miles under it, then the most likely cause of the problem is a cable, hub, T fitting, or some other connection point has gone bad or gotten damaged. The trick is finding the one that is giving you issues, and not assuming that the device that is faulted is indeed the one that is causing the problem.

If this is a new system that still has that new cable smell to it, then rechecking the backbone wiring is certainly a good idea.

Turck has a good troubleshooting guide that you can get from here.
http://pdb2.turck.de/repo/media/_us/Anlagen/G1001.pdf


Bubba.

Followup: I did not recognize the layout of the dissector/analyzer, and I admit that today is the first time I've learned that Wireshark has a DeviceNet protocol dissector that can work with a CANBus interface.

That's pretty cool.

It's probably not as good as Frontline Test Equipment's suite, but it's definitely something I'll look at next time I have to diagnose a DeviceNet protocol issue.

Mugged99: If you have the .PCAP file, zip and post it.

Hello jstolaruk, yes almost all the physical media has been swapped out save for a few things. It's not a big network.

Hello willxfmr, yes I've been using that Turck Tshoot guide, it is rather good but hasn't given me any clues. All device transceivers seem to check out, voltage levels, resistances, etc all check out. I am at the bottom of the rabbit hole now that I'm looking at individual data frames.

Hello Ken, yes about wireshark however that's not what I'm using. I have a 'CANalyst-II' device, that has a dnet script available in its' software but is actually just a generic CAN bus analyzer. It's chinese built and its cheap but it gives me wireshark-like data.

Anyway, looking at the timestamps I have:
-millisecond 407, node 7 response
-ms 412, node 7 response
-ms 434, node 7 response
-ms 467, node 7 response
-ms 473, node 7 response
-ms 497, node 7 response
-ms 507, close connection service request
-ms 507, close connection service response
-ms 525, node 7 response
-ms 531, node 7 response

My EPR is the standard 75 ms, however this particular node is a Rockwell safety block (1732 type) and so has a corresponding RPI setting in the I/O tree of the PLC, which is 30 ms for input, 60 for output.