DeviceNet Analyzer Question

Jmeadows7676 · Aug 12, 2019

I have Frontline NetDecoder Software and a 1784-U2DN in hopes of troubleshooting a DeviceNet issue. Randomly we have Nodes that stop communicating with scanner. It's been different nodes almost every time. I would like to use the NetDecoder Software with the 1784-U2DN but i'm not sure on how to tie it in the system once i set the Address and Baud rate. Is it OK to just plug it in a spare tap without putting it in the scan? Does the 1784-U2DN have to be in the Scan? Should the DeviceNet Network be down when i install? Sorry for all the questions at once just a hot item right now.

Thanks for help in advanced.

JLM

Ken Roach · Aug 12, 2019

First, the answers:

You don't have to take the DeviceNet into an idle or stopped mode to connect the 1784-U2DN; it's largely passive and can be connected to any drop that has an available port.

The main thing to be careful of is to get the data rate correct and not duplicate a MAC ID that's already on the network.

The 1784-U2DN and the FTE software do not participate in or interact with the Scanner's Scanlist function, so there's no need to edit or modify that.

Protocol analysis software is best for finding firmware problems in development devices, and not as good at troubleshooting wiring and signal issues.

But it can definitely give you insight into which devices are generating low-level errors and timeouts.

Jmeadows7676 · Aug 12, 2019

Ken Roach said:
First, the answers:

You don't have to take the DeviceNet into an idle or stopped mode to connect the 1784-U2DN; it's largely passive and can be connected to any drop that has an available port.

The main thing to be careful of is to get the data rate correct and not duplicate a MAC ID that's already on the network.

The 1784-U2DN and the FTE software do not participate in or interact with the Scanner's Scanlist function, so there's no need to edit or modify that.

Protocol analysis software is best for finding firmware problems in development devices, and not as good at troubleshooting wiring and signal issues.

But it can definitely give you insight into which devices are generating low-level errors and timeouts.

I was hoping you would chime-in (The PLC.Net Legend MR. ROACH). I'm being told Maintenance is able to reset the Node Error by unplugging then plugging back in the module that is not communicating. Does this indicate what type of issue it could be? Like I said its been different nodes almost every time.

cncsparky · Aug 12, 2019

I had a very similar problem several years ago. Tried many things, but here is what fixed it. I went through each connector on the trunk and tightened the screw fittings. Several hundred, and many were very loose. This required taking each connector apart to get to the screws. Time consuming but very worth it. Hardly any issues since.

Jmeadows7676 · Aug 12, 2019

cncsparky said:
I had a very similar problem several years ago. Tried many things, but here is what fixed it. I went through each connector on the trunk and tightened the screw fittings. Several hundred, and many were very loose. This required taking each connector apart to get to the screws. Time consuming but very worth it. Hardly any issues since.

It's worth a shot.
Thanks,

willxfmr · Aug 12, 2019

This used to be an everyday occurance where I work. The 2 things that helped the most were to make sure to give the connectors an 1/8 turn past hand tight, and to always slap some dielectric grease on the pins and fittings. We tend to spray a LOT of water everywhere, and combined with the chemicals used for sanitation those poor DNet connectors never really stood a chance. Now our biggest problem is operators not understanding that you have to turn the nut and not the connector to remove the cable. To the best of my knowledge, there is no legal remedy for that problem.

Bubba.

Jmeadows7676 · Aug 12, 2019

willxfmr said:
This used to be an everyday occurance where I work. The 2 things that helped the most were to make sure to give the connectors an 1/8 turn past hand tight, and to always slap some dielectric grease on the pins and fittings. We tend to spray a LOT of water everywhere, and combined with the chemicals used for sanitation those poor DNet connectors never really stood a chance. Now our biggest problem is operators not understanding that you have to turn the nut and not the connector to remove the cable. To the best of my knowledge, there is no legal remedy for that problem.

Bubba.

Thanks, I will be sure to check all the connectors.

Jmeadows7676 · Aug 14, 2019

Ken Roach said:
First, the answers:

You don't have to take the DeviceNet into an idle or stopped mode to connect the 1784-U2DN; it's largely passive and can be connected to any drop that has an available port.

The main thing to be careful of is to get the data rate correct and not duplicate a MAC ID that's already on the network.

The 1784-U2DN and the FTE software do not participate in or interact with the Scanner's Scanlist function, so there's no need to edit or modify that.

Protocol analysis software is best for finding firmware problems in development devices, and not as good at troubleshooting wiring and signal issues.

But it can definitely give you insight into which devices are generating low-level errors and timeouts.

So i hook up to the DeviceNet Tap, Open my NetDecoder Software and hit Start Capture. Instance Fail. ("Failed to put 1784-U2DN in Promiscuous Mode") Has anyone ever seen this before or know the problem.

DeviceNet Analyzer Question

Jmeadows7676

Member

Ken Roach

Lifetime Supporting Member + Moderator

Jmeadows7676

Member

cncsparky

Member

Jmeadows7676

Member

willxfmr

Lifetime Supporting Member

Jmeadows7676

Member

Jmeadows7676

Member

Similar Topics