I am looking for some SoftPLC to work with on a handful of projects I am looking at. I was wondering if anyone had a good list of what all is out there so I know where to start looking. I have only a limited knowlage of things, based mostly on poking through this page, so any help would be appreciated.

My major thought would be to work in Linux, but I am starting to gather that the only SoftPLC for Linux is the one being developed here. Is this true, or are there some others available, open source or commercial?

Thanks for the help.

Dirk

 

Dirk:

The most popular ones out there are:
ISAGraf
KW
CodeSys
Probably in that order.

Most of the major PLC vendors alos made some sort of Soft Logic PLC, but most have pulled them. I think ISAGraf might be your best bet and I know it's target independent code will run within the Linux runtime.

Good Luck,
Mark Massa, PE

 

The name "SoftPLC" is a trademark for a particular brand of product. The proper generic term is "soft logic system".

I can point out a few examples of free soft logic systems to you:

http://mat.sourceforge.net/

http://sourceforge.net/projects/petrilld/

http://sourceforge.net/projects/classicladder/

http://sourceforge.net/projects/opencontroller/

These are just some examples that I know about on Sourceforge. There are others as well, but many of them seem to be in early stages of development. If you are examining a project on Sourceforge, be sure to follow enough of the links to be able to see what the real status of a project is. Some of the summary pages seem to be several years behind where the project actually is. It appears that the people working on things are not keeping all the web pages up to date.

In addition to the above, I am working on my own project, but it will be a while yet before I have anything in useful condition.

ISAGraf is probably the best known commercial soft logic system that supports Linux. Some of the other major vendors use Linux as an embedded OS in their commercial products, but those are not considered to be "soft logic" systems because they are running on dedicated hardware. The following page also has some useful links to free and commercial soft logic systems.
"http://www.linux-automation.de/plc/index_en.html".

If you want to compare the relative sizes of MAT, ClassicLadder, and OpenController projects, here are some statistics using a standard COCOMO (Constructive Cost Model) approach:

MAT:
Total Physical Source Lines of Code (SLOC) = 58,681
Development Effort Estimate, Person-Years = 14.39 Total Estimated Cost to Develop = $1,943,408

Classic Ladder:
Total Physical Source Lines of Code (SLOC) = 13,786
Development Effort Estimate, Person-Years = 3.14 Total Estimated Cost to Develop = $424,670

OpenController:
Total Physical Source Lines of Code (SLOC) = 21,644
Development Effort Estimate, Person-Years = 5.05
Total Estimated Cost to Develop = $681,940

I haven't used any of the above, so I can't make a recommendation as to which is the "best" (however you define that). I would suggest that you contact
Curt Wuollet (who is a frequent contributor to this list) for more information. I am sure he would be happy to help you.

Whether the above are what you really need depends partly upon what your applications are. Are you looking for a stand alone system that just more or
less takes the place of a conventional PLC, or are you looking for something to embed within another software project (i.e. add some PLC-like programmability to a program which is not mainly a PLC)?

If the latter, I may have some additional suggestions for you. It is possible to write a simple byte code interpreter style soft logic system with comparatively little effort provided it isn't intended as a complete stand alone system. If that is what you want, let me know and we can discuss it further.

 

Funny that you should mention contacting Curt, as before I even found this website I had emailed him from contact information from some other website his name was on.

As for the soft logic PLC, it will be embedded within other software, so any suggestions are helpful. At this point I am more just seeing what is out there to do some research on what would work best without me having to code something up myself.

I know I saw somewhere else on this forum that someone was trying to port WinPLC and maybe WinAC onto Linux. Anyone know how that is going or went?

Just so many colorful options to look at.

Dirk

 

With regards to porting WinPLC or WinAC to Linux, I think you have that a bit mixed up. Curt Wuollet was interested in porting Linux to the *hardware* which the WinPLC soft logic runs on (an embedded computer which slots into an Automation Direct DL205 series PLC rack).

