Ladder Editor For Linux.

C

Thread Starter

curt wuollet

Hi all

I am hoping to pick brains here and survey how far we have come and how much is known by the group as a whole.

As the old timers know. I want very much to use Linux in automation. Indeed I have used it in many unusual ways, to integrate robots and CNC and conveyors and even a Linux based automation system project and a tiny but workable Linux PLC program (more my style). Not bad for a old C hack, I suppose.

What's been banging around in my head for a little while now, is how to use Linux with PLCs in the _usual_ way. I'm assuming many of the wonderful new generation of tiny, fanless, powerful, all in one embedded processor boards could be morphed into a PLC.

We are all familiar with today's PLC tools, good and bad. Some of these come from vast corporations and often that shows. Some have no doubt been kinda shoestring efforts and often that shows. All have been based on Windows or DOS before that. As the old timers also know, I'm not a GUI guy. But, practically everyone younger, (and some older) is. So, rather than pore through the thousands of possible ways and then do things my way :^). I thought I'd get the consensus of the people who are involved in automation and are of the GUI world, on the best tools and practices to develop a new Generic PLC Ladder Editor using the best FOSS tools available. In order to be taken seriously, this would have to be a GUI tool. I've looked at Glade and Kdevelop, etc. Some say, Python, some TCL and friends. What would be the best RAD tool for ladder?

Output would be some sort of table that could be fed to a code generator for download to a PLC. I've looked at Glade and Kdevelop, etc. I don't know if I'll have the time to code it, but it's beginning to look that way :^). Or for that matter, as long as it happens, I don't even need to be involved.

If such a thing existed, it might well induce someone with the money to do the whole thing to do the right thing.

Soon.

Regards,
cww
 
Have a look at Beremiz (www.beremiz.org). It's an IEC 61131-3 software system that does ladder, IL, FBD, SFC, and ST. The actual logic execution system is the MAT PLC (which you were once involved with).

One of the companies working on it will be shipping it as part of a commercial product some time this spring where it will replace their previous controller product line. The hardware will support CanOpen and Ethernet. The link to the product announcement is on the front page of the Beremiz web site. It's a "PLC" in that it is hardware that you would mount in a panel just like a regular PLC. Underneath though it is basically what you are talking about.

The Beremiz editor is written in Python with wxWidgets. It runs on Linux or MS Windows (one of the demo videos shows it running on Ubuntu). There is an HMI, but I don't know if that is being shipped with the hardware product mentioned above (there is more than one company involved in the Beremiz project).

The HMI system is SVG based and uses a lot of similar principles to what I have been working on (even including using Inkscape as an editor). I have been talking to one of the Beremiz developers about what we can cooperate on with regards to HMI features and he is interested in having more contributors to any part of Beremiz. You might want to contact him and see what you can do to help them.

The PLC vendor is a smaller company in Europe. You might want to get involved with Beremiz and then talk to some small companies in the US who might take a similar interest in it. There could be some interesting opportunities there for all concerned.

I haven't used Beremiz so I can't give a real opinion of it. If you are looking for a proprietary system to compare it to (in terms of what it does) however, I think it comes closest to Codesys which quite a few smaller PLC vendors license to embed in their own hardware. I think the market for it would be small hardware vendors that don't want to deal with Codesys, or who want more control over product development but don't want to create a complete system on their own.

I have my own MBLogic project that I'm working on. It's not really a traditional "PLC" though. It's more about system integration and taking advantage of the web in a PC based soft logic system. I am planning on starting to work a ladder editor within the next few months (it's strictly IL editing so far), after I have the current HMI improvements complete. My tentative plans are for it to be a web based AJAX type application, with the work being split between the browser and the server. It's an open project, so anyone is welcome to work on it.

If you are looking at doing a traditional "fat client" for a "PLC" however, then you would be hard pressed to find a better way of doing it than Python plus GTK or wxWidgets (which is what Beremiz uses).
 
C

curt wuollet

Hi Michael

As one of the more ambitious authors of Linux software in automation, I am glad to see you chiming in. There are, no doubt, many others who do things with Linux, but not to the point of complete systems. I do think whole systems are one of the best ways to take advantage of the power of Linux because the facilities are there to do the whole ball of wax under one roof. And this is a trend in the industry, to address the whole picture synergistically and do more per box.

My problem is one of scope. I think one reason that MAT ran out of gas was that the scope kept expanding. It certainly got beyond my modest talent and memory capacity fairly quickly. That wasn't necessarily a bad thing :^) as it does go on even though I have no inkling of what they are doing. I'm not even sure that I'm smart enough to run what it has become :^).

