SR-1000 Reader with L62 AB Processor

So I'm trying to do Ethernet/IP communication from an Allen Bradley L62 CLX processor to an SR-1000.

I have checked the switch port configurations and went through all cabling with a fine-toothed comb.

I can ping both devices fine. The PLC and RSLinx can see the Barcode scanner, but I keep getting "connection reset by peer" inside the drive diagnostics.

While online with the PLC it is telling me that the IO is not responding.

Under the module properties status it says "Status: Connecting" and then switches to "Status: Faulted"

I went through with Keyence tech support and verified the settings. We added as a generic ethernet module and used the following settings:

Input: 100 Size 100
Output: 101 Size 100
Configuration: 1 Size 0

The module info says there is an identity mismatch and gives an internal state of 16#0034 however it does see the revision, serial number and product name just fine.

I'm pretty stumped on this one and Keyence support just said "Sorry we can't help you, it is an Allen Bradley issue."

Sparkie.
I REALLY hope I am not leading you astray here but, a few weeks ago I had a similar issue when adding a pair of anybus modules to 2 Rice Lake scale heads. I added them as generic Ethernet modules and I saw "almost" what you are describing on one of the units and one of them worked fine. I went over it just like you did piece by piece, Rice Lake went over it piece by piece. In the end, they determined that instead of adding the module to the PLC in the form of a generic Ethernet module I should try "against the manuals direction" to install the modules in the project using the EDS file as the module profile. When you go to add a device, instead of clicking the generic eth option, I simply found the EDS file in the list of available profiles and added a new module of that type. Immediately I had both scales communicating and there were no more mismatch errors and my status became "connected".

Again, I hope this pertains to your issue. I just wanted to mention it as I had not thought that I could add a device by way of the EDS file. I only thought EDS was used by Linx.

Thanks

Thanks so much for your help! I have kept working on this. I have also tried both methods for adding the scanner.

Something fishing I noticed. I'm using two 1756-ENET/B Modules with firmware 2.6.

I also noticed that on two separate and completely different types of smart switches they are negotiating a port speed of 10mpbs/half-duplex. This could EASILY cause issue with any kind of IO, as in the linx drive diagnostics I can see the connection being made and then terminated. I'm going to see what can be done about that first and then I will update.

I'm still open for suggestions from someone that may have had this issue.

This configuration always works for me

Yea, it seems the scanner isn't at fault here. I walked through it with Keyence and they gave me the same settings.

Now I'm guessing it is some kind of problem with the PLC.

I'm not sure if we can do this with a 1756-ENET/B or not. It is supposed to accept Ethernet/IP connections.

I wouldn't be surprised if the device had not been tested with the 1756-ENET/B... those were superceded by the 1756-ENBT at least 10 years ago. While they ought to create and run an I/O connection in the same way as a 1756-ENBT, there might be an issue in the older module's firmware.

And the 1756-ENET/B was always a 10 MB, half-duplex device. The 1756-ENBT was the first full duplex 100 MB interface for an A-B controller.

What firmware revision of what ControlLogix CPU are you using ?

Try removing the I/O object from the I/O tree completely, exporting as an *.L5K, and re-opening the project. Then, add the I/O object to the tree again.

That identity mismatch code is tingling my spidey senses... there shouldn't be any identity checking for a Generic Ethernet Module object.

On second thought (and a review of some old threads) I think that the identity mismatch text shown in the Module Properties screen is normal, because that's the value if there is no identity check. The problem I was thinking of happens when there's a static "identity mismatch" fault in the I/O object.

Watch the module status closely to see if it's rapidly cycling between "establishing" and "faulted" and "closing", or if it's just in one state.

Watch the module status closely to see if it's rapidly cycling between "establishing" and "faulted" and "closing", or if it's just in one state.[/QUOTE]

This is what it is doing.

Connecting
Validating
Faulted

And a cycle like that mostly.

Try it with a 1756-ENBT or newer module.

It is too bad we don't have one. I'm submitting a PR for one now. All of the modules we have are these old ENET/B modules.