– Compact PLCs,
– Modular PLCs.
They usually have less than a 100 (or mostly even less than 30) I/Os, which is mainly digital ones with few (or none) analogue I/Os.
For example: one with 10 pieces of 24V rated digital inputs, 6 pieces of normally open relay contact outputs, one 0-10V analog input and no analog output.
These PLCs usually have a communication interface and in some cases they have a display as well, through which they can be programmed, and this way a communication line is not needed.
The communication takes place via RS-485, CAN or an ethernet based interface, but usually only one of them.
Its program memory is little, enough only for simple tasks. Its internal processor usually is a microcontroller (MCU).
The following picture shows the basic schema of their internal hardware:
To enable more functionality and more complex I/Os, manufacturers have their own range of modular PLCs.
In this architecture, the hardware units are separated by their functions. There is a separate module (called PLC card) for the program execution (CPU), for sensing the digital inputs, for outputting analog values etc.
In contrast to the compact PLCs, modular PLCs’ I/Os can be increased to a pretty high level. A single CPU card can handle several thousand I/Os, while communicating with other units (other PLCs, database servers, displays…).
This way the CPU must communicate somehow with the I/O cards in order to collect and output their datas.
Some manufacturers use backplanes to connect the cards to each other, while some integrate the connectors into the PLC cards. The common in them is the need for a “background” communication line.
The smallest modular PLC configuration consists of a power supply unit (PSU) card and a CPU card, with no I/O card at all.
Even in this small config, the PSU and the CPU card must be connected to each other: the PSU provides power to the CPU, and the CPU asks the state of the PSU (actual working voltages and currents, overload signals, etc.).
But how is this backplane communication done?
Obviously it must be a master-slave architecture, where the CPU controls the communication and all the other cards are “just” answering if the CPU asks them.
There are several types of communication interfaces which can fulfil these requirements. One can use I2C bus, RS-485, CAN bus, some sort of ethernet…
While this solution is operable, asking the cards separately takes too much time. How could this be reduced?
The most attractive property of the formerly mentioned solution is that it can function even if one card is failed.
But in practice it is very unlikely that the backplane communication line goes wrong in the lifetime of such a PLC system (or if it goes wrong, the whole PLC system shall stop to prevent damage in the technology), so the communication can be “daisy chained”.
The daisy chain method means that each card communicates only with their neighbour.
The CPU starts the process with sending an initial message to the card located next to it (for example to the right hand side). Every I/O card has two communication channels: they wait for a message from the “left hand side” (receiver side: RX), process it (insert its own informations into it), and then transmits it to the “right hand side” (transmitter side: TX).
This is a well known scheme, it is the basis of INTERBUS systems.
With this method the I/O interrogation becomes much faster. On the other hand, bus systems with multiple access (like I2C or CAN bus) cannot be used.