|Product Performed to Expectations:||8|
|Specifications were sufficient to design with:||7|
|Demo Software was of good quality:||7|
|Product was easy to use:||9|
|Support materials were available:||10|
|The price to performance ratio was good:||10|
|TotalScore:||51 / 60|
@Programmable logic controllers (PLCs) are still an important devices used to implement industrial controls.
Because they are used in applications from different industries, manufacturers have continuously sought to improve the way PLCs can be programmed so technicians or engineers with different backgrounds could develop their application.
The release of IEC 61131-3 standard has improved the way applications can be developed as different programming languages used in the industry have been standardized.
The standard specifies four programming languages that can be used to program a PLC, i.e. Ladder Diagram (LD) – easy to understand by electrical engineers, Structured Text (ST) and Instruction List (IL) – easy to understand and use by software engineers, and Function Blocks (FB) – easy to understand by electronic or chemical engineers. In addition, Sequential Function Charts (SFC) can be used to graphically specify the sequential and parallel operation of a control system implemented in a PLC.
A lot of PLC manufacturers support in their CPUs the IEC 61131-3 standard. Their programming software, therefore, allows programming the control using any of the standard programming languages or even a mix of them.
The problem for someone who wants to learn these programming languages and the IEC 61131 style is that she/he usually needs a PLC in order to run and test the program they write and such a device, not including the programming software, is not very cheap.
Some PLC programming software developers have seen the opportunity to help these initial learners by adapting their software, normally running on PLCs, with their restrictive industrial specifications, to other platforms that are more affordable. In this category enters the Raspberry Pi board that can be converted into a PLC by installing corresponding software.
Two of the companies that have created ports of their PLC programming software for Raspberry Pi (RPi) are 3S Systems with their Codesys software and PHOENIX CONTACT Software with their KW Software. Though these ports were thought only for learning and practicing purposes, therefore not to be used in real industrial applications, some companies have been taking this approach further by creating products based on Raspberry Pi platform that can be used also in real-world applications.
The idea of the road test is to use the Raspberry Pi as a PLC by running the Codesys Software which supports the IEC 61131-3 standard. Once someone learns to program with Codesys on RPi, it can program other industrial PLCs running Codesys or, with additional training, any PLC supporting the IEC 61131-3 standard. Codesys software and port for RPi is free but has time limitation, i.e. the runtime stops after two hours. This is however enough for Codesys learning and evaluation purposes.
Running Codesys on RPi has already been done and tutorials can be found on the Internet. Therefore, the more specific plan of this roadtest using the RPi is to test and demonstrate the communication features of PLCs.
In the case of normal PLCs, the communication is possible by adding to the PLC that must communicate a communication module that usually has the price in the same range as that of the PLC CPU. The advantage of using the RPi is that the communication relies on the available Ethernet communication port. The Codesys software uses this communication port both for transferring the program into the PLC (RPi) memory and for implementing different communication protocols.
In order to test communication between PLCs there must be at least 2 PLCs i.e, in the case of the proposed roadtest, two RPis. I already had an RPi and I also had a PiFace plug-on board that provides switches and relays that allows the development of simple PLC applications. The RPi expected from the Road Test was expected to be the second RPi that will communicate with the first one.
The roadtest will consist of the following steps:
This roadtest was intended to find how Raspberry Pi 1 (RPi) can be used as a PLC and how one can connect several PLC enabled RPis and make them communicate in order to implement a more complex control where remote PLC units must exchange information for synchronization or communication purposes (like in an assembly line).
In order to do the roadtest I needed at least 2 RPis, extension boards and the software that allows the RPi to act as a PLC. The choice was for PiFace Digital as an extension board and Codesys software from 3S-Smart Software Solutions GmbH.
I already had an RPi 1 and a PiFace Digital extension board. Information about RPi 1 can be found at www.raspberrypi.org.
PiFace Digital is an extension board that can be connected to the RPi offering an interface similar to that of PLCs, where inputs and outputs can be accessed via terminal connectors but also via push buttons (for inputs) and relays (for outputs). 8 inputs and 8 outputs can be accessed using terminal connectors, or 4 inputs using pushbuttons and 2 output relays. It is not too much but it can be used for simple controls such as those used for simple home automation tasks. Other solutions are available on the market so, for example, the IO Pi Plus that offers 32 I/O, the Raspberry Pi Relay Board or the Pi-Plate Board (Pi-Plates RELAY Plate For Raspberry Pi ). More information about PiFace Digital can be found at PiFace – PiFace Digital.
In order to do the networking, I needed at least a second RPi. This is the reason I have enrolled in the New Year's Grab Bag roadtest opting for an RPi.
I was very happy to be among the roadtest winners and also when I received the package from element14 and saw that together with the RPi 1, I have received a PiFace Digital 2 extension board (https://ro.farnell.com/piface/piface-digital-2/i-o-expansion-board-for-raspberry/dp/2434230?st=Raspberry%20Pi%20Relay ).
My joy didn't last too much because I realized that the PiFace Digital 2 was not compatible with the RPi 1 because their connectors are different.
So I had to start with 2 RPi 1, PiFace Digital and PiFace Digital 2.
Because I wanted to use the PiFace Digital 2 with the second RPi 1, I tried to connect the two using wires. The result was a random operation of the PiFace Digital 2, therefore I decided to make an adapter between the two. Luckily the pin map for the PiFace Digital 2 corresponds to the pins of RPi 1 they cannot be directly connected together. I tried to use a 40 pin IDE ribbon cable from an old PC together with a pin header dual inline connector. The pin mapping gets reversed at the other end of the cable, therefore a second one must be used and connected with the first one using another pin header dual inline connector.
Everything went fine, but because the cables are too long and so difficult to use, I created my own adapter equivalent to two very short IDE ribbon cables as seen bellow. A yellow small bar that can be easily bent in the desired shape was used for sustaining temporarily the PiFace Digital 2 and preventing it from making unwanted electrical contacts with the RPi board.
Probably at a later time, a custom adapter should be made so that the ensemble RPi and PiFace Digital be more robust and esthetic.
In order to transform an RPi into a PLC using Codesys Software you need the following:
- a Raspberry Pi (B, B+, 2 or 3)
- SD Card with latest Raspbian Jessie
- CODESYS Installed on your PC
- CODESYS Raspberry Pi target
- Ethernet cable
CODESYS is a software for PLC programming which is used by many industrial automation companies such as Bosch, Beckhoff, Festo, Eaton, Wago, Turck and others. Codesys can be used for writing PLC programs using the programming languages specified in the IEC 61131-3 standard, the traditional Ladder Logic included.
RPi is transformed into PLC by installing a dedicated runtime. Not licensed, the runtime will run only for two hours, which is can be considered enough for educational purposes (the usual duration of a lab is 2 hours).
Codesys and corresponding runtimes for PLCs which are used in a real industrial environment constitute an expensive software environment.
At the time I have applied to the Road Test I already had an RPi with Raspian and Codesys installed.
For installing Raspian the reader can follow the instructions given at this link https://howtoraspberrypi.com/create-raspbian-sd-card-raspberry-pi-windows/. At the first boot,
the Raspberry Pi starts in setup mode. If not, it can be configured with the following command:
The usual configuration includes the re-size of file-system to use the entire SD card, changing the locale, time zone and including different peripherals such as I2C, SPI etc.
For installing Codesys the reader can follow the instructions given at this link: https://www.instructables.com/id/Programming-Raspberry-Pi-With-CODESYS/
Please note the following regarding the installation and the use of Codesys:
Once the installation was done for one of the RPis, the SD card can be cloned on another card by using the Win32DiskImager software. The image on the SD is copied to the PC and then from the PC to the other SD card. It is simpler if both cards are of the same type and have the same size. The image can be cloned on a bigger SD but afterward, the image should be resized to the size of SD.
I have created the two SD cards, I have introduced them into the RPis SD card slots, connect them to the network (through a wireless router) and powered them from 5V power supplies.
After the RPis have started, we start Codesys and create a new project.
Start a new project by selecting the "Standard project" and we have to give a name (RT_RPI) and the location.
We then select as device "Codesys Control for Raspberry Pi SL..." and the language for the program we will write (LD for Ladder Logic Diagram).
In the Devices windows, we see the project tree for our device.
In order to use the PiFace Digital 1 or 2 we must add an SPI master device by selecting SPI in the project tree, right-click and select Add Device. In the Add Device window, we select SPI master and click Add Device.
Then we click on SPI master in the project tree and in Add Device window we select PiFace IO driver and then Add Device.
Double-clicking PiFace_IO_driver in the project tree opens the PiFace_IO_driver tab where we can, for example, the I/O Mapping for the PiFace Digital board.
The PiFace Digital driver didn't work from the beginning. When connecting to the RPi, the inputs and outputs were active and were not in accord with the status of the buttons. It took a long time to figure out that it was a problem with the configuration of the SPI driver. After a long search on several discussion forums, I found that the SPI driver must be configured with maximum speed of 100 kHz (in SPI master Parameters, the parameter _diMaxSpeed, which is in Hz, must be set to 100000).
We can also add a visual interface that can be accessed both from Codesys but also over the Internet allowing us to use visual controls in a web page to control resources ( ex. inputs and outputs) over the internet.
This can be done by selecting Application entry in the project tree, right-click and Add Object->Visualization. Then you can create your interface using visualization controls that can be mapped to elements in the program (inputs, outputs, memory elements etc).
Now clicking on PLC_PRG entry in the project tree we open the Ladder Diagram editor in order to write the program.
The first part of the roadtest consists of writing an application that will be run on the RPi using the Codesys runtime installed on the board. As Codesys complies with the IEC 61131-3 standard, it means that the application can be written in any of the 4 languages described in the standard (LD, ST, IL and ST). In addition, SFC can be used to write the application.
The application considered for this roadtest uses as inputs visual controls of the visual interface and outputs are controlling both visual controls and outputs from the PiFace Digital board. The interface is shown in the figure below.
The elements of the interface are:
The operation is the following:
At power-up, lamps #1 or #1 and #5 are lit depending on the position of the sType switch. Then, we can command a sequence of commands that, depending on the position of sType switch, it lights the lamps following a certain pattern.
If sType is on, the pattern is #1->#2->#3->#4->#5->#1->#2....
If sType is off, the pattern is (#1 and #5)->(#2 and #4)->#3->(#2 and #4)->(#1 and #5)->(#2->#4)....
The sequence generating these patterns can be run step by step, by pressing button bStep repeatedly, or can be generated automatically if button bAuto is pressed. Each step of the pattern has a duration of 1 second.
Button bReset, resets the outputs (in fact the state machine used to generate the patterns) to the initial state.
This application can be implemented in different ways. I have selected to implement it using a counter to 5 that counts 1s pulses generated with two TON timers. Comparators are used to decode the state of the state machine from the counter output, and the outputs that control the lamps are activated based on the state of the state machine and the position of sType switch.
The listing of the program written in LD language implementing this behavior is given in the file "Program LD.pdf".
The programs in ST and FB language were derived from the program written in LD by writing the boolean equations associated with LD rungs and including the counter and timers. These listing of these programs are given in "Program ST.pdf" and "Program FB.pdf". Of course, the application could have been written in other different ways using these languages, benefiting from the specific language constructs of each language.
Another implementation of the application was done using SFC, by taking into consideration the fact that SFC can easily be used to describe sequential behaviors. This implementation whose main part is given in file "Program SFC lamps.pdf" is completed with the program given in "Program SFC step.pdf" and the one in "Program LD step.pdf". The first implements the clock of the system while the second one implements the manual stepping of the application.
All these variants of the application are included in the project and can be activated alternatively by modifying the task configuration to run the corresponding program.
In order to reduce the number of variables used in these examples, we have declared the variables used in the programs as a set of global variables (GVS). In this way, any of the programs will use the same variables which are mapped to the visual controls of resources of the PiFace Digital board. The list of global variables is given in the file "Global GVS.pdf" file.
After we have written the program, we must connect to the RPi board. In order to connect to RPi we must discover the board by scanning the network (Device->Scan Network).
As we can see below, both RPis are discovered and we can connect to either of them and load the program to the board.
Then we can select which of the RPis we want to connect to in order to load the program.
We can connect to both RPis, one after the other and load the program but we cannot monitor the operation of both. To do this we have to launch two instances of Codesys software, one for one of the RPi and one for the second one. Then we can monitor both of the RPis running the same application and controlling them independently.
I succeeded to obtain for evaluation a Turck TX507E-P3CV01 which is a device that includes both a PLC and an operator panel (https://www.turck.de/en/press-135_hmi-with-codesys-3-plc-and-visualization-5723.php). What is important for this road test is that this device runs CODESYS PLC runtime (so it can be used as a PLC CPU) and CODESYS Target Visu runtime (so it can be used as an HMI acting as a PLC operator panel). In addition, it supports a PROFINET controller, EhterNet/IP scanner, Modbus TCP master/slave, Modbus RTU master/slave, serial interfaces (RS232/RS485/RS422), Ethernet port, USB host port and can be extended with plug-in modules.
Therefore, the last part of the road test will be to connect this device with the Raspberry Pi devices, all running Codesys runtimes. Because TX507 device has no inputs and outputs, it can be used as a PLC CPU, the RPi devices being used as remote I/O modules. In this roadtest, the connection between the TX507 device and the RPis modules from the hardware point of view will be done using the Ethernet network (they will be connected to the same network via a router) while the connection from the software point of view will be done using Network Variables (NV), the same as was used for connecting the two RPis. Taking into consideration that both TX507 and RPis support other communication protocols, applications seeking to connect these devices can be developed using these other protocols. This can be the subject of a future road test.
Creating an application for the TX507 implies following the same steps as for any other PLC supported by the Codesys software. The appropriate software package must first be installed in Codesys software. For the available part, this means CODESYS_TURCK_184.108.40.206.0.package (first I have installed the latest package from Turck and it was not working. I contacted the support team and they sent me the correct package).
I created a small application (see "Buttons.pdf") that is using two buttons and three lamps considering they are related to the buttons to turn on and off the light in a house (two lamps each one in a different room), and the third lamp related to the front door lamp that is turned on for 15 seconds when lamps in the house are both turned off. For this purpose, a TOF timer is used.
In order to demonstrate the communication between the TX507 device and the RPi, Network Variables (NV) are used both for sending and receiving signals from/to the RPi. A set of sending NVs (see "Turck_to_RPi.pdf") is used for controlling the auto mode of the RPi application from the first button of TX507 application and a set of receiving NVs (see "RPi_to_Turck.pdf") is used to receive the status of the lamps in RPi application and which are displayed using lamp type visualization elements on the panel of TX507. In the picture bellow we can see the TX507 and the RPi connected to the same network, two instances of Codesys running on the PC (one for an RPi and the other for the TX507) that were used to create the applications for the two, for loading the application into the devices and to monitor the execution of application and visualization components. The visualization windows have been put in front of the screen for monitoring the operation of the application.
The operation of the TX507 and the two RPis connected in the same network are given in the video "Roadtest4s".