Ladder Editor For Linux.

C
Hi Michael

Excellent and relevant points all.

For the record, no, I don't like IEC 61131-3. It seems to have created more diversity and chaos than standardization. It's an example of the rope principle: No matter how hard or which direction you push, a rope won't go where you want it to. But, it you turn around and pull, it'll follow you anywhere. And I'm a believer in standards. But, fortunately, I'm not yet subjected to software that makes it harder and more complex to instantiate logic. Most of what is done can be done in ladder and where I've been, that is the rule. No one has requested that I convert it to ST or IL or flowcharts or..... That would be the market. It's a very large part of the market, indeed many PLC vendors still don't really support anything else.

There is a large subset of what RLL tools do that is common to all, but yes, I agree that they are customized to the particular features of a given PLC. For example, some have you peek and poke registers to enable features and even call routines. Maybe those sorts of things can be abstracted into a personality module for the brand or model. That might end up being larger than the common module. The PLC tools that do that sort of thing aren't very good, because they seldom show what putting 0x04 in r1031 does, you have to look it up if it isn't your code. Volunteers could deal with the complexity that isn't economical for the companies in give away software. The biggest obstacle would be the amount of RE needed if there is no cooperation. At this stage though, I'm not ready to agree that it's not feasible, although it may not be. After all, it wasn't feasible that I would be writing this on a free *nix with free tools and that it would be displacing the works of ATT etal. What I want is ideas on how it could be done. Pick one of the fairly generic tools for the Japanese PLC manufacturers. It could look like that. My idea for solving the problem is to provide something that the PLC manufacturers might want to do. Because, like rope, we can't push them into anything.

Regards
cww
 
B
Hi Curt,

The trouble with the "pull" principle is that the thing on the end of the rope has to go where you go - which means you are setting the standard for everybody else.

The hardest part of any software project especially those involving PLCs and industrial stuff, is that someone has to decide what the end task is going to be - in other words, write functional specifications and the like. Once this is done, they can be turned into any number of different code formats relatively easily. This has to be done in cooperation with and acceptance by those who will have to run the show and those who have developed it (and created most of the problems we need to solve). Inter discipline communication, understanding and acceptance is an essential part of the process.

I like the FBD and SFC tools available in IEC61131 as they are in fact very useful as part of the process of defining what the end system has to do. I can sit down with aggressively non-computer-literate operating people and ask what the required start-up sequence is. Because of the rules of SFC it is very hard to get into a mess - and a bit of thought to the development process can help this further. If there is a complex combinational logic element to the requirements, these can be written and agreed on in FBD form. In the industries I have worked with, PLC programs were documented in an ISA or similar function block format anyway, so even if ladder was the development tool of choice, at some stage function block diagrams would need to be produced.

Since both FBD and SFC formats are relatively easy to turn into a program, why make it a requirement to convert to ladder? This is just another stage where things can get screwed up.

The other aspect I think is essential in any program targeting industrial controls is that the programming language must be bullet-proof. There are enough well-documented issues and problems that have arisen through failings due to the non-existent protection of C that I for one am not happy with the idea of letting a greenhorn programmer with little or no process experience loose on any automation project - let alone one where there could be safety issues.

Bruce
 
In reply to KEJR: You have four main choices for GUI development in Python, and all four are platform independent. They however have various pros and cons.


1) TkInter
==========

Standard Python distributions come with something called TkInter (or often just Tk).

Pros:
a) Comes with Python.
b) Easy to program.
c) Good documentation.

Cons:
a) The older versions do not look as appealing as some other GUI toolkits. The newest version (Themed Tk, or ttk) changes that, but is not in general use yet.
b) There is no GUI builder that I know of. On the other hand, it is very easy to create GUIs with it programmatically, and I find I can cut and paste text much faster than I can drag and drop widgets. I will elaborate on this further.


2) Gtk
======

