Control.com - Nerds in Control

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

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
wboyes@putman.net

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 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.

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

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

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 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

In reply to Armin Steinhoff: The PC/104 systems are for "embedded" use, with all the advantages and disadvantages that this brings. If someone is trying to run off the shelf software, they had better research whether it will run on that specific board before using PC/104. On the other hand, if you are writing custom software and want to bury a computer down inside a machine in a difficult environment, then PC/104 is probably a very good choice.

If someone is not sure what they are doing, want something that is very similar in capability to a desktop system, and don't have a particularly difficult environment, then one of the small form factor PC formats might be a better choice.

I just had a look at some PC/104 CPU boards, and there seem to be two classes. The run of the mill variety are 100 to 133 MHz. The high performance ones are 400MHz. to 1.4GHz. The faster ones however often need special heat sink arrangements to get rid of the heat and some use CPU fans.

There are faster and slower PC/104 CPU boards, but even the fastest PC/104 CPU board is much slower than the typical desktop PC sold today. Not only are the CPUs clocked slower, but most of them use CPUs that have a lower instructions per clock rate.

This *is* to cut power consumption and heat output (which are more or less the same thing). Most of the applications they are used in need to be fanless and often do not have any external ventilation. Desktop PCs today often have massive fan systems to keep their CPUs and graphics cards from melting down (some even have liquid cooling systems). Most PC/104 CPUs are fanless and many don't even need heat sinks.

In embedded applications, often slower is better. Getting rid of heat is a major design consideration so it is best not to generate the heat in the first place. This make the job of the programmer more difficult, as they have to write more efficient software to get the same job done.

The Mini-ITX systems that I mentioned have the same restrictions. Mini-ITX boards that are intended for industrial use come in fan and fanless versions. The fanless versions are always slower than the fan-equipped versions. To get rid of the fan, they have to clock the CPU slower. The slower Mini-ITX boards are roughly comparable to the faster PC/104 boards (and often use the same CPUs).

Cases for Mini-ITX boards are typically ventilated, often with auxiliary fans. There are sealed enclosures for Mini-ITX, but these have special hardware to connect the CPU heat sink directly with a finned heat sink on the outside of the case. Getting rid of heat from a small case is a problem even for a board that only consumes 14 or 15 watts.

The other small form factor SBCs probably have similar feature and restrictions to either the PC/104 or Mini-ITX. As so long as you are using an x86 type CPU, they are all working with more or less the same chips and the same laws of physics. Other CPUs such as POWER, MIPS, ARM, etc. have different parameters, but that was outside the scope of our original discussion.

And in general the "Green PCs" have more speed/watt than older designs. There is no reason the same chipsets can't be done in PC104 and leave all the media spigots off and achieve even better ratios. It's just extremely unlikely that they will do this for $65.00. In capability/$ it's gonna be awful hard to beat entries like the PC2500 and leaving stuff out won't lower cost much.

Regards
cww

In further reply to Armin Steinhoff: The comments I originally made with regards to PC/104 have to be taken in context with the subject of this thread. In the particular application in question, I was cautioning Dirk to be sure that PC/104 was suitable for what he was doing, and that it could be that a small form factor PC may be a better choice.

To better summarise what I was saying with regards to PC/104 systems.

1) PC/104 is an embedded format. This has advantages, but also imposes restrictions.

2) PC/104 will be slower than a conventional desktop PC and with less RAM. This doesn't mean that it is too slow for any job, but for example you wouldn't want to try to run MS Windows Vista on one (if it is even possible).

3) "Typical" PC/104 systems come with or have available a tailored Linux distribution, but they don't have a complete compiler suite on board. This means that MAT programs would have to be cross-compiled on a separate PC and downloaded to the PC/104 system.

4) An interpreter may work, but a fast byte code or threaded interpreter should be used.

5) Off the shelf soft logic systems may run, but the user would have to check in detail as to whether that specific soft logic system will run on that specific CPU board.

A few months ago, Marc Sinclair mentioned that a recent Siemens HMI (TP177) is running on Linux.

In reply to Dirk: Most of the soft logic systems on the market today were developed at least 5 to 10 years ago. The market concept for most of them (including Siemens WinAC) is that the user buys a copy of the software, and then sticks the CD into a desktop computer that they bought from a local computer store or ordered on-line from one of the big vendors.

