Slow Ethernet Comms

[Colin Carpenter]

I wonder if anyone can help with this problem.

The PLC is an old Q2AS-S1 with an ethernet module in the rack and this PLC is communicating with three Beijers screens - two E1100s and one of the newer X2 screens plus a SCADA sytem.

8 UDP ports are set up in the code using Beijers function blocks.

The screens do have a lot of alarms and data points to display - perhaps 100 or so screens and 200 alarms.

The communication all works, but the screens are slow to update - perhaps 8 seconds or so for a screen to load and display values.

It's possible that it's "just the way it is" - too much data, too many screens, too old equipment etc, etc.

However, when using the IEC ethernet diagnosis tool and looking at the errors page, you see as shown on the attached image - lots of "meaningless" C047 errors which can be cleared but immediately come back again.

We have another similar PLC with similar setup and it does show the C047 error, but only the one and seems much faster.

Googling C047 shows that "An error packet ICMP was received" where ICMP means  "Internet Control Message Protocol" - which seems to be related to a PING command in some ways.

I'm wondering if this is what is hogging the comms, but have no way of knowing what's causing these errors - possibly the SCADA connection ????

Any advice greatly appreciated ...

[Gambit]

Most likely the packets are not being recieved in the setup times, but you could also have cable issues.

Still the Q2AS is quite old so should be replaced by a System Q or iQ-R series. 

If the packages are to late because of the scan time of the Q2AS then you can add som COM instruction in your program.  

[Colin Carpenter]

Thanks for the reply, but what I don't understand is that all the errors seem to relate to completely undefined port numbers and I have no idea what an IP address of 0.0.0.0 actually means. 

What sort of ethernet command would attempt to send nothing to "nowhere in particular" from "nowhere in particular".

The scan time on that PLC will be high .... probably in the region of 80 ms or thereabouts, but the problem with replacing is that it's tied into 4 other PLCs that all use Melsecnet B to  communicate and effectively run the processing plant.

We always install Q plcs now on any new plant, and these use the Melsecnet 10 coaxial connections, but we still have to have one Q2AS which can talk to both Melsecnet systems and translate from one to the other and back again.

The "twisted pair" Melsecnet B is ultra reliable, but a real headache when upgrading the PLC.

[Gambit]

0.0.0.0 is probabaly means the default gateway route.

I see, well since there is an ethernetcard present you could get comm's via simple plc communication from the iQ-R or QnUDV  to the Q2AS as a gateway and keep that one running the melsecnet.

As for the scan time you could set up some comms instruction so the ethernetcard can access the PLC more frequently. Hoewever this will increase the scantime

[Colin Carpenter]

Which part of the system is causing those error messages do you think?

I'm starting to think that it's not the HMIs as the other PLC doesn't show so many, so presumably it must be the Scada system.

This was upgraded recently and runs on a "virtual PC" on the main site server rather than on the standalone PC that it ran on for many years.

My knowledge of servers and   management networks could be written on a postage stamp with a paint brush ..... 🙂

[Crossbow]

I would think the SCADA system would have a setting for a keepalive time to check the connection is still good.  It may be set way too short, and asking the PLC if it is still there way too often.  I have limited experience with SCADA, but asking for too much information too often on an old 10MB Ethernet card is going to slow down all communications while the PLC attempts to respond to all the messages in order received.

You might also want to check the port settings in the Ethernet module and see how many ports were opened with MELSOFT Connection, as some HMIs communicate this way.  Perhaps opening another port or two can help to balance the load more.

Sorry I can't be very specific, most of my experience is with Q, iQ, and iQ-R, not as much with the older A/QnA stuff.

[Colin Carpenter]

Thanks, that's a good point.

I'll have a check in the Scada settings and see if I can improve things by slowing it down.

Thanks