Py-Gtk is very widely used for Linux programs. Gtk is the GUI toolkit used for Gnome, which is the most common desktop for Linux (and also used with BSD, Solaris, and a lot of other Unix or unix-like operating systems). It is also used in some embedded applications.

Pros:
a) Gtk is already installed on many Linux systems.
b) I like the looks of it better than any other GUI toolkit on any OS.
c) There is a GUI builder called Glade. That is the "standard" GUI builder for Gnome systems. I believe there is also a version of Glade for MS Windows.
d) It is also quite easy to use programmatically. A lot of the concepts are similar to those in TkInter.

Cons:
a) Installation used to be a bit of a pain on MS Windows because you had to collect the various packages and install them separately. That is supposed to be much easier now with an all in one installer, but I haven't tried a new one so I can't comment on it.


3) QT
=====

You may have already heard of QT. It is a very popular cross-platform GUI toolkit. It is the toolkit used for KDE, which is the second most popular Linux desktop (and is also used on other unix-style operating systems). It is also used in a lot of commercial software for MS Windows. A lot of software companies prefer it over Microsoft's own GUI toolkit, even where there is no requirement for being cross-platform. It is also used in a lot of embedded applications.

I won't do a pros and cons list for it as I am not as familiar with it. It does have a GUI builder (QT Designer, I believe). The Python binding for it is called Py-QT. There is also a new one called PySide which is meant to eventually replace Py-QT.


4) wxWidgets
============

wxWidgets (formerly known as wxWindows) is a cross platform GUI toolkit. The Python binding for this is wx-Python.

Pros:
a) This is intended to give a "native" look and feel for each platform.
b) There is a GUI builder called "wx-Glade" (This is closely modelled on Glade, but it is actually a different program).
c) This is a fairly widely used cross-platform toolkit.

Cons:
a) You can customise the appearance, but the default widget set looks like the traditional MS Windows XP type widgets. I call this a "con" because I happen to think the standard MS Windows GUI looks rather unattractive. That's a personal preference however. If you happen to like the way MS Windows looks, then you might rate this as a "pro".


5) Use a Web Interface
======================

This isn't a traditional answer to this question, but it is a possibility to keep in mind. There can be a lot of technical advantages to it in automation type applications. I won't spend any further time discussing it though unless you are interested.


Summary:
========

If you want to put something together quickly and you don't insist on a GUI builder, then TkInter has a lot of advantages. I've used it to create GUI systems for factory applications, and it does the job. When you are creating applications where you are using big buttons and output characters, then minor detail artistic considerations can be not very relevant.

Absolutely the best book I have seen for GUI programming for any programming language is "Python and TkInter Programming" by John E Grayson. As well as being very well written, the author's background is writing software to control equipment. His examples are therefor a lot easier to relate to than the sort of typical business oriented data entry applications we see in most books. It's a good book regardless of what GUI toolkit you use.

If you are looking for something else other than TkInter, then your next choice would probably be wxWidgets, simply for ease of installation on MS Windows (installing any of these on Linux is easy).

I've called these "GUI toolkits", but except for TkInter, all of them (Gtk, QT, wxWidgets) do a lot more than just GUIs. However, Python is very much a "batteries included" language, so you probably wouldn't use their non-GUI features very much.

I've mentioned the GUI builders. Some people like GUI builders, and some people don't. I have found that they can be very nice for doing a mock-up of what a screen will look like, but I like to do the real thing using function calls. Because of the nature of Python, it takes a fraction of the code to create a GUI as compared to a language like C or C++. I can copy/paste a couple of function calls and change the parameters in a text editor a lot faster than I can click on options and type into boxes.