As for embedding a soft logic system into another program, that happens to be one of the (several) goals of my own project that I am working on. That is, the soft logic system is structured such that it could easily be used as a set of libraries which are embedded in another program (I had computerised test systems in mind) as well as used stand alone or as a simulator.

In my case I am trying to closely emulate popular PLCs currently on the market. The goal is to have a framework that can be readily adapted to support many different PLC architectures, rather than having something which is optimised for one specific PLC only. It is also intended to be very simple, so that anyone with sufficient interest could adapt it to support a PLC that they were interested in. It will have a corresponding programming package that works with it.

Because of these goals, I am writing it in Python. The emphasis is on ease of implementation, rather than on performance. I still get about 4 ms per thousand boolean operations (or 4 microseconds per instruction, if you prefer to state it that way). That is about equivalent to a previous generation PLC, and is more than adequate for what I have in mind. I estimate that in realistic applications the I/O network will be the bottleneck, not the logic system anyway.

If it were implemented in something like 'C' with a fairly simple byte code interpreter, my tests seem to indicate it would be about 40 to 50 times faster. It would probably also take about 20 times as much work to write, so I am happy to make the trade off in favour of ease of implementation. My compiler plus the core of the interpreter is only about 100 lines of code. Actual instructions of course are on top of that.

The MAT PLC (mentioned in a previous message) I believe takes the approach of compling the PLC program to 'C', and then compiling the 'C' to machine code. It is a bit more complicated, but it gives you the fasted possible execution speed. That might be important if you are trying to run a very large program on slow hardware. I think that Classic Ladder and OpenController use interpreters (I looked at them very briefly, but didn't examine them in detail).

I have investigated a *lot* of alternative ways of implementing a soft logic system. I can say that for a soft logic system that is to be embedded into another program, the best approach is to keep it simple. I spent a lot of time trying to adapt various general purpose frameworks, plug-in systems, virtual machines, threaded interpreters, parser generators, etc., because I believed it was easier to adapt an existing complex system than it would be to create my own simple one. Eventually, I just sat down and started writing code from scratch and made progress quite quickly.

Any conventional PLC or soft logic system consists of a few common elements. I will go into the details of some of these in the examples below, but first I will just outline the elements.

1) First there is the instruction set. We'll forget about ladder logic for the moment, and just talk about instruction list (IL). Ladder is just another way of displaying IL on a screen. The PLC really executes the IL.

Having a simple soft logic system means having a limited instruction set where each instruction does only one thing (i.e. no multi-purpose instructions). For example, don't have an instruction which does one thing if you give it a bit parameter, and something entirely different if you give it a word parameter.

2) There is location to hold the instructions in. This is typically an array or array-like data structure, but can also be done by other means. There would normally be an instruction pointer (array index) to keep track of which instruction we are on.

3) There is a data table. This holds all the data memory locations. Again, this is an array or array-like structure. If the data array is an array of 2 byte integers, then we can think of this as being a 16 bit PLC.

4) There are data types and addresses. Data types are boolean, byte, word, double word, and real. The more data types you support, the more code you need to implement to deal with them. Addresses are direct addresses, pointers, and constants. I call constants an "address type", because you deal with them in much the same way (you're still fetching data as an instruction parameter, you're just not reading it from the data table).

5) There is a logic stack. This is where the boolean instructions (contacts and coils) store their intermediate results. This is just an ordinary stack data structure. The boolean instructions just work on the top of stack with push, pop, or replace operations.

6) There may be one or more accumulators or an accumulator stack. These are just memory locations where math instructions operate.

7) There is a compiler to turn IL source code into PLC instructions. This is a lot simpler than it sounds (as will become apparent from the examples). PLC IL grammar is normally very simple.

8) There is a scan loop which executes the PLC code, updates the I/O, does the various other overhead (e.g. updating counters), etc.

If I was implementing this in 'C', it would look more or less like the following:

A) The instruction memory would be an array of 4 or 8 byte words. Each word holds 1 instruction plus all the parameters associated with that instruction. The size of the word (4 or 8 bytes) depends upon how many parameters we allow per instruction, and how big each parameter (address or constant) may be.

B) The data table would be an array of 64k words of 2 bytes each. The first few k-bytes would be the inputs, the next would be the outputs, next the flags or internal coils, next counters, timers, special memory, etc. The remainder would be general purpose word memory.

C) The compiler would be very simple. It would just read in the instructions from a text file and compile them one at a time. - Take a line of text. - Split it into tokens which are separated by spaces. - The first token should be the IL instruction. Look it up in a look-up table. - Didn't find it? Error. - Did find it? Get the associated parameter validator, which could be a regular expression. - Apply the regular expression to the parameter. - Does not match? Error. - Does match? Use another look-up table to convert that address label to a data table array index. - Store the instruction and parameter in the instruction array. - Repeat for the remaining instructions.

D) The scan loop is also very simple. It would just do the overhead (I/O update, timer update, etc.), following which it would execute the instructions. Instruction execution would go like this: - Read the first instruction from the first byte of the first array element. - Use that byte as the key to a big switch statement. Each case of the switch statement just contains a call to a function which implements the instruction. - Call the function while passing the entire array element (or a pointer to it) to the instruction function as a parameter, so the function can pull the PLC parameters out of it. - Increment the instruction pointer and repeat until we get to the end of the PLC program.

If we were implementing this in Python, we could do it a few different ways:

A) The instruction memory could be done several ways. If you are using an approach similar to that described above, it would just be a list of tuples (instruction reference and parameter). Another very simple way is to compile the PLC program directly to Python source code, and then compile the Python source to Python executable code. You just then execute the code object rather than storing a list. I will describe this a bit more later. I have used both methods.

B) The data table could be either an array (using the "array" module), or it could be a dictionary. In my case, I used the array, because it allowed addressing the same location as bit, byte, word, or double word. If I specifying my own instruction set instead of trying to emulate an existing one, I would be inclined to try using a dictionary and allow each memory location to be addressed only one way. This would probably be simpler as well as execute faster on average. Moving bits into or out of words could be done through special instructions.

C) The compiler would be similar to the 'C' example, only simpler as the look-up table would be a dictionary. Instead of storing byte codes, the instruction list would store references to the functions implementing the instructions.

Alternatively, you could compile the PLC IL to Python source code, and then compile the Python source code to a code object. The difference between this approach and the previous one is only a couple of lines of code, but it executes a bit faster. The disadvantage is that if you want to have "jump", "call", or "loop" instructions it gets a lot more complicated. I started out with this approach but switched to the previous one because of these problems. None the less, it has certain advantages and if you don't need "jump", "call", or "loop", then it is also slightly simpler.

I don't compile the PLC address labels to array indexes, but instead resolve the addresses at run time using a dictionary. The reasons for this have to do with the goal of supporting multiple different PLC architectures. Generally, it is simpler in my case to decode addresses at run time, but it probably allows for faster execution to decode them at compile time.

D) The scan loop is very similar to the 'C' example, except there is no need for the big "switch" statement. Where we compile to references, we just call the reference, passing the parameter in. Where we compile to a Python code object it is even simpler, as we just "exec" the code object to execute an entire scan.

To embed either of the above in another program is also straightforward (and simpler than a stand alone soft logic system). Whether you use the 'C' version or the Python version depends upon what language you prefer to use. You can of course use some other language as well.

i) We call the compiler from somewhere in our main program loop and have it compile the PLC program. Loading or reloading the program is under control of the main program. "On-line programming" is simply a matter of loading a new source program on demand.

ii) On a regular basis we call the PLC scan loop function, passing in the inputs. The scan loop executes once and returns the outputs. Other addresses can be passed in and out as necessary.

iii) The main program then takes care of updating the I/O between calls to the scan loop.

iv) The main program can have screens which display data table address values for troubleshooting and debugging purposes.

