AB Point I/O responding slowly Code 16#0204

Hey everyone. It's late on a Friday and I need some help. My Point I/O modules are connecting very slowly. They are connected through a 1GB fiber switch to my main rack. I'm getting connection request errors in the program, but I can get to the webpage of each point I/O AENT.

Don't know what to do.... PLEASE HELP!

What AB ethernet modules are used? How many point IO or AENT's are in the system?

The error 16#0204 is a timeout, rather than a connection resource or keying problem, so there is probably a physical issue here.

With Ethernet systems you always have to evaluate the logical capacity of the modules involved (TCP and CIP Connections) as well as the physical connectivity of the devices.

Describe more about your system. Ideally, post the *.ACD file.

Any information to add, Calvin ?

Guess that goes back to your reason #6 on replies

Similar problem

Well, I'll add another system to this thread. Our company is starting up a system with over 180 Control Techniques drives with ethernet modules. Controllogix rack has two L64 processors with an EWEB for public connections (7 HMI's) and 6 E2NT modules assigned to drive groups. Hirschmann managed switches (MICE racks) are used to direct the ethernet traffic. There are approximately 16 point IO racks (AENT modules). Everything is set to 100mB. The drive response from the PLC view is very slow with less than half the system currently active. We have concerns on response time when the whole process is running. Most drives run conveyors and response is not critical but communication faults occur regularly with the drives (I believe timout faults). We are looking at the .pkg files for the drives for problems. This company dictated the hardware for this project but does not have a system this large so it is new territory for them. Any suggestions for setup and/or critical parameters to adjust?

How are your Switches configured?
IGMP snooping active?

Think you might need to start by counting connections

As original poster did not respond, I will add comment about swhite65 system:

First off: for system of this size, did you get approval from your local RA solution architect before buying components? You should. If you did not, then this is your mistake.

Next, based on this thread you started in November http://www.plctalk.net/qanda/showpost.php?p=243886&postcount=3
you had L63 controllers, why now you changed it to L64? If because "program does not fit", then this was mistake.What is your scan time? What SOTS set for?

Next, count connections like TW recomended.
I am not sure how you layed out your I/O, but you can be easily at the limit. In any case with this amount of I/O and comms and unconnected buffers at defaut it will take some time to establish all I/O connections. Did you try to increase unconnected buffers?

Now about error 16#0204:
if all above looks OK, did you try to do traffic cature at the switch port AENT connected to? You should see controller requests to establish connections.
If you don't know how to do it, then you have no business to set Ethernet system of this size. I am suspecting that connection open request not routed by switches correctly. IGMP snooping has nothing to do with this, error 204 indicates that connection was never open (it is done via TCP and IGMP snooping is for multicast). But you may have VLAN set incorrectly and it can block "forward open" requests.

swhite65 said:

... Hirschmann managed switches (MICE racks) are used to direct the ethernet traffic. There are approximately 16 point IO racks (AENT modules). Everything is set to 100mB. The drive response from the PLC view is very slow with less than half the system currently active. We have concerns on response time when the whole process is running. Most drives run conveyors and response is not critical but communication faults occur regularly with the drives (I believe timout faults)....

Click to expand...

I observed something similar recently, though on a somewhat smaller system. At least part of the problem was that the drives (PF40) and the point I/O were set to 100 Mb full-duplex and the Hirschmann switch was set to auto-negotiate. This resulted in the switch identifying the connections as 100 Mb half-duplex and it was logging high volume collisions on all connections (although they all functioned). Setting everything to auto-negotiate got rid of that problem.
I also noticed that I/O adapters were rejecting a high volume of packets, in spite of active IGMP snooping. Turned out there is another setting in the switches to allow forwarding unrecognised multicasts to all ports. Disabling that feature cleared up the rejects. The site normally uses the Mice switches and I haven't noticed that setting on them - this system was supplied by an OEM and came with Hirschmann Rail switches.