Generic ethernet module not showing in rslinx

[saultgeorge]

Hi, folks. I searched the forum for this topic before submitting a new post, and the only thread discussing a similar issue like this the OP was using a VM. So if I've started a needless thread, please let me know. Thank you.
I have studio 5000 v. 28 and an L73S processor. I'm using Point I/O if it makes a difference. Everything is going through a Hirschmann switch which is unmanaged.
I've added a generic ethernet module for a COMAU robot controller. RSLinx will not see the device in the who active tree under the ethernetI/P driver. I can ping the device. The error is connection timed out. If I configure an ethernet devices driver, Linx sees it for a minute or so and it has a yellow question mark. I'll right click and try to go to the menu to upload the EDS file, however it won't respond and then goes to a red X.
All this hardware is under an EN2T module that is station 02. Do I need to put this in the ethernet devices driver as a station? I think that's what help said, however I'm not real clear on this as I haven't used this driver much. The robot folks say their end is good. I don't know that I'm 100% sure on this, but for now I need to communicate with this module and get it to normal running status. This is a new training cell and a used controller that was working in the plant.
As always, any help would be appreciated and I thank everyone in advance!!

 

[JTCat]

Have you tried using the ethernet devices driver instead of Ethernet/IP?

 

[saultgeorge]

Have you tried using the ethernet devices driver instead of Ethernet/IP?

Yes, I have. That driver will show the module IP address, however it will revert to a red X and not let me either upload the EDS file or enable the comms to it. Thanks for a speedy reply.

 

[passwordg]

Would you mind posting screenshots ?

 

[saultgeorge]

Would you mind posting screenshots ?

The screenshot of the ethernet devices driver configuration page show the laptop .240 and the EN2T Module .130

 

[Ken Roach]

The robot folks say their end is good.

Finger-pointing is as old as pointing, but not as old as fingers.

Two troubleshooting recommendations:

1. TCPing. This is a command-line tool that probes for TCP connectivity by requesting an ordinary TCP Connection on a specific TCP Port. EtherNet/IP devices will always accept a TCP connection to Port 44818.

If the device doesn't respond to TCPing on Port 44818, then it's not configured or operating correctly.

2. Try entering the Station address in the Ethernet Devices driver as "192.168.1.144:44818".

This skips that driver's attempt to probe for the old proprietary Allen-Bradley CSPv4 protocol on TCP Port 2222, and lets it go straight to Port 44818.

Since you are seeing other devices, especially on the EtherNet/IP driver, you probably don't have a firewall or VPN or multihome network setup that is preventing your computer from making this connection.

 

[alive15]

You can try creating a brand new driver for ETH-1 and ETHIP-1. Also, have you tried going to configure drivers, and stopping the driver, then restarting it back up?

 

[saultgeorge]

Finger-pointing is as old as pointing, but not as old as fingers=

Ken
Thank you for your reply. I tried all that you suggested. The station address in the ethernet devices driver won't accept any more places except for the IP address, and TCping didn't seem to work either. I may not understand that really well.
The robot folks have now decided that the software set-up wizard may need updating, plus they're not sure if the controller needs 2 layers of IP addressing, and I don't know. There is a PLC icon on the teach pendant. We went over to the plant to a working cell and that icon is green. The one on ours is red. There are 2 IP address configuration "pages". One says EthernetI/P and the other is just an address page. The working cell has both configured; however I'm thinking that we don't need the one because we're not using a managed switch.
Anyway, we've been pulled off this particular problem in order to get a nearly complete FANUC cell up and running at our training facility. I'm now fighting to remember Dnet configurations to get the safety gate working. I have some good manuals for that. It's been a while, and the last time was 3 years ago and Dnet was 95% running. I like a challenge. Thank you again for your reply.

 

[saultgeorge]

You can try creating a brand new driver for ETH-1 and ETHIP-1. Also, have you tried going to configure drivers, and stopping the driver, then restarting it back up?

Hi, yes thank you for reminding me of that procedure. I tried that several times to no avail. I'll keep plugging away and get it done. Thanks again for all your help. I'll let you folks know what is was when I get it running, perhaps the solution will help others.

 

[jdbrandt]

I'm using Point I/O if it makes a difference. Everything is going through a Hirschmann switch which is unmanaged.

Why, oh why, do people ignore the note in Rockwell's manual that directs that you must use managed switches if you network contains non-Rockwell E/IP devices.
I've never understood how people think they know better than the manufacturer, in this and other cases.
And, FLAME_GUARD::=ON, yes, I agree with the view that you can get lucky and used unmanaged switches, and nothing bad happens.
FLAME_GUARD::OFF

...until it does, and someone says "hey, lets try a managed switch"

 

[saultgeorge]

Why, oh why, do people ignore the note in Rockwell's manual that directs that you must use managed switches if you network contains non-Rockwell E/IP devices.
I've never understood how people think they know better than the manufacturer, in this and other cases.
And, FLAME_GUARD::=ON, yes, I agree with the view that you can get lucky and used unmanaged switches, and nothing bad happens.
FLAME_GUARD::OFF

...until it does, and someone says "hey, lets try a managed switch"

Hi, Jeffrey thanks for the response. I neglected to say that this is a training cell/system as it were across the street from our assembly plant. It is not on the plant network as far as sending data to other sections of the process or providing data to FIS. It a stand-alone system with no comms leaving the building either hard wired or by WiFi. So no worries about any compromises.
With that said, I didn't know about the Rockwell requirement that you referenced in your reply. I have only worked with managed switches. I can certainly add a switch into the I/O and configure it. When I get back to it here in a day or two I'll try that. Thank you for your response and time.

 

[Ken Roach]

The station address in the Ethernet Devices driver won't accept any more places except for the IP address

I checked to be sure, and it looks like the developers have either removed or hidden that feature; you can type it in but it disappears. Hopefully they also fixed the underlying function that made it useful/necessary.

TCping didn't seem to work either

Try TCPing on a device that you know appears in RSLinx, like a ControlLogix. That will prove that TCPing is working, and allow you to infer that the other target device is not configured correctly.

The rest of the configuration issues on the robot side suggest that it is not in fact configured correctly to enable EtherNet/IP. It's great that you have a running system to compare it to, and I appreciate you posting notes and updates for other users who might run into a similar situation.

 

[jdbrandt]

I thought that, for sure, somebody would have suggested using System Ferret, but I guess only us Old Timers use that old software.
It sure does end all of the discussion, in a big hurry.
Of course, you need to know the MAC code of the troublesome device, and it has to actually be on the network.
(And, apparently, System Ferret is not well behaved, insofar as our Propeller Headed friends are concerned.)