Also, people often form their opinions on this based on their experience with a Win32 style GUI. The traditional Windows GUI API is positively painful to program for because it is so primitive. The GUI toolkits that I have listed above are based on more advanced concepts where much of the design and positioning considerations are taken care of automatically. You just give a container object the "packing" parameters that you want to use to say "arrange this bunch of things side by side along here and don't bother me about the details". You can position the widgets on a pixel by pixel basis if you want to, but it is very rare for anyone to do things that way. If you like GUI builders though, then they are there and they are meant to work with all the popular programming languages (they aren't language specific).

If you want an IDE for Python, there are a number of those available as well. I can't offer an opinion on any of them because I prefer to just use a text editor. I've tried a few and always went back to using a straight editor. You don't need make files or build parameters for Python. Just run the program; Python will figure out whatever it needs to do to run it. Lots of editors understand Python syntax and do the appropriate highlighting (or whatever). That doesn't leave much for an IDE to do, so I think most people can't be bothered to use one. Python comes with something called IDLE, but that isn't really suitable for anything beyond student projects, so I wouldn't spend any time on it.

As far as Python itself is concerned, it comes already installed on a lot of Linux distros. I have metioned "Linux and MS Windows" above, but that should really be "Linux and MS Windows, and Mac, and a lot of other platforms". I have been very surprised recently to see how many businesses are using Macs in their offices lately, although I've never actually seen one on the factory floor.

Python has been around for a long time, longer than Java even. At the moment it is going through a phased transition between the 2.x series and the 3.x series. Version 3.0 did things like dump old deprecated features that no-one used anymore, fixed up details in handling of unicode strings, re-organised parts of the standard library, and various other long standing housekeeping matters. However, the 2.x series is still being developed in parallel with the 3.x series, while gradually adopting the new features where possible. The idea is the two series will eventually merge together and everyone will simply jump over to 3.x.

However, many third party libraries are still 2.x compatible because their user base is still using 2.x. The standard Python installations in Linux distros still haven't made the jump to 3.x. What that means is that if you are looking at maximum compatibility with what is installed today *and* you want to use the default Python install, then you should probably be looking at 2.6. If you want to support Debian Stable, then you need to worry about 2.5 for the next little while (Debian Stable has a long support life, and has been around for a while).

Most of this isn't a big deal. You just have to watch out what wizzy new features you use and which library you import them from. The biggest thing is to remember to use print("Hello world") instead of print "Hello world". The first will work on 2.x and 3.x, but the second won't work on 3.x. Changing print from a statement to a function was by far the most controversial change, so that shows the differences are generally not a big deal.

There are multiple implementations of the language from multiple parties. The canonical one is the one from www.python.org, and is generally called "CPython" to distinguish it from the others. There are at least 9 or 10 other implementations, including ones backed by large companies such as Sun/Oracle, Google, and Microsoft. Unless you have some very special requirements however, I wouldn't bother with any other than CPython from python.org as none of the others seem to meet up with the quality or completeness of the original.

If you have any questions about Python, feel free to ask me. I think it's an excellent language for a lot of typical automation applications where you need to develop a program quickly.
 
In reply to Curt Wuollet: When I say that an editor has to be PLC specific, what I mean is that it has to understand the syntax and parameters of the language and data table for that PLC.

1) What instructions are there?

2) How many parameters does each instruction take?

3) How do you start a rung? With some PLCs you start a rung with an AND or an OR. With others you need to do a logic STORE.

4) Are word operations accumulator based, register to register, or both?

5) How do you do math operations? Are they of the style "load, operate, store", or will it accept complex equations?

6) Do timers and counters count up, or count down?

7) Do errors fault the processor, or do they just set error flags which the user has to check?

8) Are boolean addresses just arrays of bits, or are they just bits packed in bytes?

I could go on and on, but I think you should get the idea. You can find different "IEC 61131-3 compliant" PLCs that take different approaches to these questions, sometimes in different models from the came company!

What might be feasible is to pick *one* PLC and write an editor for it. If you are careful when you write the program you can add support for a second PLC some time later without having to rewrite the whole thing. What you can't do is to create an editor that supports all PLCs from day one. That just isn't a feasible way to work.

