open-source implementation of a PLC

T

Thread Starter

tanstaafl

Does anybody know if there's an open-source implementation of a PLC? There used to be PuffinPLC (formerly LinuxPLC), but is seems to have fallen off the map.
 
I have one called MBLogic.

Download site: "http://sourceforge.net/projects/mblogic/"

Web site: "http://mblogic.sourceforge.net/"

For the download site, there are actually three different packages, so you have to click on "View all files" to see all of them (MBLogic, MBTools, MBLibs). The soft logic (PLC) package is MBLogic (which as of this moment is also the default download file). That's the way that Sourceforge works, so I can't make it more convenient than that.

I made a new release of MBLogic a few days ago but haven't updated the web site yet (I'm working on that right now). The latest version though adds on-line editing in IL format (add, delete, or edit subroutines while the system is running).

As well as soft logic (PLC) functions, it has built in Modbus/TCP client and server functions, a web based HMI, an enterprise ERP web service server, web based on line help, and a web based monitoring and control interface. It runs on both Linux and MS Windows.

MBLogic is intended to be a complete automation platform. I am adding new features regularly, so let me know if there is something you need which it doesn't do yet.

Installation instructions are in a PDF file which is distributed with the package. Once you have it installed, you can access the rest of the documentation via the web based on-line help.

The MBTools package contains several different optional stand alone programs which operate independently of the main MBLogic. These are HMIServer (stand alone web based HMI), MBAsyncServer (a Modbus/TCP proxy server), MBProbe (a web based client tool for manually reading and writing a Modbus/TCP server for testing and troubleshooting purposes), and MBPoll (a command line client for testing Modbus/TCP servers).

Typical use for these is to use MBAsyncServer to simulate field I/O while developing an application, and to use MBProbe to test and commission the actual field I/O during installation. HMIServer has been surprisingly popular as a web interface for conventional PLCs that have a Modbus/TCP server (slave).

The MBLibs package is for developing custom applications in Python. It contains the Modbus/TCP client driver and the soft logic system as libraries which you can include in your own programs. Typical uses for these are for writing custom programs for production test systems.
 
Actually, now that I think of it you probably want to look at this too: "http://www.beremiz.org/"

This uses the MAT soft logic engine, but I'm not sure if it is the same version as on Sourceforge. It looks like they are using Sourceforge for the mailing list and forums, but are hosting the most up to date MAT code at beremiz.org. The newest version is from last Thursday (the 10th), so it seems to be actively maintained and developed.

Beremiz has a soft logic engine (MAT), and an editor (IL, ladder, ST, SFC, FBD). They have plans for an HMI, but I haven't seen anything concrete for that yet.

Beremiz is a strict IEC 61131-3 type soft logic system that runs on Linux and MS Windows (via MinGW apparently). I haven't used it, so I can't comment on it too much. The screen shots for the editor look impressive though.

Beremiz has a different emphasis that my own project (MBLogic). Beremiz is concentrating on being a conventional but complete IEC 61131-3 soft logic system. My own project focuses on providing a complete platform that integrates well into the overall factory and providing extra features on top of the base soft logic system.

The two projects (Beremiz and MBLogic) are based on different principles and are not aiming at the same target, so which one makes the most sense for you depends on what you are planning on doing with them.

As for "PuffinPLC", so far as I know the history was this:

1) There was a lot of talk on this forum about an open source soft logic system. Finally some people got together and decided to start writing it.

2) This forum (Control.com) and Ken Crater provided some help in getting it started. At that time it was called "PuffinPLC".

3) It them moved to Sourceforge, where it changed its name to MAT. While there, it became a working soft logic system.

4) It was then rewritten to support IEC 61131-3. That was a huge project, because IEC 61131-3 is really hard to do properly.

5) During this time it became associated with some people who were working on an IEC 61131-3 editor.

6) The two of these together are called Beremiz. The project as a whole seems to have moved to the "beremiz.org" web site, while still keeping their foot in the door at Sourceforge.