v) The main program is responsible for taking according to whatever faults the PLC library passes back to it.

I haven't mentioned anything about PLC programming software. I am working on that as well, but have less to show for it so far. I believe the MAT people are working on using the editor from ClassicLadder. You might want to have a look at that. Alternatively, you might decide that it is good enough to simply write IL using a text editor. I'm not sure what your actual application is, so I can't make a recommendation on that.

MAT is GPL. I don't recall for sure, but I think that ClassicLadder and OpenController are both GPL. If your project is compatible with that, you might be able to directly use code out of one of those. However, keep in mind that you could spend more time adapting something than writing your own.

Alternatively, I believe that you can share the data table with MAT and run it as an independent server. You would need to ask Curt Wuollet for more details on that.

Since I don't know exactly what you are doing, it's hard to make a recommendation. I hope the above has been some help though. Even if you don't plan to write anything yourself, the above can probably help you evaluate whatever you do look at. If you have some more specific questions I would be happy to answer them as well.

 

Your post actually answered alot of questions that were in the background as well as gave me a better idea what I am looking at.

As I stated, I am still doing research at this point, so I am curious as to how well your project and MAT and the others like them compair to the COTS stuff like Isagraph and WinAC.

I only have so much time here at lunch to get this all out, so the most interesting thing I am curious about is how the code compiles down to c then machine code.

Is it possible to develop the PLC like code on some dev station then compile it and move it onto some embedded system? In other words, could I work on my favorite laptop and develop the code then install it to something like a PC104 or other type platform without having the software PLC structure installed as well?

Please pardon all the typing mistakes and misswordings, doing this update on my 30 minute lunch break.

Dirk

 

That would be the idea I would favor, develop on any old PC and deploy on the fancy hardware. Of course, I would like to see the target having enough resource to run an appropriate Linux. That way you would have easy networking and could distribute the system with sockets or the like. You can already get a very low cost system that could serve for both development and deployment. With Gb of flash available cheap these days, the last barriers are coming down, While you can't run Vista. :^) you can have a very rich Linux environment without a hard drive or any moving parts.

Regards

cww

 

I will let Curt Wuollet can answer questions relating to MAT.

As far as hardware is concerned, if you are using PC/104, make sure to design your software system very carefully. A PC/104 system is *not* a PC in a smaller box. PC/104 systems have very limited hardware in terms of speed, RAM, and storage. Most PC/104 systems are supplied with Linux, but it is a very stripped down version intended for embedded use. If you are using PC/104, you will almost certainly *have* to compile on another computer.

Also, PC/104 hardware usually runs at much lower speeds than modern PCs (66 to 100 MHz is typical). This is to cut both power consumption and heat output. It means though that if you want to use an interpreter, it had better be a fairly good interpreter to get good performance out of it. I wouldn't recommend my Python based interpreter for this sort of application.

For embedded hardware, you may wish to have a look at Mini-ITX and other similar small form factor PCs. These are more like a PC, but are still available in low powered fanless versions. You can use solid state disk drives, and even CF flash cards for disk.

If you use any sort of PC in an embedded application though, be sure to turn off all the ACPI features in the BIOS. ACPI has never really worked well, and will give you no end of grief in an application that requires reliability.

I said I would let Curt Wuollet can answer questions relating to MAT. I lied. I will answer a few points. Compiling IL to something like Python or C is straightforward, provided you aren't trying to do something that Python or C doesn't do.

Suppose we take the following simple example. Here is a rung in IL:

STR X0 AND X1 ANDN X2 OUT Y0

Here it is compiled to valid Python source code:

CodeStr = "PLCLib.STR('X0'), PLCLib.AND('X1'), PLCLib.ANDN('X2'), PLCLib.OUT('Y0')"

That's valid Python source code provided that I have a module called "PLCLib" containing functions called STR, AND, ANDN, and OUT. To compile it to Python executable code is just: CodeObj = compile(CodeStr, 'errorout.txt', 'exec')

This executes it: exec(CodeObj)