Meanwhile, back in the trenches, to automate something, lots of folks buy a PLC, fire up the programming software for that particular beast and have at it. Most of this is still, thinking in logic, building rungs, test, rinse and repeat. Indeed, when I am doing automation, the majority of what I am asked to do are the small projects, using a lot of bricks and a PC. I would like for that to be a Linux PC. Yes, it may lead to scada, HMIs, DCS, MIS, and the rest of the alphabet soup, but nothing I've seen really aims at the part that a lot of us spend most of the time looking at. Some of the programming tools take a whole CD or more. But some of them fit on a floppy, that, I could actually see completing before I run out of money and become homeless or retire, depending on the economy.

Some programming tools sell for thousands of dollars, some are free already. The folks who want thousands of dollars seem to be quite incorrigible, only the market can change that and they will go down fighting. What I would like to come up with is for those who see it as necessary to sell PLCs and not a profit center. IF they had a decent package they can adapt to their PLC at little cost, perhaps the fact that it runs on Linux would be palatable and I can cause that first to happen. After that, World Domination :^).

What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target. It would be something all of us can use, just like the stuff that comes with the PLC. The question is, how best to do it?

Regards
cww
 
When it comes to traditional hardware PLC i use XP within VMware on a linux host system, because i can use what the PLC vendor delivers.

When using (embedded) PC hardware i do not use ladder at all. The ladder code is the minor part in an automation system anyway.

Our principle can be seen here:
http://pvbrowser.de/pvbrowser/pic/prinzip.png

As you can see we have a data acquisition that reads the inputs cylically and stores the values within a shared memory. Output commands can be send over a mailbox to the daemon that will send them to the hardware outputs. The daemon(s) are configured with an ini file.

Once the I/O is connected to the computer you can do visualization.
See: http://pvbrowser.org

Instead of ladder code we now use C/C++ for the PLC logic. In principle this is a endless loop where inputs are read, some logic is applied and outputs are written. This "PLC logic" can run as a separate process with access to shared memory and mailbox. Programming is supported by a library that handles the frequently used stuff.

If you want to have a graphical programming environment you would need a graphical editor which allows you to place "blocks" and to connect them with other "blocks" and I/O.
From that you would generate our C/C++ program.

The above principle is used in
http://www.logicals.com/products/logi.CAD/
for example. But this is Windows only.

As graphical editor
http://www.scilab.org/ (similar to LabVIEW)
would be a good starting point. You would now need a code generator that produces the C/C++ code for that model.
 
W

William Sturm

CWW Said : "What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target."

Isn't that what the IEC 61131 folks have been pushing for for years?  You would probably find PLC editing software or libraries that will work with Linux.  The missing link, IMO, is hardware. 

An "open source" PLC hardware platform would be very beneficial.  Maybe a home brewed microcontroller board with local or remote I/O.  It needs to be something that can be made and serviced by virtually anyone.  An open micro, such as an ARM or even an 8051 would be nice too.  Maybe ARM for larger systems and 8051 for brick systems?

Does this help, or have I strayed too far from your original topic?

Bill Sturm
 
J

James Ingraham

At the risk of being ridiculed, have you thought about Java? You immediately get cross-platform support, and NetBeans / Matisse (or even Eclipse with Matisse) is an excellent GUI builder. True, Java isn't fully open yet, but it's getting there. And there are LOTS of open source projects out there to draw from. Another advantage of your ladder editor being written in Java: put the editor on the "PLC" and pull it up remotely using a Web browser. No more worrying about which version of the editor was last used on that system, or running around looking for the project file.

-James Ingraham
Sage Automation, Inc.
 
C

curt wuollet

Hi Bill

I quite agree that we could use a truly open hardware platform. And yes, that can be done. I have several PCs operating as Linux PLCs in use in various places with hardware add-ons that I offered here. And I have, on paper at least, a design that will give a PC104 computer industrial grade I/O. And between the two, I'm confident it will work and meet the practical needs for reliability and "hardness". But, there are relatively few who will build gear and push it through management and naysayers and assume the risks. What people seem to want is a fully "productized" system with the proper certifications and ratings and approvals. That I can't do on unemployment. Even a band of brilliant hardware hackers can't do that. I'm not even sure that a well funded startup can do that because you'd burn cash until the approval bodies got around to making you jump through hoops, eventually approving or not, depending on the golf schedule. And I'm not sure you could compete on the low end with the $69 Koyo Click or similar offerings that are popping up.

