Linux-Based PLC for Industrial Control
The mechanism employed by the gmm enforces semantics very similar to those in existing standard PLCs, but the two are not exactly the same. Situations arise where the exact same semantics are required, and this is resolved by the synchronization library. This library simplifies the task of the module programmer but leaves a lot of flexibility for the end user.
The synchronization library uses standard semaphores to synchronize the modules but does not make this apparent at its higher level interface. Module synchronization revolves around the concept of synchronization points. The end user can configure a PuffinPLC with a certain number of synchronization points (or synch points). The configuration data of synch points is loaded into the configuration memory upon PLC setup. Modules obtain handles to these points and then call a synchronization primitive to wait at a specified synch point. Having the module obtain the name of the synch point from the configuration file allows the end user complete flexibility in specifying the synchronization sequence for the application.
The end user must also define a petri net model (see Sidebar) of the sequence of events they wish to enforce. Synchronization points may be associated with the complete firing of a transition, the removal of tokens of a firing transition or the insertion of tokens of a firing transition. We also plan to support the association of synchronization points to the existence of a certain number of tokens in a place, the arrival of tokens in a place or the removal of tokens from a place, but some of these require more support from the operating system than is currently offered.
Modules waiting on a synchronization point associated with the firing of a transition will block until the transition is fired. Synchronization points associated with the insertion of places of a firing transition will never block, but they will insert the appropriate number of tokens into the places where a module synchronizes with this point. This, and the fact that the PuffinPLC will not fire a transition unless there is a module waiting on a synchronization point associated with that transition, implies that the semantics the PuffinPLC supports for the synchronization petri net are not exactly those of standard petri nets. But a modified petri net provides a base from which to work.
Using a petri net model allows very complex synchronization semantics. Nevertheless, due to the complexity of configuring this model, a simplified configuration syntax is also supported; it consists of a simple execution sequence for modules. This sequence is automatically transformed into its equivalent petri net model upon setup.
Every module is required to call plc_scan_beg() and plc_scan_end() before commencing and upon completion of its scan loop. These functions synchronize with two default synch points that, if not configured, will map to the null synch point that continues execution without delay. These two functions provide the hooks for the synch library to provide module synchronization in a standard form. Modules that wish to synchronize at other locations of execution can use additional synch points as desired.
The configuration library is a collection of functions that help parse the configuration file. The file is completely parsed upon module initialization and loaded into the module's heap memory. To obtain specific configuration data, the module calls functions that scan the parsed file from the heap memory. The configuration file may include other files using the *include directive. Circular includes are detected and supported.
The configuration file may contain name = value pairs or data organized in a table, for example:
table_name value_1_1 value_1_2 table_name value_2_1 table_name value_3_1 value_3_2 value_3_3
These values may be grouped into sections under the [section_name] syntax. Generally, the data required for PLC setup, such as plc points, synchronization points and model, are all placed under the [PLC] section. Other sections should contain the name of the module instance and the configuration data for that module.
The log library is a group of functions that provide common logging facilities for all PuffinPLC-related processes. Currently, nine logging levels are supported for error, warning and trace messages. These messages, with an additional timestamp, are placed into a logging file. We plan to offer the option of forwarding these messages to the syslog subsystem, taking advantage of the forwarding capabilities of TCP/IP to a remote message concentrator.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development