With C, the process is a bit more complicated, but the concept is the same. Of course, the example above is a very simple one. Things like subroutine calls, jumps, and loops are more complex. Have a look at the MAT source code to see in detail how they do it (or ask Curt Wuollet).

"Compiling" a program just means converting it from one language to another. IL usually has a very, very simple grammar compared to normal high level programming languages.

Compiling a language to 'C' and then calling a 'C' compiler to turn it into machine code is actually a very common technique. The hard part comes in making the output of this integrate into a complete soft logic system. I won't go into detail on that though. I have limited my own research to interpreters (bytecode and to a less extent, threaded).

If you have more questions, let me know.

 

Don't die of shock, Curt, but you are right on the money here. If anybody doesn't think so, go look at the eeePC by ASUS.

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
[email protected]

 

"While you can't run Vista :^)"

I could not help but laugh at that. Vista, running a critical control system.... Priceless.

 

Dirk,

As with most questions on controls, a lot depends on the application.

If you need ladder logic then you have several options. However I have found that often PC based control is better suited to flow chart programming. Products like Steeplechase from Phoenix Contact or Think-N-Do from Automation Direct provide a lot more flexibility and ease of use over programs that where designed for PLCs and ported to PC base control. And they are less expensive. Steeplechase, for example, provided what I consider a logical approach. Can be edited on the fly and the flow chart is a pretty good HMI. If you want to add additional HMI you can download OPC widgets or use Iconics, or some other commercial HMI. But these are your choices and you don't need to pay for them if you really don't need them.

My.02

Mike

 

Hi Michael

First, Jiri Baum reads the mail here and can answer MAT questions in far more detail than I can. I think the reasons for using PC104 hardware and the like are disappearing rapidly except in special cases. The stuff works and the form factor is handy when you need the smallest available. But it is low volume and fairly high cost as well as being less generic and PC like than the Mini ITX and similar being offered. PC104 would be good for a backplane system like I have drawn up but not fabbed as it has a good enough bus to plug inexpensive IO into. But if you look at the PC2500 as an example, it's the heart of the $200 Linux PC WalMart has sold a pile of, and it has plenty of power for development and deployment in vast numbers of applications, costs $65 and is a high volume product. If you have the room and can use networked IO, there's no contest.

Regards

cww

 

This generation of "Green PC" boards effortlessly crossed into PLC territory without intent. They serve both the consumer market for quiet. small machines and will be eminently suitable (with appropriate software) for many areas that PLCs are trying to evolve into. The reliability will be comparable and the value in commodity volumes will
be outstanding. I see hard times ahead for the high buck panel PCs and OITs as well as high end control.

Regards

cww

 

In reply to Mike MacLean: Whether the programming is done via ladder logic, flow charts, or any other language, the PLC or soft-logic system is executing either some form of IL code or machine code. All of the higher level programming languages simply compile down to the lower ones. Whether it looks like IL or a flow chart on the screen of your computer is just a matter of how the programming software decides to display it.

There is nothing about executing on a PC versus a traditional PLC which makes one form of development language better than another. It's all a matter of which language you would prefer to write and maintain the program in.

It also would appear from further detail that "Dirk" has given that none of the products that you mention would be suitable for his projects. These are all stand alone soft logic systems while he is looking for something that can be embedded within a custom software system. The ones you mentioned are also all MS Windows only, which also doesn't suit his projects.

 

Yes that would be interesting.

Do you really want to turn on Q31? (allow or deny). Do you really want...

Regards

cww

 

In reply to Curt Wuollet: For an operator interface terminal or panel PC:

- LCD touch screens start at about $500 for 15 inch. These are commonly sold for POS and kiosk applications. This can be VESA mounted.

- Add a small form factor PC motherboard (e.g. Mini-ITX) plus RAM. Assume $100 to $150.

- Add flash memory plus an IDE flash adaptor, or IDE flash drive. Assume $50

- Case with power supply. Assume $100.