But Koyo gets at least some, and I think most, of their software from a small outfit called Host Engineering. I've corresponded with the Host folks on a few occasions about various things and they are nice folks, but are singularly uninterested in Linux.

But suppose someone like Koyo could get a Linux programming toolset for their hardware at little or no cost. And it would be supported by the community. The community could do more than Host or Automation Direct to make the stuff really good. Where's the downside?

That's what I would like to try to make, the machine independent part of a programming package. It would need a "driver" to adapt to a particular machine, but they support a whole range of machines with one package. They could certainly keep their old package, but also offer an Open Linux package. And how handy would it be if you could program several PLC brands with the same package? The community is the only hope for that.

Regards
cww
 
Curt,

I think in a way we are going backwards in our attempt to use sophisticated software tools (C/C++, Python, Java) to generate mediocre automation software (Ladder, SFC, etc).

I think it would be more interesting to see an automation system based on C/C++ running on an RTOS with all of the familiar automation concepts easy at hand (timers, IO access, Monitoring/debug). I have had some experience evaluating a commercial motion control product that used Xenomai but had a sophisticated front end editor/uploader GUI (yes, it did run in windows, but you could do something in Linux too, albeit on your own...). What was interesting to me is that you had the power of a hardened embedded linux device that could be programmed at the RTOS level but had access to IO, servos, ethernet, etc through shared memory.

One could argue that there is no point in creating an open source automation platform based on an RTOS. Its already available, what is the point? Not all automation guys (even sophisticated ones) have the time or ability to configure target OS, hardware, and development environments. They want something they can purchase, install the software, and be up and running. I believe the following is necessary for the masses to accept such a platform:

- Crafting an environment that allows normal [i.e. not Computer Science level] automation engineers to easily work with creating RTOS tasks and synchronization tools. Basically this could be a simple library of calls that set up task creation and mutex/semaphores with the least amount of work and confusion so that the automation professional can concentrate on the application, not stack size or pthread task attribute structures, etc.

- IO drivers for commercially available industrial IO in HARD REALTIME. Maybe something like Wago/Beckhoff/B&R "slice IO" using Modbus UDP for speed. You could represent the Modbus address space through function calls or shared memory interface to the user application. Some work will have to be done to figure out how to configure the Modbus polling in the driver (Maybe something already exists...) Each system I've worked with does this in a different way. I do like rack based IO in a traditional PLC, but I don't know of anyone who is selling an open PC platform CPU card for their PLC for [relatively] cheap money. Doing custom IO racks that are as nice as the plastic housed PLC IO modules is very expensive.


- Modbus TCP drivers for hardware based HMIs. Even for a system that has a VGA port, some people and applications will still appreciate a commercial HMI with all of its features. In some instances this is hard to beat. This probably can be scheduled in normal linux priority using commonly available libraries/utilities.

- Lastly, but certainly not least, a preconfigured programming environment that you can do uploads and monitor/debug. This application certainly wants to run in windows at least as an option. You have to remember that most automation people are more familiar with "C:\" than "/". The difficult question here is, do you put work into being able to run on two platforms, or do you let the high powered Linux guy do his own thing? This is fairly easy with the programming/compiling, but maybe not so much with things like a preconfigured debugger that is aware of this automation framework since it will be customized to handle specific automation related things. Maybe working in a browser is the way to go here, who knows?

At the same time it almost seems necessary to include some form of graphical ladder logic to get buy-in from people, and maybe to do some sinple logic things that ladder excels at. You have to admit that you can easily.

I do agree with Bill that a hardware platform for an open PLC would help things out, I just would like to see one work with a high power computer that can run Linux based RTOS with ease. I think in some ways the hardware is going to be difficult to overcome and that is the beauty of the slice IO systems, at least for medium sized projects. It definitely won't replace a Brick PLC, but I don't think the problem is in finding a good brick PLC since they can be had for under $100 with free software.

KEJR
 
C
Hi James

