Programmable Logic Controllers (PLC) can also be implemented by (embedded) Linux computers. MBLogic from http://mblogic.sourceforge.net/index.html is an open source collection of PLC tools. It is written in python and does not need to be installed, since it runs inside a directory. If you download MBLogic you get all the different packages together and you might loose the overview. The packages are:
MBLogic Soft Logic (the PLC and all necessary tools as web server)
HMIServer (Human Machine Interface that has a modbus interface on one side and a Web server on the other)
HMIbuilder (Toolkit to create web pages for the HMIServer)
MBLogic Tools (Useful tools for debug, troubleshoot and test)
MBLogic Libraries (Contains the PLC without all the tools)
The packages have some parts that are redundant. The reason is that MBLogic is a complete platform but many parts of this platform make sense to use as individual packets. As the HMIServer could be used without the PLC and the mbtools can be used to test and troubleshoot any kind of modbus devices. Since MBLogic is quite complex it is important to get an overview. If you have the chance, it is therefore recommended to test out MBLogic or if you have some separate modbus hard or software HMIServer .
It is written in python and makes use of twisted a python network framework, therefore emerge twisted and emerge twisted-web.
MBLogic supports also SBus and Ether SBus from SAIA Burgess that is not covered in this document.
The MBLogic supports all the modbus data Objects as: Coils, Discrete Inputs, Holding Registers, Input Registers.
MBLogic introduces also Alarms and Events. Alarm and Events are Modbus Coils that are handled differently inside the MBLogic. They can be logged. Offset addresses have to be defined allowing to start the alarm and events numbering from zero. However they can also overlap to existing coils. Alarms and events can be grouped in to zones. Zones might overlap allowing alarms and events be visible in different zones.
MBLogic is the PLC. Since MBLogic is python, it can easily be started. Go to the directory where it is and type: ./mblogic.sh. After some start up messages not much happens in the console.
Open the HMI interface using a web browser to see what is alive http://localhost:8082/hmidemo.xhtml.
To get control of the PLC open an other link in a browser http://localhost:8080/MBStatusSystem.html. There you can edit the program, monitor data and shut down the System (this is just the PLC application and not your PC).
MBLogic has no direct support for local IO's. To connect local IO's to it you can either run a modbus server on the same computer or make use of the MBLogics Generic client interfaces.
MBLogic makes use of config files that can be reloaded (except mbserver.config) with the HMI and while the system is running:
Holds system server configuration (the PLC, HMI, Help system) and client connection configuration (where it gets data from as IO modbus devices). A client connection defines usually a modbus server having a IP address (e.g. localhost). Every client connection holds connections, parameters and commands:
&readdiscrete=function=2, remoteaddr=0, qty=1, memaddr=0100 &writecoil= function=5, remoteaddr=0, qty=1, memaddr=0200
Please be aware that two tables are involved:
The PLC address table (Synonyms: memaddr, Softlogic Address, Data table address, MBLogic table). In general when the term address is used, this address is meant.
Examples are: X1 for fist input and Y1 for first output.
The modbus table (Synonyms: Remote address, System Data table, modbus address ). The addresses contain two fields, the first is the physical type that can be: Coil, Discrete Input, Holding Register, Input Register. The second field is a number.
Examples are: coil 100, discrete input 100
If you do not have modbus devices that have physical IO's or if you do not have a modbus simulator, then you can link back the modbus server of the MBLogic to the MBLogic modbus clients. This is the loopback feature.
Holds the name of the file containing the application program that has to run on the PLC (as plcprog.txt). It also links the communication names (modbus addresses) to the PLC addresses. It also supports to configure data that is saved non volatile (saved to hard disk during shutdown and restored on startup).
HMI server is the Human Machine Interface that can be accessed via a standard web browser. The MBIServer can also be used as standalone package, to visualize any other modbus devices.
The HMIServer has different subdirectories where the hmiserver subdirectory does not require any customization. The hmipages directory contains a sample web content and needs to be customize to fit your needs.
The HMIServer has two sides, a side to the user, the HMI and a side to the modbus devices. The HMIServer supports Modbus/TCP and can communicate to modbus devices either as server (slave) or as as client (master). On the user side it obviously acts as server only, since web browsers are clients.
The HMIServer is usually started via script as the hmidemobs.sh script. Looking at this script shows that it could start one out of 4 possible hmiservers:
hmiservermbc.sh the modbus client
hmiservermbs.sh the modbus server
or the two SBus alternatives
When acting as modbus server (slave) just two parameters are required, since other modbus clients will poll the server and need to care about the additional stuff:
HMIServer Port: -p 8082
Modbus/TCP Port: -r 502 (or 1502 for no root users, or for the demo 8600)
When acting as modbus client (master) more parameters must be passed:
HMI web server Port:-p 8082
Name or address of remote modbus server: -h localhost
Port number of remote modbus server: -r 502 (or 1502)
Unit ID to identify an unit inside the remote server: -u 1 (1 for the first or only unit)
Timeout in seconds, since the remote server might not be online -t 5.0
For the demo, the script also starts ../demosupport/demosim/demosimmb.py that simulates a machine. This is required to have a living demo with feedback to your inputs, usually this is not required on a real applications. However this is also a good start to show how python code could be interfaced to the HMIServer to expand the functionality. The script hmidemobs.sh is started in the console. To have a gui for the hmiserver open http://localhost:8082/statussystem.html in a web browser.
Finally you like to see the customized web pages showing the machine, this is: http://localhost:8082/hmidemo.xhtml
The interface to the modbus devices is done in the mbhmi.config file. It holds the definition of all the modbus data that can be used. For a modbus Coil the entry looks as follows:
[PB1] addrtype=coil memaddr=0
[PB1] is a label and stands for Push Button 1, any other name can be set that represents the coil function. The push button 1 in the HMI (Web page) will activate the modbus coil at address 0.
A Discrete Input looks as follows:
[PL1] addrtype=discrete memaddr=0
The label [PL1] stands for Pilot Light 1, any other name can be set that represents the input.
Input and Holding Registers are defined in a similar matter, but have more parameters that deal how the 16 bit value is interpreted.
[HR00]
addrtype=<holdingreg or inputreg>
memaddr=0
datatype=integer
range=-32768, 32767
scale=0, 1
The datatype integer should be used for modbus registers, other datatypes are available in MBLogic for other purposes. Range checking is possible with the range parameter that defines the minimum and maximum value. The scale parameter has two values, the first is the offset, the second the multiplication factor.
Everything for the HMI is in the hmipages subdirectory. All xhtml pages in this directory are recognized. Reverse engineering and debugging the demo application is a good approach to get familiar with this complex subject. After that, the documentation will be clearer.
Modify or customized the following pictures:
pagebackground.png the background picture
pagelogo.png a logo inside the web page
pageicon.png is the icon that the web browser uses. Since the web browser has cache it takes time until an update has an effect.
In the xhtm page replace the main picture. The main picture is svg vector graphics. svg is pure XML and this means it is text! So everything between <svg> and </svg> is the picture. The java scripts inside the web page can modify it according the alive data.
To observe the secrets reverse engineer the main picture of the demo, by copy everything between the <svg> and </svg> tags including the tags themselves into an empty svg file with the inkscape header:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
This is best done using a XMLeditor.
Then open it using inkscape. Select now the buttons and lights. Go to object property and you will see their ID tags with their ID values (=names). This has to match to the mbhmi.config file.
It is recommended to read the MBLogic Inkscape guide to understand how the svg has to be drawn and prepared.
The clientconfigdata.js needs to be adapted. If the HMIServer has to act as modbus client it has to poll the modbus server. Therefore the following line must contain the discrete inputs and input registers to be read. Adding coils and holding registers to the list makes that they are read back:
MBT_ReadList = ["<modbus obj1>
", "<modbus obj2>
" ];
To have a Pilot light controlled you need to know its ID and add some javascript code to the xhtml page inside the <script> section. The first line updates the javascript variable, the second makes it visible. After reset it will be black, but then it changes to red or green. Note that a pilot light needs to be connected to a modbus servers discrete input and not to a coil.
var<Name of PilotLight>
= new MB_PilotLight(document, "<Name of PilotLight>
", "black", "green", "red"); MBHMIProtocol.AddToDisplayList(<Name of PilotLight>
, "<Name of PilotLight>
", "read");
It gets interesting when you click in the object property window on interactivity, you will see what script code is executed when the mouse clicks and moves to the object. Be aware some objects seem to have no interactivity, however their interactivity is hidden, since the object as Push Button is a grouped object that contains multiple objects. If you ungroup it, or better double click on them, you can select its child objects, where you find interactivity properties. Simple Pilot Lights have no interactivity at all, since the user can not change anything on them. You can observe this in detail if you open the svg file in a xml editor.
Push buttons need nothing in the <script> section. Everything is done entirely by the interactivity parameters in the svg drawing. Push buttons can act differently, they can be instantaneous this means as long as you press they are on if you release they are off or they can be toggle switches, if you click they are on if you click again they are off. For toggle switches the user needs to know if they are on or off. To indicate this Pilot lights can be used that store the status of the toggle switch and show it to the user.
Interactivity parameters for an instantaneous switch:
id="<some sub id inside the PB object>
" onmouseup="MBHMIProtocol.WriteImmediate('<PB obj>
',0);" onmousedown="MBHMIProtocol.WriteImmediate('<PB obj>
',1);" class="buttonactivate">
Interactivity parameters for a toggle switch:
id="<some sub id inside the PB object>
" onclick="MBHMIProtocol.WriteToggleImmediate('<PB obj>
', '<pilot light obj>
');" class="buttonactivate">
For this purpose the pilot light object must be in the MBT_ReadList as well as in the mbhmi.config file, this means it must be an modbus object and when the HMIServer acts as modbus client, then the modbus server must actively set the pilot light object.
An alternative with no direct feedback involved uses the same push button object instead of the pilot light. In this case the push button object must be in the MBT_ReadList and will be polled by the modbus. Since the server gets the status of this push button it can send back a response to a dedicated pilot light.
MBProbe is a TCP/IP modbus client that comes with mbtools. It is a good application to develop and test modbus nodes and modbus servers.
To start it go to the directory where it is and ./mbprobe.py. This will probably fail since the default values will not find anything, to get more specific add parameters as: ./mbprobe.py -p 8680 -h localhost -r 1502 -c y -a y that connects to the local host on the modbus port 1502 (no root port) and it connects on start up and reconnects automatically when connection is lost.
Again, not much can be seen in the console so open the link http://localhost:8680/readdata.html in a web browser and you can read and write to the modbus server (slave). This allows also to set and modify the parameters as a connect and disconnect.