When the soft logic software was being designed (5 or more years ago), any consumer grade computer that you bought came with some version of MS Windows. Linux was well supported (at least from 5 years ago), but only in the professional server market. You can buy desktop PCs today from Dell, HP, etc. with Linux, but that is a more recent development.

IsaGraf supports a wider array of platforms, but they seem to have been targetting a slightly different market than companies like Siemens. Siemens was targetting the same market as people who were buying their conventional PLCs, while IsaGraf appear to have been targetting more sophisticated users, such as companies building standard machinery.

About 10 years ago, a number of PLC customers (including General Motors) were promoting the idea of a standard PC based automation platform that would free them from vendor lock-in. The idea was to run soft logic systems on PC hardware with a Microsoft OS.

Although there were some applications, the idea never found much popularity. In my opinion, the original concept didn't really address any of the real problems, and added some very serious ones of its own.

It didn't solve the problem of vendor lock-in because the promoters were fixated on the hardware and didn't consider the rest of the system. They could now choose hardware from third party PC vendors, but were still running proprietary application software on a proprietary operating system. Switching soft logic vendors still meant your existing PLC programs and programming software couldn't be used with the new soft logic systems.

In exchange for no real benefit, we got fragile PC hardware and an operating system whose best known feature was the "blue screen of death". To top it off, the soft logic systems were usually more expensive than an equivalent conventional PLC in the same application.

If all you wanted to do is run some basic ladder logic to control a machine, a conventional PLC wasn't a bad choice. Modern ones aren't that expensive and they're ready to go out of the box. A soft logic system wasn't a good choice if you were just trying to save a bit of money.

Step forward to today however, and we have a different situation. Compact, rugged PC systems with no moving parts are off the shelf for a reasonable price. Linux and BSD operating systems are available which are reliable, simple, and well suited to these applications. Both free and non-free soft logic systems are available.

What's missing is really two things. One is packaging and documentation. Packaging is putting a complete system together, or at least offering all the pieces with a guaranty that they will work together. People don't want to hunt around to get one bit here and another bit there and then hope they all work together. Look at the questions we get all the time along the lines of "will software 'x' and software 'y' work together on Windows Vista Ultimate French Version?".

Compare that to installing software on a typical Linux distro using a package manager. You start up the package manager, type in a search term for what you are looking for, and then choose the package you want out of the selections available. A few clicks, and everything you need is installed and working in minutes. For soft logic systems to become that easy to use on Linux, people will have to package them for Debian, Ubuntu, Fedora and Mandriva. Packaging isn't hard, but someone has to do it.

The other thing that has been missing is the end user motivation. As I said earlier, if you are just trying to save money on your Allen Bradley or Siemens PLCs, then look at cheaper vendors such as Koyo. Where the motivation to use a soft logic system comes however is when you are trying to do things which conventional PLCs do poorly or not at all. Conventional PLCs are poor at things like processing or storing large amounts of data. They aren't good at working with hardware or software from other vendors or integrating into a larger system.

Where soft logic systems might start to show their real advantages is when controlling the machine is only a small part of what they need to do. In other words, where the soft logic system has the advantage is when it is an addition to another system rather than a stand alone controller.

I think you're missing the substantial numbers of companies that provide programmable automation controllers (the name coined to refer to these
software-enabled embedded computers because the phrase "SoftPLC" is a trademark) complete with packaging, system design assistance and a host of
system integrators that are effective and experienced. Just off the top of my head:

National Instruments
Opto22
Wago
Phoenix Contact
Advantech

There are certainly others, but it is 5 am in a hotel room, so I might be forgiven if I left anybody out.

Most of these systems are using WinXPembedded or WinCC. These controllers have been around long enough now that their usability and durability is no longer in question.

As Dick Morley said, when talking about the PLC, "It was always a computer. We called it a controller so we wouldn't scare the operators."

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
wboyes@putman.net

And you have the choice of Windows or Windows. Any color you want as long as it's black, or in this case, blue.

Regards
cww

In reply to Walt Boyes: Dirk's question was why most of the PC based soft logic systems seemed to require MS Windows as the OS. He hasn't been too specific about what his planned projects are, but they seem to involve a soft logic system being closely integrated with some other software on a PC based system.

As for as the products you metion (NI, Opto22, Advantech, etc.), I would call them PLCs. They are dedicated controllers running on custom hardware. That's what a PLC is. The "programmable automation controller" phrase seems to be more a marketing term than anything else.