So, what you want to do is to pick a PLC that you think you are interested in *and* that looks fairly simple, and write an editor for that. As for cooperation from the vendor, I would say forget that. They aren't going to take you seriously until you have something that works.

What is more, I seriously doubt that any of the vendors have the sort of design documentation that you think they do. What they probably have is a collection of e-mails where the engineers sent messages back and forth between each other asking "how does this work?"

If you are trying to write programming software for a PLC, then I think that starting with the editor is starting from the wrong end. The first thing you would need to do is figure out what gets sent to the PLC when you download a program.

Older PLCs (like the Siemens S5) just needed to have a set of byte codes representing the instructions downloaded. I suspect however that for most modern PLCs the process works a lot like Beremiz/MAT does. It compiles a program (to machine code in some cases), links it to a bunch of libraries and then sends the complete combination to run on the hardware. If that's the case, then what are you going to do? Write your own support libraries? You probably can't redistribute theirs.

Once you can create your own program, download it, and get it to run, then you might think about an editor for it. I suspect though that working with closed embedded hardware like that is a lot harder than you think.

I think the steps would have to be more or less like this:

1) Identify some likely target PLCs for further study. These need be ones that are going to remain on the market for a good while yet so they don't become obsolete before you are even finished.

2) Figure out if it is feasible to reverse engineer any of them. Ones that can use hand held programmers (if there are any such things still around) are the most likely candidates. You would be looking for PLCs that just interpret downloaded byte codes, or at least PLCs where the compiler is in the PLC rather than in the programming software.

3) Buy some hardware and the OEM programming software.

4) Capture some download message samples between the OEMs programming software and the PLC, and figure out the download protocol.

5) Figure out the instruction set by downloading small programs and seeing what changes each time.

6) Re-evaluate whether the whole thing is feasible. Would you have to create your own hardware support libraries (firmware)?

7) Get to the point where you can take a text file with IL instructions and then compile (or tokenize) it, download it to the PLC and get it to run as expected.

8) Congratulations! You are now at the point where you can even think about writing an actual ladder editor!

Alternatively, you could forget about trying to actually replace the whole programming package and just try to replace the editing process while still keeping the OEM's software for downloading and debugging on the actual hardware. In this case you are just replacing the software you use while sitting at your desk and creating new programs. The objective here would be to let a company get by with fewer copies of the OEM software. The process here would be:

1) Pick a PLC that is popular but for which the software is *really* expensive. It's hard to beat AB or Siemens when it comes things like that.

2) Get a copy of their software.

3) Reverse engineer the file format. That means writing different small programs and seeing what changes each time. Make small changes to the file and see what errors you get. If the software has a text mode import/export feature, then you can skip this step.

4) Make a big spreadsheet listing the instruction set along with all the information about each instruction. If the PLC doesn't have a documented IL syntax, then you'll have to create your own IL based on the ladder. (This is a necessary step in order to be able to work with the instructions).

5) Create your own PLC program files and see if the OEM software can read them.

6) Now you can start writing a ladder editor.

However, I think you'll find that in order to have a workable ladder editor you will need to create software that has about 75% of the functionality of a complete soft logic execution system (that's excluding things like management and monitoring). That's because in order for the editor to be able to understand the program (so it can tell the user what he did wrong) it has to analyse the syntax and structure of the program to the same degree as a PLC compiler would. You are just leaving out the final steps of outputting executable code.

So, there's a couple of possibilities. I would be happy to be proven wrong on either. However, that is more or less what I think you would be up against.
 
In reply to Bruce Durdle: I'm the one that said that IEC 61131-3 is a monster of a spec. By that I meant that writing a logic system that complies with it in a meaningful way is a huge project. Something like that would take years of effort as opposed to a few months at most for a logic system design that is simpler but still offers most users equivalent functionality.

In saying that I'm not trying to say that IEC 61131-3 is "bad". I am just saying that using that as a model expands the scope of work to such an extent as to be infeasible for a small project that is attempting to get useful short term results. I would not also be surprised to find that this is in fact the reason why so many existing proprietary PLCs are only partially IEC compliant.

