Hello! I'm the CTO of Inxton! More than a decade ago my pet project turned into a full-time job - INXTON. Now I'm on a mission to bring industrial automation and information technologies together.
This article will be a short introduction to the TcOpen initiative - where we are at this point, where we are headed, what the roadmap is, and how you can be part of it.
How it all started
The initiative started with a post from Dustin Hullett, here on LinkedIn, towards the end of last year in the TwinCAT Forum:
The pandemic seemed to provide some shelter to engage in a pet/open-source project. Initially, several dozens of people met on Slack, with some very productive discussions about conventions, structure, and the patterns to adopt.
Why open-source?
There are several good reasons why to go open-source. Without spending too much time enumerating them all, let us just say a couple of things:
Open-source is fantastic because it shares knowledge and experience; bringing people together in the creation of something both productive and constructive.
Let me pinpoint something I consider very valuable: many automation companies have some enlightened developers creating libraries that meet the company's needs, and which other programmers use daily. These libraries are written through blood, sweat, and tears— to deliver an adequately abstract structure suitable for various scenarios. It takes time, often years, to provide a solid solution. It is a shame that these libraries remain available only to a limited group of developers, whilst being confined to the author's firm.
At the same time, somewhere else; other brilliant programmers are working late-night hours building libraries for roughly the same purpose! Now, these libraries heavily depend on a single person or two. What happens if these people leave the company (for whatever reason)? We would end up with code that nobody else understands, with a sort of black box solution. No support, and no further development.
Open-source projects answer this kind of problem: the collective knowledge does not rely on a single person's expertise — the experience is shared across a community of developers, thus preventing a single point of failure.
...the collective knowledge does not rely on a single person's expertise — the experience is shared across a community of developers, thus preventing a single point of failure.
Here is what we decided to do
The Inxton team will keep working on TcOpenGroup/TcOpen fork. We are currently providing between two and four contributors to lay out the foundations. There might be some moments of silence due to the other responsibilities we have, but we will return.
We are committed to this project because we are crafting it as a next-generation version of our existing non-public libraries. Once ready with the basic construction, another team from MTS will join the ranks to contribute to specific components (robotics, vision, etc.).
We have made some design decisions during the past few months; they reflect two factors: our background in machine building; discrete automation (we think along the lines of this paradigm), and to build upon our existing framework that we have developed over numerous years.
Open-source projects universally lose their initial momentum. Some of them drown into oblivion, some grow slowly, and some die to resurrect one day when the conditions are more favourable. I believe it would be a real shame if this project did not continue the mission stated in Dustin’s post.
TcOpen as a framework
We believe we can do better with a framework than without one. Here are the main reasons: a framework unifies the way that we create and interpret a software solution. It can relieve the programmer of various tasks. Allowing him to focus on solving actual problems, instead of having to program the condiments (alarms, state initiating/management, coordination, etc.).
A framework also helps to organise the program's structure — making it easier and faster to navigate and apply the changes for other programmers. It also helps to craft better components and ultimately deliver better applications. Without entering into technical details about how the framework is structured: we put a lot of effort and thought into making it sufficiently generic/abstract in order for it to suit as many applications as possible.
We understand that imposing a framework requires more than learning the programming language. It may also mean that a specific framework does not fit some classes of projects.
These are the risks involved in this decision. However, we believe the advantages of the framework make it well worth the input!
Presently, we are discussing the mechanism for using the TcOpen components without the framework for those who already have an existing codebase. In this case, some of the framework features might be lost, but the component's functionality will be maintained.
Based on our experience, there are some areas of general discomfort across projects that we would like to address in this TcOpen project. Here are some of them:
- Coordination (coordination primitives, sequences, etc.)
- Observability (automated alarm systems, logging, hierarchical events organisation)
- Hierarchical program structures
- Automation of monotonous tasks (I/O binding)
- Reusability
- Data-driven applications
TcOpen is Object-Oriented
Besides the practical aspect of this project, there is yet another one, as we understand it — to bring a breath of fresh air to PLC programming; we will focus on Object-Oriented design to the maximum extent it is allowed in the TwinCAT 3 implementation of IEC-61131-3.
It might be too much for some people to digest; we understand that.
The crucial point here, is that the object-oriented approach allows for componentisation that is simply not possible with the procedural paradigm.
We do not want to pour new wine into old barrels — that is not good for the wine, nor the barrels! TcOpen will be written in ST-OOP. We plan to have a solid replacement for SFC in the ST implementation.
That being said; we actually opened a discussion into the implementation mechanism — to wrap the OOP blocks in "traditional blocks" that do not exhibit OOP characteristics. This is in a separate project that will not limit the design of the core libraries.
Questions about compatibility and portability
Beckhoff HMI
The Inxton and MTS teams will focus on creating UI user controls for WPF, and then Blazor technology. We are committed to maintaining compatibility/cooperability with Beckhoff's HMI. The community is warmly welcomed to contribute to Beckhoff HMI components. A maintainer with solid experience is needed here.
CoDeSys systems
There is no explicit promise of portability to other CoDeSys platforms. Still, we will seek to manage abstractions to keep the TcOpen code base adaptable to other CoDeSys systems.
Non-CoDeSys systems
There is no intention (for obvious reasons) to support codebase portability, nor interfacing to other non-CoDeSys platforms (Siemens, AB, and the like).
What is TcOpen road map?
We just moved from the Inxton/TcOpen fork to the TcOpenGroup/TcOpen fork — Pull request discussion with the work and conceptual descriptions can be found here.
Q2/2021
By the end of June 2021, we will deliver the TcOpen Framework as a preview — with some essential primitive components for digital sensors, single-output actuators, pneumatic cylinders, and drives; an easy-to-get-started project template will accompany the preview release.
Throughout the same period, we will be porting some libraries for CRUD operations on the databases (MongoDB, and in the pipeline; InfluxDB). These will work with Inxton. Another feature that we will incorporate is security access control in the Inxton applications. These features are necessary to develop the end-user applications at MTS, and for other Inxton users, to allow the testing of TcOpen in a production environment.
Q3/2021
We will add new components (robotics, vision). Depending on the feedback from early adopters and the community; we will release an RTM (Release to manufacturing) version.
We will introduce NET5/6, Blazor support, and libraries. These technologies will open new possibilities for building web-based applications as an alternative to WPF.
What's next?
This is as far as we can see at this point; it will certainly be an adventure! I am sure we will not run out of ideas, and the project will continue to grow in maturity and size.
The ultimate goal is to gather together a community to create a set of libraries that individuals and companies can use.
Help needed
Open-source projects rely on a community of contributors. It is not very common for projects in industrial automation to be open-sourced. If you are considering becoming a contributor; please add comments here, stating your needs (Git knowledge, how to work on Github, workflows, etc.). We will try to provide information and tutorials for you to get started.
Contributions
Submit ideas to discuss in GitHub discussions.
Submit issues (what you miss, bugs you found, etc.) here.
Submit Pull Requests with your code contribution here.
Become an early adopter (battle-tester), get the repo, or use pre-release packages (when available), and provide feedback.
Documentation help is needed, especially from native English speakers, for documentation reviews (orthography, grammar, clarity). The documentation site under construction is here, and here is the documentation repository.
Thanks for reading to the end! See you on GitHub, where the code lives.