Introduction

[13/04/2024]

In this series of articles, I would like to go through a variety of Modicon controllers and discuss communication configuration commonly called IO Scanning. Modbus protocol is going to be discussed as a mean of transporting data between PLCs. IO Scanning makes data exchange easy because all You need to configure is:

  • from where to take data (IP address, Slave ID, Modbus register),
  • quantity of data,
  • where to store obtained data,
  • how fast to poll,
  • timeout for the communication.

It is straight forward and all the mechanisms of requesting data, analyzing, and processing them are done behind the scenes. Application engineer just indicates needs and gets the results in specified memory location. As always, it comes with the cost. IO Scanning manages only Modbus Function Code 3 which sometimes may forces to aggregate data into registers. If You need to pass several bit statuses, the intermediate step is to pack them into a register. Of course, there is a way to exchange bits (ex. Modbus Function Code 1 or 5), but it requires to write a piece of code an manage communication by yourself.

Concerning IO Scanning, some controllers (like Quantum programmed with Unity Pro IDE or M340 family) allow to create a “Network” and link it to the specific module. It means, application engineer can easily move the “Network” from one to another module without losing its content. For other controllers (like Momentum or Quantum programmed with Concept IDE) communication configuration is tight to specific module. Moving it to another module is basically repeating all the configuration by hand.

For this series of articles, we are going to use 350 elements array. But why not 360? Or why not 375, 384, 300 or any other number? What are the reasons to choose one number over another? First, I am writing this article based on my experience and field problems I faced. My task was to manage almost 300 Protection Relays of the same type. 300 is the most natural choice for regular people who are used to decimal system. In my case, 300 was just at the limit for the number of devices I had to manage, and I didn’t have any spare capacity for unpredicted system extensions which I normally consider as 10-20% spare. As a programmer, you are familiar with the binary system, You can quickly notice that 384 is 3 x 128 and 128 is a power of 2. So why not to choose 384? It would be roughly 30% of spare which is acceptable if Your PLC is powerful. The problem is the limitations of Modbus. By Modbus specification, the maximum You can get with one request is 125 registers (250 bytes). So, should I use 375 then (25% spare)? Well, yes, that is a good choice. Why then, I didn’t go for 375? It is because of my personal preferences. When I worked with old PLCs or HMI versions, I faced a weird problem that after deeper investigation can be considered as firmware bugs. It happened to me several times that when I attempted to read full range of 125 registers, the last 2 or 3 of them (register 123, 124, 125) gave me some random values. My Modbus Master / Modbus Server contained one value, but I obtained another. Of course, in Your case it is a matter of testing Modbus Master / Modbus Client to make sure the data are received correctly. I also can’t imagine that modern controllers could have such issues but in older controllers You may face that kind of problem. By my personal preferences then, I request no more than 120 registers. I should choose 360 then (20% spare) and program exactly 3 polls of 120 registers each. Data could be easily managed with two “FOR” loops and it would be an elegant solution. However, I decided to use 350 elements array so not all Modbus frames are of the same size. I am going to program 2 polls of 120 registers each and 1 poll of 110 registers.