SFC (Grafcet) and FBD by the way both precede IEC 61131-3 by a long way. You can support both in a non-IEC PLC quite nicely and indeed both were supported in PLCs long before the IEC versions were ever thought of.

As far as ladder is concerned though, you need to look at market demand. At least 95% (if not more) of the market would be fully satisfied with ladder and nothing else. Most PLC users don't even know what SFC or FBD is. Again, for a small project with limited resources (such as what Curt is contemplating), supporting only ladder (plus IL) is a very reasonable design decision.

I do happen to like SFC (and state diagrams). However, I think the way they are supported in many programming packages is so poor as to be worse than useless. Hand translating SFC (or state diagrams) to ladder is actually pretty easy however provided you write your PLC programs the right way. Grafcet was originally designed as a means of documenting machine sequences. You can do the diagrams using a word processor. Some drawing programs (like Dia) have SFC symbols as well.

Anyone buying new custom made machinery should really include a requirement that SFC and/or state diagrams should be supplied by the vendor and used as part of the design review process. They can then be used as part of the acceptance test procedure to see if the machine works the way it is supposed to. I have found this to be a very effective way of doing things which eliminates most of the argument at delivery. Hand translating Grafcet diagrams to ladder is still a lot better than the "hack away at it until you run out of time" approach which seems to be the alternative.
 
I think a standard programming language is the best solution.

The basis should be C++ classes.
For those who are not capable or willing to code in C++ you can simply generate a language binding with
http://swig.org/

Thus they can do it in Python or PHP for example.
These are languages (especially PHP) which many people can do nowadays.
But the kernel classes would be in C++

The classes would implement "function blocks".
The user would only have to connect input and output to the classes and call a "calculateStep"
in each cycle.
For example see our implementation of a closed loop controller:
http://pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlController.html

Once you have classes for all standard "function blocks" you can build a GUI for graphically connecting these blocks.
First you would define a XML format for the application and generate the sourcecode in C++ from that XML file.

When this is done it is easy to build a "designer" for this.

Thus i would simply forget ladder code.

PS: HMI's are not coded in ladder code

Yours:
http://pvbrowser.org
 
> 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. <

Every ladder logic program can be converted to function block display (but not vice versa). And the conversion is very simple ... IMHO.

> Having said that, C/C++ handles sequential items brilliantly if you have an RTOS to put each sequential task on its own thread. <

To do that we, don't need C/C++ . It depends on the implementation of the target software. It is possible with our tool to run instances of the target software as threads which are scheduled by the RTOS. This allows to wait suspended for events, which avoids senseless polling.

It is also possible to assign such threads to an individual CPU core of a multi-core CPU. So you can run secure the control algorithm on an separate core(s) and the GUI threads on the other(s). Building of instances of composite function blocks is supported ... why should we use C++ ? We use function block display as a general purpose language.

Best Regards
Armin Steinhoff

http://www.steinhoff-automation.com
 
I think I'm somewhat responsible for pulling the C/C++ element into this discussion so I wanted to elaborate on some of my points.

First, there is no reason a common system based on C/C++ can't be used with Ladder, SFC, whatever. There are many projects that have demonstrated a ladder editor producing compiled code to execute on a cyclic target "scan". This scan can be but one thread in a common runtime platform that could include C/C++ threads.

I would also say that I've seen inexperienced programmers produce the most aweful programs I've ever debugged or modified - In ladder. You cannot have a powerful and flexible programming language that is bulletproof for use by some inexperienced, rogue programmer that doesn't understand good program design principles. Ladder and Flowchart are no exception. I've seen Flowcharts that will boggle your mind. I've also used flowcharts on a machine and to do the actual low level programming it is difficult for the layman (lay-person?? ) to understand.