I don't often ask a question then ridicule the answer. One problem is I've done very little with Java. I'd have to learn it pretty much from scratch. I don't know if there is an equivalent to GTK or QT or better yet, higher level GUI builders. Of course, the learning curve applies to almost anything but C. And I'm not at all concerned with Windows compatibility. It would expand the scope and probably limit the project to what can be done on both. And there is already free Windows software for many PLCs and to many end users free obviously means more than Open. Right now, I'd settle for a commercial shrinkwrap package that runs on Linux, to get the ball rolling. Did I say that out loud? If Java would be the easiest, it's still in the running. I'd need some help though. I'm sure it could be done, I've seen some pretty cool Java stuff lately. Right now, If I had to come up with something soon, I'd probably do it with ncurses and a custom character set for the Linux console. Almost anything would look more modern than that :^), But it would be fast and small and in C.

Regards
cww
 
In reply to Bill Sturm: The hardware exists, provided you don't want a shoe box format. Linux is by far the most popular OEM OS on 32 bit embedded hardware (which is what a typical PLC would use these days). For I/O however, you will need to use networked I/O via Ethernet (e.g. Modbus/TCP) or CanOpen.
 
In reply to Curt Wuollet: I started off by writing a big long reply to address your points directly. The questions to ask yourself are:

A) Who do you see as being your market?
B) What would your project do for them?

If you have a software project that you want other people to use, then you need to have a "market" in mind whether or not you are actually selling anything. So, who would use it, and why would they want to?

> What I would like to come up with is for those
> who see it as necessary to sell PLCs and not a
> profit center. IF they had a decent package
> they can adapt to their PLC at little cost,
> perhaps the fact that it runs on Linux would be
> palatable and I can cause that first to happen

Beremiz/MAT are doing that *now*. Their market is OEMs who want a PLC run time and programming software, but don't want to develop their own. The first vendor is already scheduled to ship hardware based on it.

So, what is it you want to do differently? Is it that you don't like IEC 61131-3? It is a monster of a spec and anything based on it will inherently be big and complex? (That's why I gave up on it and went down a different road).

If you want to so something different though, then what would it look like? Just an editor? If so, then for what PLC? It can't be a "generic" editor that would work with any PLC, because that is either impossible, or impossibly complex to create. The whole point of a PLC editor is for it to know a lot about the PLC the programs is meant for.

So, what would the goals and the focus be?
 
In reply to James Ingraham:

>At the risk of being ridiculed, have
>you thought about Java? You immediately
>get cross-platform support,

I believe that Python would be much better for that. Cross platform support is excellent, and GUI programming is easier than it is with Java. You would also have a very rapid edit/test cycle which makes development faster in that type of application.

>Another advantage of your ladder editor
>being written in Java: put the editor on
>the "PLC" and pull it up remotely using
>a Web browser. No more worrying about
>which version of the editor was last
>used on that system, or running around
>looking for the project file.

Or use HTML5 and Javascript. No more worrying about whether you have the correct Java run time version installed. Final syntax checking can all be done server side, so you don't need two parsers, two compilers, etc.
 
N

Nathan Boeger

Writing a Linux Ladder editor as a module in the new Ignition platform from Inductive Automation would work out really well.

A lot of the framework is already in place: A cluster aware web server with database, Java NIO for multi-threading, built in serialization, built in Authentication/alerting/auditing support, Ethernet support, Database support, scripting support (via Python), OPC-UA module for device communication, a built in Java Web Start "Designer" application to house the Ladder editor.

The API exists but isn't yet documented. The platform would be a great fit for such an application - especially as an Open Source project. I can get you in touch with the developers if you're interested in pursuing that route.

-----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com
 
C
Hi Ken

You're preaching to the choir :^)

Most of that has been done and you can get the source. Well, not the translation so your average automation type can do kinematics and HRT easily, but IMHO, once you start dealing with things that need HRT, building the system and writing the software are actually not the hardest part, even my crude little 2 page PLC used memory mapped outside of Linux so it could communicate with an RT process. This is outside the scope of what I am trying to do at the moment, but hardware is a major limitation, not that you can't make hardware to do it, but that the world becomes extremely hard to deal with at even microsecond speeds. The reason garden variety automation gear is easy to use is that it's so slow. Inputs have 15 mSec filtering and outputs are totally inadequate to switch at more than a few kHz. And we live with one scan uncertainty. What you would start to see to generalize HRT stuff would be controlled impedance (Coax) wiring and totem pole outputs. It isn't just a matter of making the software easy to use. Everything becomes more complex and most of it defies simplification because physics get in the way. That said, I'm in complete agreement that a single Linux system could do all the parts, that's why MAT came to be. And I agree that slice I/O is the way to go with a 100+ MIPS processor that can do gHz networks. And you won't find anyone who is more a proponent of doing automation work in C or of building libraries to reuse code. That was my idea for a Linux PLC, to do all the things that a powerful computer with a powerful OS can do.