The discussion about "packaging" referred back to his questions about using a soft logic system with a Linux OS on a PC. Most Linux distributions have a "package manager" that takes care of installing and removing software. Preparing the software and documentation for easy installation is called "packaging" and is done by the software authors or by someone else ("package maintainers").

The description probably doesn't mean much to anyone who has only used MS Windows, because Windows package management is extremely primitive to non-existent (it's pretty much a free-for-all when it comes to installing software). None the less, Linux users perceive software packages in the following hierarchy: supported or core packages > extra packages > packages outside the repository > unpackaged > CVS.

Right now, all the free automation related projects for Linux seem to be in the "unpackaged" to "CVS" zone. That's not a problem for people who know what they are doing, but it's a barrier to most people who aren't interested in anything outside their distribution's repositories.

They are not PLCs. The difference between a PLC and a PAC is the rigid
proprietary OS of the PLC, versus the more open capabilities of PACs to use
different OSes, like Windows and Linux. PACs have more capabilities, are
more open, and are designed to be interfaced with control systems more
easily than PLCs. I respectfully disagree that it is more marketing than
anything else. I will not debate the degree of openness among available
OSes. Even Linux can be construed as "not open" if somebody wants to waste
the hot air.

The fact is, I/O and field controllers are becoming more powerful, more
capable and more interfaceable every day...and more like a network node than
a standalone piece of electronics.

This is getting very interesting from the enterprise control point of view.

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
wboyes@putman.net

In reply to Walt Boyes: I had a look at the products you listed, and found the following information.

National Instruments - The NI system is basically a small form factor PC in a Compact PCI rack with Labview. What about if I put a Mini-ITX board in a nice box and loaded it with Labview? Would that be a PAC, or do I have to charge $5000 for the motherboard like NI before it qualifies? I would call this a PC based system.

Opto22 with PAC Project - The Opto-22 system seems to be genuinely something different. However, it appears to be primarily oriented towards small scale process industries rather than being a general purpose system. If you want to say that it has a combination of features that puts it somewhere between a PLC and a small scale DCS, then I won't argue with you over it. So, we'll call this one a "PAC".

Wago. They don't use the term "PAC". The closest they have would be the 758 series running the CoDeSys IEC 61131-3 on RT-Linux. Why is this not a PLC?

Phoenix Contact with PC WORX - This is simply their IEC 61131-3 software running on their PLC-like hardware. Why is this not a PLC?

Phoenix Contact with Steeplechase VLC (flowcharts) running on their PLC-like hardware. Why is this not a PLC?

Phoenix Contact with "High-level language". This is just a set of interface libraries for their I/O to allow you to write C++ or VB programs on their MMI panels (or PCs). It's not a PLC, but I don't see how it can qualify as a "PAC" (even though they list it as one).

Advantech - Their "PAC" is the ADAM-5500. This has the Datalight ROM-DOS OS and lets you program in Borland C++ 3.0 for DOS. I'm sure that brings back old memories for a lot of people, but what is so special about putting an SBC into a nice rack?

Now let's deal with your qualifying points in turn:

> The rigid proprietary OS of the PLC, versus the more open capabilities of
> PACs to use different OSes, like Windows and Linux. <

How do you know what OS is used in any particular PLC (if it uses one at all)? The newer ones probably use something like VxWorks, or even an embedded Linux. Perhaps you are trying to say that you can run third party application software on the "PAC" hardware as well as the manufacturer's own offerings. That is probably the case for the NI hardware, as it is really just a small form factor PC. For any of the others though, I have my doubts.

> PACs have more capabilities, <

Labview may be better at test systems than a PLC, but it is probably not as good for typical machine control. I've already agreed that the Opto-22 system is something different, so I won't argue that further. Of the remaining systems, two are just IEC 61131-3 (just like a PLC), one uses flow charts (just like some PLCs), and two just let you bang away at a 'C' compiler (which I suppose in a way qualifies as "more capabilities").

> are more open, <

The NI system is a PC, so I suppose we can call that "open". Now, what does "open" mean with respect to the rest? Why is the Opto-22 system "open"?

> are designed to be interfaced with control systems more easily than PLCs <

Er, PLCs *are* control systems. You're going to have to explain that one a little better I think.