Let me ask this: Why is it that more robot and motion control languages are based on C/Basic like syntax and use a RTOS structure? I personally believe it is because they had a chance to start from the ground up and chose a better language than any of the IEC offerings. I have to clarify language in this context because although Structured Text is a C like language it is often implemented in a scanned PLC loop which limits its behavior to calculations and "ladder" like programming. Also, they picked a language that would help the user keep the system in sequential order. Who would want a robot to jump out of position because of some tricky to debug ladder scan related problem?

There are rules of thumb for high level languages to make them safer to use in automation, just like there are good operating practices to make ladder safer for automation. I would argue that a well written C program tailored for automation is far more human readable than ladder if the programmer believes in making their code readable. I have compassion and respect for people that have english problems and/or reading problems but I don't think it is a compelling argument that should dictate a control system design. This has been debated for years however and I hope I haven't sparked a new thread to debate this age old issue!

I feel that properly written code tells the maintenance people what is failing so that they can fix it. Usually it is a mechanical problem (sticky tooling, bad valve, etc), a sensor that is mis-adjusted, etc. So if the operator or technician can't fix the problem than they are not familiar enough with the machine or they don't have the tools and information to fix the problem. I blame that on the programmer, not the programming tool.

KEJR
 
I think reverse engineering a commercial PLC is perhaps the wrong way to go. In most cases the vendor can always do a firmware change to kick you out.

I've often wondered about redoing the PLC CPU and just reverse engineering their IO bus architecture. This is perhaps easier for those who have logic analyzers available.

The packaging in a PLC is what kills me on any of these ideas. All of the modern ones I know of are proprietary backplanes with proprietary injection molded cases.

KEJR
 
I guess I prefer C/C++ syntax (For OOP I actually like C# better than C++) over something like Structured text which is more cumbersome to read/write. If there were a tool that did the same thing I would not be opposed to it, only ask why make it different?

I'm proposing code to control a machine that is viewed at the top level in a text editor, at least as an option. Is there an option with your system to write threads in native text? I don't want to program in a graphical language anymore, it takes too long and is more difficult to read. I think the process industry and some other applications are in somewhat of a different boat.

~KEJR
 
> I guess I prefer C/C++ syntax (For OOP I actually like C# better than C++) over something like Structured text which is more cumbersome to read/write. If there were a tool that did the same thing I would not be opposed to it, only ask why make it different? <

Just one question: why are in field graphical tools for representing control algorithm by schemes of finite automatas?

IMHO, it is often the only way to specify and understand these algorithms ... but the C/C++ code generated out of these representations are completely not understandable :)

So I don't believe C/C++ are very efficient for the representation of control applications ....

Best Regards
Armin Steinhoff

 
C
Hi Russ

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

That is, more or less, what I am trying to do. If the front end is appealing enough, we have a huge advantage over a single individual or team handling the complexity. The GE fans could do the GE back end, the modicon fans could do that back end, etc. That's the new paradigm and it makes the task much less daunting.

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

That is what leads me to this approach. I want to make using Linux tools just what you expect when using the manufacturers tools and not a computer science project. I've already been down that road and, in order to change what we do every day, it has to work with existing hardware. Of course, it would be relatively simple to also have it work for a Linux PLC. Simpler in fact, since you would own the code.

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

I've found electricians like ladder, computer people might like flow chart or even ST or IL. There is absolutely no reason why other front ends could not be written to use the back ends, if the design and interface level is correct. That is, if equivalent programs would produce the same object code or structure. The dynamic interaction expected with the PLCs would make this interesting, but it's not far removed from HMI prectice. Online editing requires quite a bit of carnal knowledge, hard to RE, but maybe there would be some cooperation. Ladder would be a good first priority.

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

Exactly!, that's what plagues all the Linux PLC projects as well as even the long standing "soft plcs". That's why I would endeavor to make the change as minor as possible. Just delete the Windows and shrinkwrap issues, dongles, key disks, planned obsolescence, churn and having to own $15,000 worth of packages, versions and gadgets to support a plant. I think that is a worthwhile goal, but buy in is, as you say critical.

The power of the idea is that it's the way things should be. Some folks here think I'm crazy, but what I find crazy is the Cartesian product of N operating systems with N versions and N service packs and N versions of N software packages, most or all incompatible, immutable, unfixable, indifferently supported and all with strictly one sided licensing that assumes I'm a crook.

Tell me _that's_ not crazy. And it's extremely expensive too. And you have to maintain it and keep it all quickly accessible. Quick, tell me what I need to troubleshoot the Frombulator that we last worked on five years ago :^) Oh, and downtime is $30,000/hr. Very few industries work this and we shouldn't either.

