This example setup describes the movement of containers over conveyors. The conveyors have motors which can be started and stopped by a GPIO output pin controlled on a Raspberry Pi and each conveyor has a light barrier to detect the occupancy of a container and the Raspberry Pi detects this on GPIO input pins.
Further at each conveyor location is a barcode reader to read the ID of a container.
The general idea is that the PLC notifies a Strolch agent of changes, and only turns conveyors on, when the agent gives the command. Thus the agent handles business logic and the PLC controls the I/Os.
Create a new project using the PLC Strolch Maven Archetype:
mvn archetype:generate \
-DarchetypeGroupId=li.strolch \
-DarchetypeArtifactId=strolch.mvn.archetype.plc \
-DarchetypeVersion=0.1.0-SNAPSHOT \
-DgroupId=<my.groupid> \
-DartifactId=<my-artifactId> \
-Dversion=<my.version> \
-Dpackage=<my.package> \
-DappName="<my app name>"
This will create a multi-module project:
<my-artifactId>-web
module contains the server code, which handles notifications from the PLC, and can send
telegrams to the PLC.<my-artifactId>-plc-web
module contains the PLC code, which connects to the server and communicates with the
low-level hardware.shared
modules contains classes shared by both projects (e.g. constants, etc.).This project already contains a default PLC model in <my-artifactId>-plc-web/runtime/data/
.
The following sections explains these files:
This file defines the hardware connections. The following connections are implemented:
See their respective classes for details.
This file maps I/Os to Resources and Actions and is converted into Strolch Resource
objects using
the PlcAddressGenerator
class.
In this example we will use simple Raspberry Pi GPIOs. For convenience, and also when sharing I/O definitions with
external partners, it is easier to use a CSV file to define the I/Os and then use the PlcAddressGenerator
to generate
and validate the model.
For easier handling, use the following Google Sheet as a starting point: https://docs.google.com/spreadsheets/d/10fgTfR3FZCVbQ5bbh0xB1u8rLIaw2KEyO45VMv7y5ho/edit?usp=sharing
The CSV headers are as follows:
<Connection>.<Device>.<Pin>
.
DevPin0 decrements the Device and Pin values by one for zero-indexed addressing.<Connection>.<Pin>
.When you use this file as input for the PlcAddressGenerator
, then it will
generate PlcLogicalDevice, PlcAddress and PlcTelegram elements. See the file strolch-plc-example.xml
for an example.
The PlcLogicalDevice
references the PlcAddress
and PlcTelegram
objects, and is
then used in the UI for grouping.
The PlcAddress
is used to store the current value and defines the keys with
which the agent will be notified
The PlcTelegram
is used to store default values to send, for specific keys. E.g.
The action On
would send true, and Off
would send false. This is semantics, and
is defined in each project depending on the hardware.
Once you have both the server and PLC instances running, you can login. The default username and password are admin
/ admin
.
After logging in to the PLC you should be greeted with the following screen:
And after logging in to the server you should be greeted with the following screen:
If the PLC could connect to the server, then the PLC Control
icon should be activated. The actions Enable, Disable and
Stop All send telegrams to the PLC, thus showing how the server would communicate with the PLC.
Now that the server and PLC are running, we can customize the code. On the PLC side you will want to create
new li.strolch.plc.core.PlcService
services by extending the class and then registering the service
in CustomPlcServiceInitializer
.
See the example StartupPlcService
.
On the server side, to register for notifications from the PLC, one would
implement li.strolch.plc.gw.server.PlcGwService
services and register them on the PlcHandler
in
the PostInitializer
class.
See the example ModePlcSrvService
.