7) They have plans for something called "SVGUI", which will be an HMI. So far as I can tell though, they don't have that working yet.

As I said above, I haven't tried Beremiz/MAT, so I can't comment on how well it would work for you.
 
C

curt wuollet

Thanks, Michael

Even I didn't know that :^)

A couple of points that need clarification.

When I founded what became MAT, one of the fundamental principles was that it be GPL Open Source Software. That is, it should be publicly owned and available to all, free, the only restrictions being against making it less so. We moved to Sourceforge when Ken Crater, with the best of intentions, began normal business things like protecting the name as a trade mark and the like. This was in direct conflict with public ownership which we felt was critical to stay Open to participation by people who would not care to be perceived as contributing to any particular (perhaps competing) company, a definite turn-off in this hyper proprietary arena.

There were, as in any OSS project, many conflicting ideas for direction and scope and the means to get there. I did, not as many have, install myself as a benevolent dictator, opting instead for "the best (and most) code wins". Since I was not a CS type, this quickly went far beyond me and far from the technical concepts I cherished, so I stepped out of the way.

For the curious, I envisioned that a Soft PLC should be written very much like a "hard" PLC. That is, while taking advantage of the power of running Linux and the *nix way of doing things, the part that solves logic and controls things should be as small, simple, and therefore reliable as possible. And written in C, the lingua franca of *nix and the embedded world, understood by the most people, and therefore most inclusive. Some here, have rubbed my nose in the "failure" of MAT. This is a fundamental misunderstanding on their part. The goal was to have Open, freely available automation tools. There were none, even the rhetoric precluded this. Now, there are quite a few. And even the management of Rockwell Automation "gets" the concept. There was no plan for domination, choice is quite enough.

Regards
cww
 
W

William Sturm

IMHO, most successful open source projects start with one person (or maybe a close knit group) getting the code architected and have a good rolling start before turning the code loose for open development.  That way, the direction is fairly well set.

Bill Sturm
 
If anyone wants an idea of the size of the MAT project, this is what I get when I run the source code through sloccount (using a COCOMO cost model):

Lines of code: 58,618
Person-years of development: 14.37
Total value: $ 1,941,217