Regards
cww
 
C
I don't think you are getting what I'm doing. From the users perspective, it's a ladder editor, they neither have to know or care what the tool is coded in. That's the developers issue. It's a safe bet that both the current tools and the PLCs have been created with C or C++ in the mix, but they're not talking. So it's kind of a straw man. And the only group with enough pull on the rope to move the industry are the readers here and their peers.

Here's what I want: You boot up your PC and click on the ladder editor and work like you always have. Only the PC is running Linux and the editor works for all your PLCs. And it's free. Wouldn't that be a good thing?

Regards
cww
 
C
Hi Michael
We would need the usual boxes and dialogs, etc. But which one would be easiest to create drag and drop contacts, function boxes, coils, and rung gadgets, in ? Would these be widgets or blobs dropped on a canvas or ? Please remember that I don't DUI GUI :^).

I'm counting on this being a somewhat rude introduction to the subject since I seem to have some time to learn. For me, it's a lot easier to learn something when you have a need, and a deadline :^). I learned C because I had to write some UNIX networking code. _That_ was a rude introduction :^).

Regards
cww
 
C
Hi Michael

Yes, that sounds like the drill.

I was thinking along the lines of: Can we define a struct or table or ? that can completely define the functions of several PLC's ? It would include register maps, data formats, bits for if counters go up or down, etc. Is that possible? Can we do the commonality that way and handle diverse functions with token replacement? In other words, we are parsing rungs and we know what to pop in for a NC or NO or the various branches possible. For boxes we read the symbol and replace with a function possibly modified by the state of the above mentioned table. These function/tokens would be published by the backend to suit the individual PLC and scanned by the front end so as to provide the right boxes. The back ends would vary from difficult to really difficult as you would have to RE from the comms in the absence of documentation. And yes, the PLC makers would be less than thrilled, they might even be able to convince a judge that this is a DMCA violation. I have no money or substantial assets, so my guess would be they could make you quit at best. But, back to the point of interface between the front end and back end, I have to think through how that might be done generically enough. A good first target might be the bricks, especially the least sophisticated. It will probably require people smarter than I am, embedded types maybe.

Regards
cww
 
W

William Sturm

cww said: "Only the PC is running Linux and the editor works for all your PLCs"

I agree with some of the previous comments, I just don't see how it would be possible without a major reverse engineering project for each brand/model of PLC. The programming protocols and bytecode and/or machine code is virtually never published. That and you would end of with a major subset that might be common to most PLC's. It is a cool idea on paper, but not very practical. It would be much easier if all PLC's used ASCII programming protocols and interpreted ladder code.

Having said all that, some companies used to do exactly what you are suggesting. Teledenken, ICOM, Event Technologies, Taylor, and many others used to do this in the 80's and early 90's. I wonder what has changed?

Bill Sturm
 
B
Back in the days of the Modicon 484/584, the programming manual (I think) came with a detailed description of how the program actually appeared in memory - at least superficially. I used this information on several occasions to find mismatches between PLCs - find the mismatched bytes, and I knew what I was looking for. You couldn't tell the network number so had to find the specific element.
The basic format was a byte for the function, including non-functions such as new network, new column, vertical short, horizontal short, followed by bytes for addresses where relevant. It would be **possible** to implement some sort of software to recreate that, given the basic information, but it would have been quite a job to reverse engineer it just given a string of stuff from the PLC memory. Add in the overheads for communications etc and it's quite a task.