So out of 7 possible "PACs", we have one for which there appears to be a genuine case (Opto-22), one PC based system (NI), three PLCs running IEC 61131-3 or flowcharts, and two which are basically barebones systems for which you write your own software in C.

If we look at the Opto-22 web site to see why they think it qualifies as a "PAC", we see the following points.

> Operate using a single platform in multiple domains, including logic,
motion, drives, and process control. <

Doesn't AB Contrologix do this as well?

> Employ a single development platform using common tagging and a single
database for development tasks across a range of disciplines.
>
> Be programmable using software tools capable of designing control programs
to support a process that "flows" across several machines or units, integrating multiple domains into a single system. <

Siemens calls this "Totally Integrated Automation" for their S7 product line.

> Tightly integrate controller hardware and software. <

A PLC is tightly integrated.

> Provide efficient processing and I/O scanning. <

And, a PLC processes I/O efficiently.

> Operate on open, modular architectures that mirror industry applications,
from machine layouts in factories to unit operation in process plants <

This is a bit vague, but it might be the real meat of what makes the Opto-22 system different.

> Employ de-facto standards for network interfaces, languages, and protocols,
allowing data exchange as part of networked multi-vendor systems. <

This has more to do with being a minor vendor as the same is true for most small PLC vendors as well. If you have a small market share, you can't afford to play the proprietary protocol game.

So, if there is a difference between a "PAC" and a PLC, then it seems to be a fairly subtle one.

Hello all,

Yes, this is one view of the usage of soft logics.

Soft logic applications have big advantages if you have to integrate many different subsystems.

For instance... a graphical application of a driver display can have interfaces to fieldbus systems, C++ coded control tasks and an embedded text database (SQL). It does also communicate to different hardware subsystems besides the GUI interface. It does in general a lot of computing for the animated GUI and the verification or conversion of input data.

This is more or less typical for soft logic systems, but such a kind of integration isn't possible with a ladder logic based standard controller.

BTW... QNX6 offers in the meantime very interesting features for secure control applications... multi-core support makes sure that computing power is always available and additionally the partitioning of CPU time makes sure that all critical tasks will get the necessary CPU time.

Best Regards,

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

That one's easy. If you wish to be a MS "partner" and get the info you need to compete in the majority market, you will be pressured to be all MS. And if you sell into the Linux market, for example, your pricing and perks will go south. At one time, it was actually written into the agreements. They've probably had to get more subtle since the monopoly convictions. And Siemens _is_ doing things with Linux, but between the exclusive licensing and the monopoly bias and hegemony on the consumer side, it's pretty hard to develop a customer base to sell a product into. MS has spent a great deal of effort in making it difficult to jump ship and they have been very effective. Margins in all aspects of the PC business are such that very little pressure can make you unprofitable. Having to pay retail for Windows for example, would eat all of the profit in the general computing class machines. They can easily get their way and as you can see if you look at it objectively, they have, with few exceptions. Any guesses why IBM got out of the PC business? And why puppet organizations with open in their name, standardize on Microsoft technology? These things are invisible from inside the monopoly but become obvious quickly if you try to do business outside.

Regards

cww

I have not seen anything that proves this. Actually talking to them included. At least, as far as WinAC is concered, I don't know about their true PLCs.

Dirk

In reply to Dirk: Siemens uses Linux as an embedded OS in some of their products (as do other companies). I doubt that many of their sales reps would know much about it though, as they don't generally know what embedded operating systems they use in any of their other products.

Siemens also has their own private Linux distribution they call "Siemens Industrial Linux". Their consulting arm uses this in projects for things like integrating your production lines to your ERP system. Unless you are a really big company with lots of money to spend though, they won't talk to you.

Neither of the above has much relevance to your project though. Embedded operating systems are invisible to the user, and I doubt that you will ever deal with their integration consultants. Siemens Industrial Linux isn't available for download, so don't waste time worrying about that either.

You see, the strategy is working :^). Even Siemens can't afford to upset Bill. That's why it's kept very quiet and a lot of things will run on Linux with no outward indication from firms that have a large exposure to Microsoft pricing and support.

Once they figure out how to get their neck out of the noose, you will start to see Penguins all over. Certainly in the EU first, where they don't own _all_ of the politicians and can't make it effectively illegal to open things up under the sheepskin of IP protection.

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.

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

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

Yes that would be interesting.

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

Regards

cww

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

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.

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.