That is just the soft logic system. The Beremiz editor is in addition to that (it's a lot smaller though). The above is using the standard effort factor, so the schedule and value estimates are probably a bit low for this type of software.

The currently active developers appear to be in France and Portugal, which may explain why we don't hear much from them in an English discussion forum. So far as I can tell the project is active, although I don't follow it closely. Those figures come from a version that is only 10 days old.

Beremiz/MAT seem to be intended to replace PLCs. It is pretty conventional in that respect. If I were to compare it to a proprietary product, then I think that Codesys comes the closest. I'm not trying to say who is better here, I am just comparing design philosophy. Codesys licenses their product to a lot of the smaller PLC manufacturers, and that is the software you are probably using when you buy an "IEC 61131-3 compatible PLC" from anyone other than the big vendors. There's no technical or business reason why some of those smaller PLC manufacturers couldn't use Beremiz/MAT instead. The same applies to large machine OEMs who want their own control system rather than depending on the big automation vendors.

My own design philosophy for MBLogic is a bit different. I am aiming at applications where the soft logic component itself is only part of the overall control platform. HMI is integrated. So is system management. All documentation is on-line in the system itself. The user can add their own documentation (e.g. equipment manuals, procedures, etc.). It has a protocol intended for ERP integration. Future additions will include recipe management, data storage, messaging, etc. The idea is to have advanced features which work with the soft logic system itself, but still have them integrated into one easy to manage package. It is intended to run on a PC, although that could be a diskless, fanless PC if you want improved hardware reliability. PCs have come a long way since we first discussed this issue in the 1990s.

So, I'm not trying to do the same thing as Beremiz/MAT, which is why I'm doing my own project instead of working with them on theirs. I suppose I really ought to contact them though, as I think they've got some stuff that I could use, while I've got some stuff that I think they could use.

As for the PuffinPLC versus MAT trademark issue, I can see how that would be important. If the current developers get enough interest from the sort of market that I identified above, trademark title would have to be clear and unencumbered. Etherial/Wireshark went through some pain over the same issue because they weren't careful when they started.

However, there is no reason why whoever currently owns the "PuffinPLC" trademark couldn't package up the Beremiz/MAT software and offer it under the "PuffinPLC" brand on their own hardware. The whole point of a GPL license is to let people do that while making sure that nobody (contributors or users) gets shafted in the process.
 
C

curt wuollet

That certainly is one model, but it depends, I think, somewhat on the scope of the project. Smaller projects can be done that way, because you can live with less contribution. But, one contradiction is that many of the best and brightest really want to be the architects. And I have to say, at this point, I'm far from sure what people with interests in both CS and automation want. To attract people, for free, they have to get what they want from working on the project. And they must, almost, be OSS zealots. I had all kinds of people who wanted to do something on Windows with MS tools. They just don't "get" Open. And I'm deeply suspicious that they don't "get" reliability either. And I'm afraid some knowledge of very low level systems programming is needed. I think that there is simply a very small pool of people with the right stuff for these highly specialized apps. That is, they are way different from desktop apps and what works there.

Regards
cww
 
In reply to William Sturm:

With this sort of software, you probably don't want a large team. More people would just get in each others way. There is a book you may have heard of called "The Mythical Man Month" which talks about this.

As for setting a detailed plan and sticking to it, I'm not sure that works well in practice. You can set a broad goal, but I think you need to be flexible as to how you get there.

My own experience has been that you get e-mails from people who say they need to do 'x' for a customer and they want some advice as to how they can change your software so that it will do that. It may not have been in your plans, but they've got a real customer who wants that feature, so that is some pretty valuable feed back as to what people really want.

Based on the feed back that I've been getting, my most popular program has been HMIServer (it lets you put a web based HMI on a PLC, robot, or other similar device). That program only came about by accident as a byproduct of another development effort. I released it because I thought that someone might find a use for it. It turned out that quite a few people were able to find a use for it. As a result of that, I keep developing and improving it. It certainly wasn't in my original plans though.

So, I think you need to have a vision and a general goal, but you have to flexible as to how you reach that goal.
 
If you use a full blown PC for automation, is a PLC software really needed???

Of course you need drivers for I/O using the PLC and fieldbus protocols out there.

But do we need more?

My opinion is that if you use a PC you should use C/C++ or eventually a scripting language like Python + some libraries that make life easy.

A automation will need
- I/O software for PLC and/or fieldbus protocols
- PLC logic that runs forever
- HMI system
- Logging
- Alarm
- production planning
- quality control (statistic software)
...

Thus computer programming knowledge is needed anyway.

The PLC programs are almost like:

init();
startSomeClosedLoopControllersAsSeparateThreads();
while(1)
{
readInputs();
doSomeLogicBasedOnInputs();
writeOutputs();
}

I think it would be better if PLC programmers would learn a real programming language. Effort should be put into the development of library functions that make life easy. Effort should NOT be put in developing integrated development software that tries to mimic a PLC programming environment.
 
W

William Sturm

There are two main issues with using a standard PC language like C or Basic for machine control.  Both issues are related to maintenance and debugging, not program development.

1. Debugging a running process is difficult. You cannot typically break your program to view variables when a machine or process is in cycle. You would need monitor screens to display variables in real time.

2. Training of support staff to debug machine. Many maintenance techs are familiar with ladder logic. A-B and Siemens have huge training networks to train a companies support staff.

Both of the issues can be resolved, but it is not easy to do. Especially issue #2, since so many people are involved.

Bill Sturm
 
From a technical perspective, the structure of the program you have outlined will work. And, I think most (if not all) PLC programmers know several programming languages. (in my case, I have spent about 50% of career on computer and network programming, etc.; and about 50% on PLC/HMI work).

But don't loose site of the fact the PLCs exist to replace computers in industrial control applications. I lived through that transition. In the early 1980's it was common to deploy industrial control systems written in various languages on various flavors of hardware (e.g. C, Pascal, Fortran, assembler(s) on S100, VME, Multibus, DEC and HP minicomputers). The deployment of systems built from the aforementioned technologies was successful in every way except for ongoing software maintenance (i.e. tweaking the process) by the end-users.

PLCs developed as a means of hosting a user-friendly language and configuration on rugged digital hardware. And by user-friendly, I mean from the perspective of the end-user's plant maintenance personnel.

I see many posts to the list suggesting that PLCs be replaced with PCs and that ladder logic is a poor language. In fact, history shows that the opposite change took place over 20-odd years ago. And in most cases, PLC deployment is well received and has supported easy continuous improvement by end-users.
 
In reply to pvbrowser: What a soft logic system does is provide a ready made framework for an automation application. It saves you from adding a lot of common boilerplate to every new application. Also, IL is a short hand notation for common logic constructs.

The other thing it does for you is to separate the application configuration from the boilerplate. 95% of any application is going to be the common boilerplate. By separating out that last 5% you make the system easier to maintain. With a soft logic system you can upgrade to a newer version of the boilerplate without having to patch in your custom code into the middle of it.

IL (and ladder) is an application specific language. It doesn't do everything, but what it does do it does reasonably well in as few words as possible.

I think a good analogy is web frameworks. A lot of routine web sites are based on a common application framework such as Django or Rails. That lets the web developer concentrate on the features that make that web site unique without having to worry about the routine stuff.
 
C
Hi PV

> If you use a full blown PC for automation, is a PLC software really needed???
>
> Of course you need drivers for I/O using the PLC and fieldbus protocols out there.
>
> But do we need more? <

No, you don't strictly need a PLC type logic solver or graphical programming or cyclic operation. But these have persisted for a reason. It's far more predictable than event driven or interrupt driven sequential programming and _much_ easier to do well. And understandable by non programmers.

The real beauty of using a PC and a _reliable_ OS with excellent multitasking, is that you can do the PLC thing for hardware control and conventional PLC tasks, and also handle those things that are really not suitable for that mode of operation as another task, written in the manner most suitable to that task. For example networking can be carried out at network speed and math can be performed at nearly processor speed, allowing slices for the PLC task. And this too is much easier with a good, well understood, flexible scheduler running the show.

> My opinion is that if you use a PC you should use C/C++ or eventually a scripting language like Python + some libraries that make life easy.
>
> A automation will need
> - I/O software for PLC and/or fieldbus protocols
> - PLC logic that runs forever
> - HMI system
> - Logging
> - Alarm
> - production planning
> - quality control (statistic software)
> ...
>
> Thus computer programming knowledge is needed anyway. <

That is the challenge, to make this other stuff as approachable as PLC programming. This can be done reasonably easily with good multitasking as well, as is shown by the number of packages used by PLC people to do these "other" things. Once you can run these things easily on one box, unlike the Windows proliferation of one box per task, adding the relatively tiny PLC part is trivial compared to adding those other tasks to a PLC. The above is _not_ a prejudicial statement, by the way, it is the way IS people do server stuff on Windows. The reasons are something they don't want to discuss much. It seems *nix is just better at multitasking as the norm there is to run everything on one box. Raw processor power is no longer an issue as modern PCs have almost unbelievable power with even moderately efficient software. If you question that, you should try some more efficient software.

> The PLC programs are almost like:
>
> init();
> startSomeClosedLoopControllersAsSeparateThreads();
> while(1)
> {
> readInputs();
> doSomeLogicBasedOnInputs();
> writeOutputs();
> }
>
> I think it would be better if PLC programmers would learn a real programming language. Effort should be put into the development of library functions that make life easy. Effort should NOT be put in developing integrated development software that tries to mimic a PLC programming environment. <

I don't necessarily disagree, but PLC programmers disagree strongly and they are the target audience. OSS lets you give everybody what they want, with graphical programming tools for the PLC guys and C or HLL programmers can do what they want or need, too. What's not to like?

Regards
cww
 
In reply to all the responses of my post above.
###############################################

We run the open source project
http://pvbrowser.org
pvbrowser is for HMI / SCADA. It provides an application framework for process visualizations.

As was said above a lot of code is needed for the framework. Exactly this code is generated by our IDE. The task of the programmer of the visualization is to code the "slotFunctions" handling the events only. Thus creating a visualization with pvbrowser can be compared to the effort and complexity of creating a webpage.

For the PLC part it is very similar.
readInputs();
writeOutputs();
is almost the same for each project.
All that will be necessary is to configure the system via some INI-Files.

doSomeLogicBasedOnInputs();
is what really cares.

startSomeClosedLoopControllersAsSeparateThreads();
is not a problem at all because you only have to think in the parameters of a closed loop controller (parameters of a PID controller for example).
See:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlController.html

As was said
> Debugging a running process is difficult...
We approach this by a "shared memory".
A piece of RAM that is shared by several processes.
See:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlSharedMemory.html

All interesting parameters of the running process are written to this shared memory and can be seen in a comfortable way using our visualization.
And if this is not enough there is
printf();
the best "debugger" of the world.
By tracing your process with printf(); it is relatively easy to debug a process.
It is needless to say that these printf(); statements can be switched ON/OFF via the visualization.

#######################################

I think all the discussion about is:
doSomeLogicBasedOnInputs();

For my part i can live very well when this is coded in C/C++. You will probably have a good library to make your live easy. Thus you can concentrate on the logic of your process.

If you want to have that graphically we are here.
Example Software:
http://www.logicals.com/products/logi.CAD/

That provides a graphical editor for your control system. The result will be converted to C by a generator and be deployed on a computer.

Could we do something like that ?

Is somebody out there willing to start developing something like that as open source?

I could imagine joining such an effort by taking our

http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classes.html

as a basis for the framework that will be generated from the graphical editor.

Almost everything that is missing to do something like logiCAD is to have such a graphical editor. The code generator is trivial.

Thus
doSomeLogicBasedOnInputs();
could become graphically also.
 
In reply to pvbrowser: You asked: "The result will be converted to C by a generator and be deployed on a computer. Could we do something like that?"

You might want to have a look at this:
"http://www.control.com/thread/1252697981". You'll see a discussion about something called "Beremiz/MATIEC" which just happens to work like that.

MBLogic is also discussed, but that works on somewhat different principles.

In either case though, since the input/output update and scanning control is always the same, there is no reason for the users to have to write it themselves. That gets generated automatically. The "doSomeLogicBasedOnInputs();" part gets automatically translated into C from IL (or ladder, SFC, etc.).

Something to realize though is that a useful soft logic system has a *lot* of boilerplate code besides just the basic soft logic itself. For example, in my own MBLogic program only about 40% of the program is directly associated with the soft logic program translation and execution itself. The rest is the system management and monitoring, HMI, communications, and other functions. And that 40% will probably shrink to 20% or less as more features are added.

Something else that you shouldn't underestimate is the need for documentation. The system needs to operate in a consistent way so that a standard set of documentation can be used to describe it. MBLogic has approximately 75,000 words of documentation and more than 130 drawings, and I don't see how you could do with less.

So, once you look at a complete system, you'll find that the logic execution is actually just a small part of it all.
 
@M. Griffin: Thank you for the link to
http://www.beremiz.org/

I know about the "boilerplate code".
This is already covered in pvbrowser too.
What is missing in pvbrowser is IEC programming software.

In Beremiz HMI seems to be done in SVG.
We do it with SVG and/or any Qt widgets including WebKit widgets.

I will evaluate the PLCOpen Editor and figure out if generating our C/C++ sourcecode can be done using the XML data from the PLCOpen Editor.
 
Top