But, again, most of us stare at a programming tool, doing boring old ladder logic much of the time. And, if and when I get a job, chances are I will have to deal with the whole crappy Windows experience again, just to program PLCs. And spend more time keeping the crud working than programming. And maintaining everything from DOS to Vista. Someone needs to solve that problem.

Regards
cww
 
>> CWW Said : "What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target." <<

> Isn't that what the IEC 61131 folks have been pushing for for years? You would probably find PLC editing software or libraries that will work with Linux. The missing link, IMO, is hardware. <

IMHO ... the missing links is not the hardware. To find an appropriate hardware is a minor issue. What you need is software which handles the program upload and execution of it. And this execution environment (software) should be easy portable.

The use of ladder logic is simply a step back and would introduce unnecessary additional restrictions. With ladder logic you can only express a small subset of possible control algorithm. Function block display allows the representation of all control algorithm.

BTW ... we have completed our port of DACHSview-SDL to Linux and Real-Time Linux. With the usage of function blocks we can provide a development environment for the development of animated graphical 2D/3D real-time applications and control applications running secure on an and the same multi-core CPU e.g. Individual control threads can be assigned to individual cores of the CPU.

Would this be possible with ladder logic?

If someone is interested, a full working evaluation system (windows based workbench / Linux target, tested on openSUSE 11.2) is available on request.

Best Regards

Armin Steinhoff

as [at] steinhoff-automation [dot] com
http://www.steinhoff-automation.com
 
Mr Griffin,

What would be a good toolset to do a quick GUI in python that would be cross compatable? Is a certain GUI builder and/or widget set easier to get started with?

Thanks,
KEJR
 
>> At the risk of being ridiculed, have you thought about Java? You immediately get cross-platform support, <<

> I believe that Python would be much better for that. Cross platform support is excellent, and GUI programming is easier than it is with Java. You would also have a very rapid edit/test cycle which makes development faster in that type of application. <

The PLCOpen editor from
http://www.beremiz.org/documentation/the-plcopen-editor supports ladder logic. It is written in python, wxPython and wxWidget or wxGTK

So you have not to reinvent the wheel completely :)

Best Regards,
Armin Steinhoff


 
Mr Steinhoff,

I agree with most of your points. I do think that particular hardware needs to be tested and qualified to work especially when you are talking about fast communication cycles over Modbus TCP. Some devices can't handle anything faster than 5ms update.

I do somewhat disagree with your point regarding function block diagram lanaguage. This seems useful when you have a continuous control algorithm like PID or the like, but I find it cumbersome for complex sequential discrete control. Having said that, C/C++ handles sequential items brilliantly if you have an RTOS to put each sequential task on its own thread.

KEJR
 
Many years ago I used a programming tool from WRB Associates called "Ladders". It allowed a generic ladder program to be developed and you purchased the "drivers" needed to talk to a specific brand of PLC. They had it compatible with the Modicon 384/584, AB PLC-2 and the like. For reasons not related to the capabilities of the program, the package finally died in the mid-80s. That is what I think you are trying to do but today, the complexibility of the task may be more than any one package can handle. Good luck!

One thing I don't see mentioned in this thread that is particularly important is how does a plant maintenance person support these different systems. I am assuming we are talking about a Linux control system that is not necessarily Ladder based. Yes, more and more younger staff have exposure to C and other non-graphical languages but can they figure out what is happening when there is a problem? I sure don't want to be called in at 3 in the morning because the guy can't know why the machine stopped.

Flow chart (with necessary debug and monitoring) can help. Maybe I am just too old but most of the maintenance staff (from the level of skills I have run into at typical plant) "might" be able to follow a ladder diagram but that is still not always the case. They "may" be able to break out the software and look at the flow diagram but I'd have a hard time expecting someone to look at a C++ listing and know what to do.

All the projects that I have been associated with that were considered successful had a common theme. The users had to buy in on the design at least as it related to the HMI and maintenance support functions. Then the equipment had a chance to run well. If they didn't like what they saw or felt that they had no influence on design decisions (and understanding how the program runs is part of that), magically the equipment had all sorts of "issues". Whatever is supplied must be understood and accepted by maintenance or what we provide won't have much success. The major players in Automation have a leg up since more people have been trained on their equipment. Doesn't make their products better, just more accepted. That inertia is tough to overcome.

Russ
 
Top