Bruce
 
In reply to Ken E.: If you aren't going to use the PLC OEM's complete system, then there is no reason to use their rack.

1) For a CPU, use an off the shelf single board 32 bit computer. There are lots of these with Atom, ARM or MIPS CPUs, and the prices are very good. There is some newer hardware out that is the size and shape of a small wall transformer and comes with Ethernet and has a target price of $50 to $100. People are also re-programming routers for special purposes (some of the major router vendors produce special versions to accommodate this market). If you want a bit more CPU power, then use one of the small Atom PC boards. There are lots of fanless and diskless options available off the shelf.

2) For an embedded OS, use Linux. Any of the hardware that I have mentioned in the previous point will come with it as standard. If you really want an RTOS, then use an RT version. When you look at the cost, hardware support capabilities, and availability of additional software (compilers, web servers, databases, etc.), then it is ridiculous to use anything else.

3) For I/O use Ethernet networked I/O using an open protocol. That can include rack style remote I/O. There is lots of choice there. There is no reason to try to reverse a PLC vendor's proprietary protocol for this.

4) For operator HMI panels, use a panel PC and a web based HMI.

The hard nut to crack in all this has been the programming and runtime software, not the hardware. As we have said though, this is already solved or close to solved, depending on what you want out of it.
 
In reply to Curt Wuollet:
>I was thinking along the lines of: Can
>we define a struct or table or ? that
>can completely define the functions of
>several PLC's ?

Doing that for *one* PLC is a lot of work. What I would suggest to start is to pick *one* PLC that you think you would like to work with. Set up a spreadsheet with a row for each instruction and with a column for each piece of information about that instruction.

The number and format of the columns will only make sense within the context of your implementation, so I can't say what each column would be, except that there will likely be several dozen of them (you will find yourself adding columns as you go along). You will have to do this even if you just want to support *one* PLC.

Now you've got something to track the characteristics of each instruction. You can if you wish repeat the process for another PLC and then try to map the instructions from one table onto the other. What you will find is that for a lot of instructions there just isn't a one to one correspondence between the two PLCs.

At best what you could do is come up with some sort of lowest common denominator of features between them and restrict your editor to that. A lot of potential users wouldn't be satisfied with that however. It would also mean that if someone had a program written with the OEM's software, there would be a strong chance that you couldn't read it with your software because it would be using those unsupported features.

I'll put it another way. With all their resources, not even Siemens and AB have been able to write software that would reliably port PLC programs between different generations of their own hardware. The best they have been able to do is an 80% - 85% success rate.

If IEC 61131-3 really meant anything, then you could just write an IEC 61131-3 editor and have it cover everything. Instead, what you are talking about is more like writing a single compiler that will compile C, Perl, Forth, Fortran, and HTML all in one program.

Now there are syntax oriented programming editors that *can* do that. But they have the big advantage that all they have to deal with is text. And even with that advantage, they basically have to deal with each language as a separate syntax tree.

So, if I was going to try to do this (which I'm not), I would try to do this for *one* PLC first while taking care to keep the model specific code isolated from the generic support code. After I had it working for *one* PLC, I would rewrite it to support a second PLC. The advantage that I would have at that point is that I would have a much better idea of what I was doing.

When I started working on MBLogic I had certain specific design ideas in mind. What I ended up with was radically different from those original design concepts. The goals remained the same, but the implementation changed as I came to understand the problem better. I have also gotten feed back from people using the software and found myself changing emphasis and priorities based on that.

I think what you need to do is to avoid getting too fixated on the grand overview and instead setting a few short term goals. This is starting to overlap with another post you made that I am going to reply to, so I will leave this post at that.
 
Top