Total basic hardware cost is under $1000 for a 15 inch touch screen.

This is very competitive with low end MMI panels and less than half the price you would pay for a normal industrial panel PC. Again though, it isn't
something that you would want to try to run MS Windows Vista on.

 

First, thank you all for your input, it has all given me a great place to start the study I am doing for my projects.

>It also would appear from further
>detail that "Dirk" has given that none
>of the products that you mention would
>be suitable for his projects. These are
>all stand alone soft logic systems while
>he is looking for something that can be
>embedded within a custom software
>system. The ones you mentioned are also
>all MS Windows only, which also doesn't
>suit his projects. <

Very true, and with the lists and suggestions already given, I have more than enough to look at.

Oh, and thanks for putting my name in quotes, it makes me feel so mysterious.

 

I have a muse kind of question, one that I don't expect a clear answer to, because I don't think a clear cut answer exists.

With all the stability problems and security issues with MS, why haven't the big companies like Siemens developed their own software into Linux? From what I can tell WinAC is an amazing piece of software who's only downside when compaired to ISaGRAF and others is that it is MS only. (That and it only works with PROFIBUS and P-NET as opposed to being open to all fieldbus).

 

Hello again,

>I will let Curt Wuollet can answer questions relating to MAT.
>
>As far as hardware is concerned, if you are using PC/104, make sure to design
>your software system very carefully. A PC/104 system is *not* a PC in a
>smaller box. <

It depends on what parts you have assembled together... but x86 PC/104 hardware in PC hardware.

>PC/104 systems have very limited hardware in terms of speed,
>RAM, and storage. <

Sorry... there are not such hard limits.

>Most PC/104 systems are supplied with Linux, but it is a
>very stripped down version intended for embedded use. If you are using
>PC/104, you will almost certainly *have* to compile on another computer. <

This is common for *embedded* target systems.

>Also, PC/104 hardware usually runs at much lower speeds than modern PCs
>(66 to
>100 MHz is typical). <

A typical PC/104 system has at least a CPU with a clock rate of 400MHz. Typical low power systems are running with up to 1.2 GHz (Intel Mobile /
VIA Eden / VIA C7 2GHz!)

> This is to cut both power consumption and heat output. <

No, no this was yesterday.

>It means though that if you want to use an interpreter, it had better be a
>fairly good interpreter to get good performance out of it. I wouldn't
>recommend my Python based interpreter for this sort of application. <

Good choice!

>For embedded hardware, you may wish to have a look at Mini-ITX and other
>similar small form factor PCs. These are more like a PC, but are still
>available in low powered fanless versions. You can use solid state disk
>drives, and even CF flash cards for disk. <

The 3.5" SBCs are also interesting.

Best Regards,

Armin Steinhoff

 

Hello all,

>I have a muse kind of question, one that I don't expect a clear answer to,
>because I don't think a clear cut answer exists.
>
>With all the stability problems and security issues with MS, why haven't
>the big companies like Siemens developed their own software into Linux? <

Good question because there are other "open source" operating systems like QNX 6. The sources of the kernel, the utilities and the network system are now available.

>From what I can tell WinAC is an amazing piece of software who's only
>downside when compaired to ISaGRAF and others is that it is MS
>only. (That and it only works with PROFIBUS and P-NET as opposed to
>being open to all fieldbus). <

BTW... there other SoftPLCs which are more exciting the WinAC or ISaGRAF.

The general purpose graphical programming tool DACHSview and its QNX6 based target allows besides cyclic processing also event oriented processing.
Event oriented processing needs less CPU power and supports response time to events in the range of micro seconds. (Events are e.g. hardware interrupts, messages or released semaphores) This tool is open to all fieldbusses, SQL data bases, GUI applications and C/C++ applications. It's
used e.g. for the development of complex driver displays of locomotive control systems and control systems for automatic car park systems.

However, if you like added it to the list of "SoftPLCs".

Best Regards,

Armin Steinhoff
http://www.steinhoff-automation.com