Dear Sir or Madam,

I am a software developer in Germany. I am responsible for the communication between programmable logic controller and our Database.
We are using Modbus for the data transfer.

So far it works perfect. But now, we are communicate with over 100 PLCs (Beckhoff CX) asynchronous. So, we got an Server which communicate with al lot of PLCs. But we can only get the data of circa 97 PLCs. To connect with the other PLCs is not possible, the server could connect to the other PLCs.

Are there settings in the OS?
Do you have any idea, which could be a solution?

Best regards
Andreas Wickert

 

- What sort of Modbus are you using? Is it Modbus/TCP on Ethernet, Modbus/RTU on RS-485, or Modbus/ASCII on some other media?

- Are any of the PLCs connected via radio links?

- Are you using Ethernet to RS-485 (or RS-232) gateways?

- What is the network configuration? Are all the PLCs local (in the same building), or are they spread out over half a continent?

- Are the PLCs configured as clients (masters) or servers (slaves)?

- What "server" software (including communications drivers) are you using? Did you write the server yourself, or are you using something that is largely off the shelf?

- What operating system are you using? What version?

- What is the central communications server? A PC? A PLC? Some special embedded hardware?

- What is the server CPU load? If the server is a PC with a multiple cores, what is the load factor per CPU core?

- How fast is the system polling? How many reads (and writes) are there for each PLC in a complete cycle?

- For the PLCs that you cannot connect to, is it always the same PLCs that you cannot contact, or does there just seem to be an absolute limit of 97?

- When you say the server cannot connect to the PLCs, are you getting error messages? If so, what are they?

 

Is there any reason to use Modbus instead of Beckhoff ADS?

With ADS you can access the variables (and even structures) by name in one read. You can also register events and thus receiving notifications when a variable changes without scanning the PLC's at all.

 

Hello,

i add some informations, but I have only the knowledge of the IT site.

Ok, at first, we had the machine 1 - 90. Then it works. Later, I added the machine 91-100. Then some Machine 80-90 could not connect to the OPC Server. If we decrease the machine, then it works. I hope it is understandable.

Ok, at first we using an own developed application in .Net. We are using the mbusmaster.net.dll for the connection. We connect via modbus/TCP. If we use it, in that way, we can connect to 97 PLC's.

Now, we want use an OPC Server. It is developed by INAT. I think, not very famous, but it is easy to use. Then we can connect with circa 70 MC's. The OPC server is running on a Microsoft 2003 Server.

We are using Beckhoff CX. They are in one building in the same network, but connected with different switches via RJ45.

Configured as Clients or servers - I don't know. Is it important?

The Microsoft server is visualize with VMWare. But it is an really high performance server.

It seems to be, that it is always the same PLC, who can't connect. At first, we thought, that it could be a switch or Firewall, but our network specialists inspect it and it looks ok.

I hope this information can help.

 

I'm not familiar with the INAT OPC software, and the INAT web site doesn't appear to have any manuals which I can download. However, you may wish to check with INAT if there is a limit to the number of connections and/or "tags" (variables) they allow. Many vendors put artificial limits in their software so they can charge you for upgrades for more connections or more tags. On the other hand, INAT may have just put a hard limit into their software because they've never tested it with more than that.

You may also have more than one problem here. Some of the new PLCs may not be set up correctly for communications, or you may have routing or other problems. You should be able to test the connection though by using a Modbus/TCP test program to see if you can read anything from those PLCs. There are a number of these available, and they are commonly used in commissioning (I have a free one available if you are interested).

You are going to need to know whether your OPCServer software is acting as a Modbus/TCP client or server however before you can investigate things properly. You've said the PLCs were connecting to the OPC server. That may imply the PLCs are the clients here, but on the other hand that may just be imprecise wording on your part.

In addition to the above, Microsoft puts limits on the number of TCP connections that you can make. I think with the server version of MS Windows though you can raise that limit if you know what parameters to tweak. Since you are running this on VMWare, there may also be a VMWare limit (or quota) involved as well.

Also, you may have a fairly fast server, but you could still be hitting CPU limits when trying to service that many connections. You are running in VMWare, and you may be configured to be limited to a single core. In addition, your software may be single threaded, and the OPC server may be single threaded. You could be hitting a RAM (quota) limit and swapping. You could be hitting a TCP bandwidth limit (quota). There are lots of ways the server could be idle "on average" while still hitting a performance limit. This is especially true as there are ways of imposing "per image" quotas on a VM.

I would suggest investigating things in the following order:

1) Make sure you can contact each of the new PLCs. Try pinging them, and try using a Modbus/TCP test/commissioning program.

2) Check the actual CPU load and memory consumption while under actual (or simulated) load. In particular look for any process that is under high load or that is using a lot of memory. Also check network bandwidth usage.

3) Check the MS Windows parameters for any limits on TCP connections. I'm not familiar enough with MS Windows Server 2003 to give you any direction on this, but you should be able to find this out via Google.

4) Check for any corresponding limits (or quotas) in VMWare.

5) Check with INAT as to any connection or tag limits.

6) Your server software may have a hard coded limit in it somewhere (not necessarily an obvious one), but I assume you would know about that.

I also have (free) programs which can act as Modbus/TCP clients or servers. I use these to do load testing on Modbus/TCP server systems (clients and servers). Running multiple instances of these programs allows simulating multiple field device clients or servers for testing purposes without actually having hundreds of devices on a network. If you are interested, then let me know.

 

Hi,

Although I have used the INAT OPC Server (with Siemens protocols, not Modbus) and can say it is a great product I never tested it with the amount of PLCs you have.

I think your problem has 2 possible causes:

1) There is an internal problem with the OPC Server when it has to connect and handle a large amount of data or tcp/ip connections. Maybe the limit is reached when you connect the PLC #70th or #75th.

Have you called INAT? If so, what did they tell you?.

2) There is an issue associated to maximum number of concurrent TCP connections that a server can handle (XP, Vista, Windows Server 200x, etc).

Here you can take a look at these links to help you:
a) http://smallvoid.com/article/winnt-tcpip-max-limit.html
b) http://www.lenholgate.com/archives/000568.html

Best regards.

Saludos desde Venezuela.

Gustavo A. Valero P.

 

It seems that MS has limited the number of new TCP connections to 10 connections/second because of security reasons.

See:
http://www.speedguide.net/read_articles.php?id=1497

You might insert a sleep() after connecting to 10 new PLCs. Thus it should be possible to connect all PLCs.

 

Why don't use OPC for this? Use this opc server to connect to your PLCs:
http://www.matrikonopc.com/opc-drivers/1603/index.aspx

then to connect it to the Database, use the OPC Client for ODBC:
http://www.matrikonopc.com/products/opc-archiving/opc-client-for-odbc.aspx

you will be good to go. let me know if you need any help

Wassim Daoud
Global Solutions Architect
www.MatrikonOPC.com