Slow response, Ignition talking to M580 via ModbusTCP

Ignition
1

Hi,

We have a couple of projects using Schneider M580 PLC.

There are all slow response when read/write tags from ignition, about 2-3 sec delay. Total number of tags configured is around 5-10k.

It's using Modbus driver, configuration as below, is there anyway to improve the response?
I have tried to adjust "Concurrent Requests"/"Max Holding Registers Per Request"/"Max Input Registers Per Request".

image
image712×1119 103 KB

2

Show your driver diagnostic page.

Are your connections local--that is, the Ignition gateway is on the same LAN as the PLCs?

Are your register addresses consecutive, or nearly so?

3

Thanks for the reply.
Yes, it is local connection over LAN.
The addresses are mapped in the UDT for each tag group.
For example,

image
image869×143 79.3 KB

Just had look at the device diagnostic page. It's overloaded.
But how do I increase the throughput? It's the right amount of tags needed for each type of scan.
image
image1247×1143 201 KB

4

You will almost certainly have to make changes on the PLC. First, take a wireshark capture and look for requests that aren't at or close to the max size per memory type. Move data in the PLC to new addresses to maximize the consecutive placement of bits and registers.

If the M580 has any settings that govern communications CPU usage, check that too. Also, you might be using too many concurrent requests--many devices do not benefit from concurrency greater than 2 or 3. Experiment with that.

If you cannot make PLC changes, then you are probably out of luck. The Modbus protocol's maximum packet size is ¼KB, so it doesn't scale very well in general.

If this is a new application, and you can change brands, consider a processor technology that supports larger transfers. (I'm not familiar with the current Schneider product line, but what I hear is almost invariably disappointing.)

5

I noticed that your response times are very close to 100ms for all paces. I can't imagine the PLC really is that slow on a LAN, but it might be throttling communications to one per scan of a particular task. Response times for capable processors tend to be in the single digit millisecond range.

{ If you find a setting in the PLC that is causing that, and is adjustable, please share for the rest of us to find in the future. }

6

I'll just throw in that the M580 has a module that can expose the tags on the PLC via OPC-UA. From the documents it will have a much faster response. I have not had a chance to test it yet as Schneider Electric is facing supply chain issues currently.

7

Schneider is definitely having supply chain issue. Any parts ordered needs to wait at least 3mths.

What's the part number you are referring about the OPC-UA comms?

8

Thanks for the comments.

I have a couple of sites using the same CPU, there's one currently under development, I maybe able to test out.

Also one of sites is using NOC card talking to Ignition, it seems much faster than direct communication with the CPU module.

9

BMENUA0100 is the part number. It's fairly new.

10

just googled, it looks like the solution to go.

11

This module has limitations. For big Plant/applications it would be a problem. It supports 100000 data dictionary counts configurable for OPC UA Server, out of which 50000 variable accessible at a time.

12

We are going to use this module for a facility, and one PLC with RIO covers half of the facility... We have <5000 tags total! I guess different industries just have a lot denser I/O needs, but 50000 is plenty for us.

13

When you consider that Modbus TCP, the alternative here, typically only handles 64k 16-bit read/write registers and 64k read/write booleans, these limits seem appropriate.

1 Like
14

A couple of items to consider for OPC-UA communication to M580 Schneider PLCs:

  1. Depending on your situation, perhaps another option to the BMENUA0100 module is the Schneider OPC-UA Server Expert. This would be more of a software/driver solution. Note, this works with M340s as well as M580s. Also, of course there are limitations to the total number of tags a single instance can handle. Here is a link if you want some more details:
    https://www.se.com/us/en/product-range/66388-ecostruxure-opc-ua-server-expert/#overview

  2. In either scenario (NUA module or Schneider OPC-UA software) I would recommend changing the PLC settings such that "Only HMI variables" are part of the data dictionary. That way you have much more control of what variables take up your dictionary and are available to SCADA.

2 Likes
15
  1. We have not gone for Software Solutions, Of course we will get more dictionary counts in Software Solutions.
  2. We have lot of DDT and each varaiable inside DDT will be considered one dictionary count. You can't select "Only HMI variables" inside the DDT variable which you want to expose. Either you can select complete DDT or Completely not.
16

Just to update:

I have increased the 500mS group to 1043mS, it looks like the issue has been resolved and the overall update time is about 1.xx sec. Looks like the 500mS tag group does not work for M580, too fast for Modbus TCP comms protocol.

17

image
image1179×1096 183 KB

18

I would say "too fast for the M580". I have experience with many devices that have mean response times in the low single-digit milliseconds.

1 Like
19

Concurrent Connections = 16
PLC M580 small CPU behind a router and Ignition 8.1 in a Dedicated server cloud. M580 and M340 is very fast modbusTCP query/Response, but is necesari know protocol and know Schneider Hardware.
Ethernet Cable connected in RJ45 CPU (Service Port) 100Mb and RSTP protocol DISABLED on Eth ports of CPU M580

image
image980×887 32.6 KB

20

In other projects (Solar Plants), I connected about 50 devices in ModbusTCP with a ScanClass 1000ms ,5000ms ,10000ms and 60000ms, depending of type of signal, with large UDTs and Overload of ScanClass groups is below 60% with a 83421 tags in the project (comunicated tags).