I am hoping to pick brains here and survey how far we have come and how much is known by the group as a whole.
As the old timers know. I want very much to use Linux in automation. Indeed I have used it in many unusual ways, to integrate robots and CNC and conveyors and even a Linux based automation system project and a tiny but workable Linux PLC program (more my style). Not bad for a old C hack, I suppose.
What's been banging around in my head for a little while now, is how to use Linux with PLCs in the _usual_ way. I'm assuming many of the wonderful new generation of tiny, fanless, powerful, all in one embedded processor boards could be morphed into a PLC.
We are all familiar with today's PLC tools, good and bad. Some of these come from vast corporations and often that shows. Some have no doubt been kinda shoestring efforts and often that shows. All have been based on Windows or DOS before that. As the old timers also know, I'm not a GUI guy. But, practically everyone younger, (and some older) is. So, rather than pore through the thousands of possible ways and then do things my way :^). I thought I'd get the consensus of the people who are involved in automation and are of the GUI world, on the best tools and practices to develop a new Generic PLC Ladder Editor using the best FOSS tools available. In order to be taken seriously, this would have to be a GUI tool. I've looked at Glade and Kdevelop, etc. Some say, Python, some TCL and friends. What would be the best RAD tool for ladder?
Output would be some sort of table that could be fed to a code generator for download to a PLC. I've looked at Glade and Kdevelop, etc. I don't know if I'll have the time to code it, but it's beginning to look that way :^). Or for that matter, as long as it happens, I don't even need to be involved.
If such a thing existed, it might well induce someone with the money to do the whole thing to do the right thing.
Have a look at Beremiz (www.beremiz.org). It's an IEC 61131-3 software system that does ladder, IL, FBD, SFC, and ST. The actual logic execution system is the MAT PLC (which you were once involved with).
One of the companies working on it will be shipping it as part of a commercial product some time this spring where it will replace their previous controller product line. The hardware will support CanOpen and Ethernet. The link to the product announcement is on the front page of the Beremiz web site. It's a "PLC" in that it is hardware that you would mount in a panel just like a regular PLC. Underneath though it is basically what you are talking about.
The Beremiz editor is written in Python with wxWidgets. It runs on Linux or MS Windows (one of the demo videos shows it running on Ubuntu). There is an HMI, but I don't know if that is being shipped with the hardware product mentioned above (there is more than one company involved in the Beremiz project).
The HMI system is SVG based and uses a lot of similar principles to what I have been working on (even including using Inkscape as an editor). I have been talking to one of the Beremiz developers about what we can cooperate on with regards to HMI features and he is interested in having more contributors to any part of Beremiz. You might want to contact him and see what you can do to help them.
The PLC vendor is a smaller company in Europe. You might want to get involved with Beremiz and then talk to some small companies in the US who might take a similar interest in it. There could be some interesting opportunities there for all concerned.
I haven't used Beremiz so I can't give a real opinion of it. If you are looking for a proprietary system to compare it to (in terms of what it does) however, I think it comes closest to Codesys which quite a few smaller PLC vendors license to embed in their own hardware. I think the market for it would be small hardware vendors that don't want to deal with Codesys, or who want more control over product development but don't want to create a complete system on their own.
I have my own MBLogic project that I'm working on. It's not really a traditional "PLC" though. It's more about system integration and taking advantage of the web in a PC based soft logic system. I am planning on starting to work a ladder editor within the next few months (it's strictly IL editing so far), after I have the current HMI improvements complete. My tentative plans are for it to be a web based AJAX type application, with the work being split between the browser and the server. It's an open project, so anyone is welcome to work on it.
If you are looking at doing a traditional "fat client" for a "PLC" however, then you would be hard pressed to find a better way of doing it than Python plus GTK or wxWidgets (which is what Beremiz uses).
As one of the more ambitious authors of Linux software in automation, I am glad to see you chiming in. There are, no doubt, many others who do things with Linux, but not to the point of complete systems. I do think whole systems are one of the best ways to take advantage of the power of Linux because the facilities are there to do the whole ball of wax under one roof. And this is a trend in the industry, to address the whole picture synergistically and do more per box.
My problem is one of scope. I think one reason that MAT ran out of gas was that the scope kept expanding. It certainly got beyond my modest talent and memory capacity fairly quickly. That wasn't necessarily a bad thing :^) as it does go on even though I have no inkling of what they are doing. I'm not even sure that I'm smart enough to run what it has become :^).
Meanwhile, back in the trenches, to automate something, lots of folks buy a PLC, fire up the programming software for that particular beast and have at it. Most of this is still, thinking in logic, building rungs, test, rinse and repeat. Indeed, when I am doing automation, the majority of what I am asked to do are the small projects, using a lot of bricks and a PC. I would like for that to be a Linux PC. Yes, it may lead to scada, HMIs, DCS, MIS, and the rest of the alphabet soup, but nothing I've seen really aims at the part that a lot of us spend most of the time looking at. Some of the programming tools take a whole CD or more. But some of them fit on a floppy, that, I could actually see completing before I run out of money and become homeless or retire, depending on the economy.
Some programming tools sell for thousands of dollars, some are free already. The folks who want thousands of dollars seem to be quite incorrigible, only the market can change that and they will go down fighting. What I would like to come up with is for those who see it as necessary to sell PLCs and not a profit center. IF they had a decent package they can adapt to their PLC at little cost, perhaps the fact that it runs on Linux would be palatable and I can cause that first to happen. After that, World Domination :^).
What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target. It would be something all of us can use, just like the stuff that comes with the PLC. The question is, how best to do it?
CWW Said : "What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target."
Isn't that what the IEC 61131 folks have been pushing for for years? You would probably find PLC editing software or libraries that will work with Linux. The missing link, IMO, is hardware.
An "open source" PLC hardware platform would be very beneficial. Maybe a home brewed microcontroller board with local or remote I/O. It needs to be something that can be made and serviced by virtually anyone. An open micro, such as an ARM or even an 8051 would be nice too. Maybe ARM for larger systems and 8051 for brick systems?
Does this help, or have I strayed too far from your original topic?
In reply to Bill Sturm: The hardware exists, provided you don't want a shoe box format. Linux is by far the most popular OEM OS on 32 bit embedded hardware (which is what a typical PLC would use these days). For I/O however, you will need to use networked I/O via Ethernet (e.g. Modbus/TCP) or CanOpen.
>> CWW Said : "What is needed is a module that does the things common to PLC programming packages and outputs a machine independent format that can then be compiled, converted, or interpreted into code for the target." <<
> Isn't that what the IEC 61131 folks have been pushing for for years? You would probably find PLC editing software or libraries that will work with Linux. The missing link, IMO, is hardware. <
IMHO ... the missing links is not the hardware. To find an appropriate hardware is a minor issue. What you need is software which handles the program upload and execution of it. And this execution environment (software) should be easy portable.
The use of ladder logic is simply a step back and would introduce unnecessary additional restrictions. With ladder logic you can only express a small subset of possible control algorithm. Function block display allows the representation of all control algorithm.
BTW ... we have completed our port of DACHSview-SDL to Linux and Real-Time Linux. With the usage of function blocks we can provide a development environment for the development of animated graphical 2D/3D real-time applications and control applications running secure on an and the same multi-core CPU e.g. Individual control threads can be assigned to individual cores of the CPU.
Would this be possible with ladder logic?
If someone is interested, a full working evaluation system (windows based workbench / Linux target, tested on openSUSE 11.2) is available on request.
as [at] steinhoff-automation [dot] com
I agree with most of your points. I do think that particular hardware needs to be tested and qualified to work especially when you are talking about fast communication cycles over Modbus TCP. Some devices can't handle anything faster than 5ms update.
I do somewhat disagree with your point regarding function block diagram lanaguage. This seems useful when you have a continuous control algorithm like PID or the like, but I find it cumbersome for complex sequential discrete control. Having said that, C/C++ handles sequential items brilliantly if you have an RTOS to put each sequential task on its own thread.
> 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.
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.
> 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 ....
In reply to M. Griffin regarding embedded hardware:
I always thought it would be cool to use a PLC rack with a custom Linux RTOS CPU for the form factor, wiring, etc. Besides the cool factor there is one instance where it is practical, however, and that is when data needs to be sampled in the sub-millisecond levels. More specifically I would guess that polling at anythign faster than 100 microseconds is sketchy even with isolated ethernet UDP transfers. I would love the opportunity to purchase a "slice IO" unit and do this kind of testing with Modbus UDP and Linux RTOS but so far I don't know of anyone who has done this specifically.
I do agree with you 100% though in that some embedded fanless "Box" computer with multiple ethernet ports *is* the way to go. Any open source effort probably should be in this direction as it is the most economical/flexible and should be the most supported in the future.
I will say that the HMI Panel PC could (should??) be the entire controller, or to use a VGA touch panel driven by the embedded box using shared memory to the RTOS threads.
In reply to Ken E: Typical PLC rack style hardware isn't up to sub-millisecond scan rates. The physical inputs and outputs are too slow, and the backplane is usually a bottleneck. On at least some popular PLCs (I have only researched this for a few) the backplane is actually much slower than the CPU network connection.
You also usually see that high speed I/O on a PLC is normally either limited to the I/O directly integrated into the CPU, or in a special high-speed card that has it's own CPU and program (or sometimes an FPGA). There is some fairly fast industrial digital I/O. However it all seems to be Ethernet based, not PLC rack based.
Advantech does have a "data acquisition rack" which looks like a PLC. They do have PLC-like CPUs that you can load your own software on. However, while the I/O capabilities are better than a normal PLC, it is barely into the range that you are talking about.
Once you start dealing with kHz data acquisition rates then you are out of the range of ordinary PLC hardware and into PC territory. You would want a data acquisition board, or else you would want to look at PC/104 hardware. It's not just the speed. It's also the signal conditioning and channel to channel skew. Data acquisition on a PC is usually done directly in hardware.
PLC applications can usually get away with ignoring a lot of problems simply because everything happens so slowly. At higher speeds though, the real world starts to intrude more and these issues can't be ignored. Just cranking the speeds up on conventional PLC I/O designs isn't going to work. The signal conditioning and wiring have to be just right and that's outside the experience of most PLC users.
As for TCP versus UDP speeds, well I recently tested a UDP based protocol that used similar principles to Modbus/TCP. Running on the same hardware (PC based), and transferring the same amount of data, Modbus/TCP was 4 or 5 times faster (average throughput) than the UDP based protocol.
Now, you can say that the difference is due to implementation details and that is probably true. However, that is also the point. UDP isn't a magic bullet and TCP can be pretty fast. The speed of networked I/O is going to depend more on the details of the hardware and software design than on whether it uses TCP or UDP.
In reply to Armin Steinhoff:
Do you have examples/screenshots of function block code running a detailed sequence?
> Do you have examples/screenshots of function block code running a detailed sequence? <
Yes, please have a look to http://www.steinhoff-automation.com/img/ButtonCtrl02.jpg
It's just a simple light ON/OFF example :)
In response to Armin Steinhoff:
I just don't see that type of SFC programming being easier to write than text programming using a system such as I described earlier. I've done it both ways and am at least 5 times faster with a structured programming language and RTOS. Maybe we'll just have to say it's a matter of preference.
In reply to M. Griffin:
I'm not talking about typical PLC racks I suppose. Currently I use a lot of Mitsubishi Q series backplanes with their higher speed input cards. They are not co-processor cards or interrupt cards, but simply Input cards that have a settable digital filter that goes as fast as 100 microseconds on the hardware filter. My typical scan speeds are on the order of 600-700 microseconds (which includes rack IO reading), so we are getting real savings out of the faster inputs. I use this as a default and have not had any problems. Proper 24V signal thresholds and decently conceived wire runs help you out a lot here because the noise amplitude that you can get away with.
Like I mentioned before, I do agree with you that standard Linux box with commercial (or public domain) field IO is probably the way to go. I'll keep an open mind to test with Modbus/TCP if the opportunity arises.
In response to Graphical vs. C/C++ text editing:
I think we are describing two different types of control. I mostly deal with sequential assembly automation, so in that sense my comments stem from that field. Most of the operations I deal with are either pneumatic cylinders with discrete on/off valves (with feedback) and triggering (and waiting on) motion control events (which are executed by a high end motion controller). Currently I use a lot of Ladder based sequencing (Mitsubishi Q series PLC), "C-like" programming (Epson robots), but have also dealt with SFC, Flowchart, and Delta Tau proprietary motion languages in the past. I think SFC and flowchart take up too much screen space and really is useless for detailed low level control. Most of the editors I've used hide all of the detail and only display a comment which makes it hard to tell what the underlying code is doing unless you click on every block, or spend most of your time maintaining comments.
- Quick to do some latching and simple combinatorial logic.
- Can be made re-usable somewhat by using Function block calls.
- To do sequential operations you have to force sequencing with "step numbers" or set/reset of next rung.
- Inserting items into a sequence often involves renumbering your sequence.
There are some tricks to making this all work out, and it is useable, but in the end it is just too overly complex to sequence things in ladder when in an RTOS/C/C++ environment a thread executes code sequentially *by default*. The ability to describe a sub-sequence in a function call (or object method if you wish) can really help you "divide and conquer".
For the text based RTOS your actual code can be very similar to this pseudocode:
- Turn on ejector
- Wait for ejector forward
- Trigger motion index
- Turn on loader
- wait for index complete
In addition these pseudocode "steps" when implemented as functions/methods can encapsulate a lot of functionality, such as the motion control trigger / wait including diagnostic code built in, as well as having timeouts and fault generation for waiting on the discrete IO, etc.
> [ clip ]
> For the text based RTOS your actual code can be very similar to this pseudocode:
> - Turn on ejector
> - Wait for ejector forward
> - Trigger motion index
> - Turn on loader
> - wait for index complete
> In addition these pseudocode "steps" when implemented as functions/methods can encapsulate a lot of functionality, such as the motion control trigger / wait including diagnostic code built in, as well as having timeouts and fault generation for waiting on the discrete IO, etc. <
IMHO ... our concepts are not very different. We use more or less the same modular approach, but we do an additional step to encapsulate these function/methods (or APIs) into graphical function blocks. This hides a lot of syntactical problems of textual languages. You can consider our function block display as a graphical abstraction layer supporting transparently threads and multi-core CPUs. Even recursive calls of function block routines are possible...
In reply to Curt Wuollet: I started off by writing a big long reply to address your points directly. The questions to ask yourself are:
A) Who do you see as being your market?
B) What would your project do for them?
If you have a software project that you want other people to use, then you need to have a "market" in mind whether or not you are actually selling anything. So, who would use it, and why would they want to?
> What I would like to come up with is for those
> who see it as necessary to sell PLCs and not a
> profit center. IF they had a decent package
> they can adapt to their PLC at little cost,
> perhaps the fact that it runs on Linux would be
> palatable and I can cause that first to happen
Beremiz/MAT are doing that *now*. Their market is OEMs who want a PLC run time and programming software, but don't want to develop their own. The first vendor is already scheduled to ship hardware based on it.
So, what is it you want to do differently? Is it that you don't like IEC 61131-3? It is a monster of a spec and anything based on it will inherently be big and complex? (That's why I gave up on it and went down a different road).
If you want to so something different though, then what would it look like? Just an editor? If so, then for what PLC? It can't be a "generic" editor that would work with any PLC, because that is either impossible, or impossibly complex to create. The whole point of a PLC editor is for it to know a lot about the PLC the programs is meant for.
So, what would the goals and the focus be?
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.
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.
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 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.
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?
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?
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.
Whem they used OTS components, you could simply dump the ROM and disassemble the contents and you know what they are doing. Many current products use custom or semi custom silicon and the game gets much harder. This is to lower chip count and maybe to make the game harder :^).
> 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? <
Well, the good thing is that such a ladder editor is already there :)
What do you need is the possibility to generate code for a bunch of different target PLCs. And second, you have to communicate to all of these different target PLCs in order to upload the ladder application and to get all data for the debug session.
Do you believe that the PLC vendors would open up their proprietary design of their PLCs for you? I'm not convinced...
> Do you believe that the PLC vendors would open up their proprietary design of their PLCs for you? I'm not convinced... <
No, probably not for me, but if a few important customers got together and wanted an end to the madness, the automation companies would even write it. But, it would still be better for the community to own it. There would be fewer shenanigans that way. And it would be hard for the automation companies to do. At the first sign of a defection, planeloads of MS marketing droids would show up. If that didn't stop it, there would be great difficulty in getting support from Redmond. So, any support from the manufacturers would be "leaks" or very low profile. Or maybe they just wouldn't threaten to sue you into oblivion. Look at Modbus.org, once GS did the right thing, the interest in Modbus increased exponentially. It is certainly far more likely to survive now, than if they had aggressively protected their IP. As I said before, the ones who want thousands for their tools are probably beyond hope. But the ones who give the tools away to sell PLCs are prime candidates for a vendor/community partnership. The companies with a good product and tiny market shares could increase their visibility immensely with very little expense or downside. It has to be a win/win, at least until the idea catches on.
so what we need isn't an editor for ladder logic at first.
We need a *standard* for uploading of code and exchanging of debug
information with a target PLC system. And second, we have to define a target system which is able to execute the code and is able to support debugging.
If you like take the free C compiler "tcc" (http://www.bellard.org/tcc/) which allows compiling on the fly. Build an execution environment for uploading of the C code and for compiling the code with tcc and try to provide the debug information.
The existing editor for ladder logic supports the generation of C code. The remaining issue is the port of tcc to the different target hardware ... sounds easy but is hard to realize.
I think I missed a tick here. What editor are you talking about? As far as the rest, I think we will need to match whatever the target PLC
does to download/upload code and update the dynamic display.
If we used C as the intermediate representation, we would need a converter to load the program from the PLC in whatever format they use and convert it to C. That is a possible approach, but I'm not sure how you would accommodate more than one PLC as the struct sizes, etc. would
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.
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.
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.
I'm not trying to be difficult, but what really is the point to having a free (as in speech) editor for ladder on a simple commercial PLC? As you have mentioned in the past the Click PLC is very inexpensive and has free (as in beer) downloadable software.
If you are thinking of trying to convince automation vendors that a GPL programming package will help their sales I think you are mistaken as to what the market really is for PLC software.
If you want to use a PLC for customers that require it, install windows in a virtual machine and use the free packages from Automation Direct. This really is your easiest path and I think it will be more welcomed by your potential customers. I think it will be a hard sell to tell a customer you are going to use something like an AD PLC but with custom GPL software that relies on reverse engineering. I know I would run away from that one in a second because of the long term support issues.
I do admit that this will not get you around the people wanting Rockwell and having to pay the many thousands of dollars to run their software. This *is* somewhat of a problem, especially for independents and small integration companies.
Am I missing something?
> I'm not trying to be difficult, but what really is the point to having a free (as in speech) editor for ladder on a simple commercial PLC? As you have mentioned in the past the Click PLC is very inexpensive and has free (as in beer) downloadable software. <
No, it's a good question. There are a couple of points. First of all, to get tools running on Linux, which is a far better platform for these tools for a number of reasons. For instance, you could ship the tool installed on a version of Linux and keep that combination indefinitely, Contrast that with trying to support people loading your tool on the last 5 versions and who knows how many service packs with Windows. And having to rewrite every time Redmond needs revenue. Imagine how much easier it would be to support a consistent platform and control when it changes. A community supported tool would take care of itself to a large extent. And an independent, community supported tool is the only way you would _ever_ have a tool that would work across platforms. And Linux is going towards industrial and commercial works at the same time Windows is becoming far more multimedia and entertainment oriented. And getting even larger, with scads of features totally irrelevant to automation that can't be left out. Another reason is that _I_ would rather work with Linux than the mess that I generally get to work with. I would be at least 25% more productive and would need much less costly stuff.
> If you are thinking of trying to convince automation vendors that a GPL programming package will help their sales I think you are mistaken as to what the market really is for PLC software. <
I don't think the sales would change much. Their costs would improve dramatically if they took full advantage of an OS that they can control. They should be acutely aware of this after being dragged through Vista and a few other debacles that really had _no_ upside for them. This is for the big guys that would port their tools. The picture for the smaller outfits that give away their tools would be even better. Why write a tool if you don't have to.
> If you want to use a PLC for customers that require it, install windows in a virtual machine and use the free packages from Automation Direct. This really is your easiest path and I think it will be more welcomed by your potential customers. I think it will be a hard sell to tell a customer you are going to use something like an AD PLC but with custom GPL software that relies on reverse engineering. I know I would run away from that one in a second because of the long term support issues. <
Yes, I could pay more for a copy of Windows than for the whole click setup, for instance, and install it in an environment that will likely decrease it's dubious stability. But that's even harder to support than the current mess. That would be going the wrong direction. That current mess is the problem I'm trying to solve. It costs everyone involved a lot of time and money to chase after a platform that is outside their control and is not at all optimized for automation.
> I do admit that this will not get you around the people wanting Rockwell and having to pay the many thousands of dollars to run their software. This *is* somewhat of a problem, especially for independents and small integration companies. <
Imagine using rockwell without the big bucks and Windows issues, using the same tool you use for everyone else :^)
> Am I missing something? <
I think immersion tends to lull people into thinking that things have to be the way they are. Imagine for a moment how you would want them to be and compare that with what I am proposing. Being involved with computers was once the same sort of mess as automation is now, Action by the users has straightened things out a lot. Left to the manufacturers, it would still be ugly. But they can be winners too, if they try leaning towards the users side of things a little. Some grudgingly embraced the change, the rest are history.
In reply to Curt Wuollet: You said "Imagine using rockwell without the big bucks". Do you know if it is feasible to do this however? Forget about how to edit ladder on the screen for now. The question is do you know how to compile and download a single rung of ladder into a modern AB PLC and get it to run? A simple command line program would be good enough to demonstrate that.
No, I don't know if it's feasible yet. That would require owning or at least borrowing the equipment and software to RE the process. Then there's the difference between possible and feasible. I'm certain it is possible, feasible depends on how bad you want it :^) That is, in my current circumstances, it is not feasible to work on that part. Given the choice between eating and buying automation gear, it's going to be a while before I can start on that. But with the generosity of the FOSS community, I can write and test code for the machine independent part. I might be able to finagle a Click environment, but the ROI on that isn't very high as it's a singleton. Better would be the older AD line. And a brick with a bad output, for example, would be feasible if it can be found. Or for that matter, even a worn Micrologix if they still offer the 10 point demo version of RS Logix. And I'd have to dredge up Windows someplace to run it. But, one of the things I'm trying to assess is the _interest_ in such an undertaking as I would never accomplish it alone. Donations from your pile of dead, but programmable gear will be accepted :^) If I had known....
M. Griffin asked:
> The question is do you know how to compile and download a single rung of ladder into a modern AB PLC and get it to run? <
I know how. I spent some time analyzing the byte codes of a ControlLogix (a fairly complex PLC)
> A simple command line program would be good enough to demonstrate that.<
I can produce it if the ControlLogix become a target of the project. The program would list the bitecodes with symbolic names (contrary to most PLC, the symbol table is stored into the PLC memory)
I must stay anonymous until Rockwell give us permission to reverse engineer their product.
Actually I have begun, but a wise man said "The sooner you start coding, the longer it will take". I am going to need help for sure. But, I have been active. I have looked at the options, and I don't think any of the GUI builders is going to be of much help. I am looking closely at Python because "they" say that you can build a good looking GUI app with less code. I am trying to dispel my biases against interpreted languages, Hungarian notation and OO, and trying to find out how one would do possibly low level serial port programming and the other tasks needed to interpret and translate and fold, spindle and mutilate data where I would be more comfortable with C. Indeed I will probably do a "proof of concept" in C, as has been suggested. I have also asked Automation Direct and Host Engineering if they are interested in helping the project with information. I haven't received any response yet as that was this evening. I propose to look at their DL06 and friends first as this is a sort of generic PLC and can be found used inexpensively. They have a free demo version of their DirectSoft software available. The only machine I have with a Windows license is the one I'm writing this on, so I'll have to see if I can find that hdd and install it and set up a dual boot. While I was on their site, I noticed the click has grown analog ports. But,(sigh) it doubles the price.
In reply to curt wuollet:
> I propose to look at their DL06 and friends first as this is a sort of generic PLC and can be found used inexpensively. <
From a cursory look, that one has good potential for reverse engineering. However, it looks as if the DL series will soon become a "legacy" product, with the Click and Productivity3000 series being the new basis for their product line.
On the other hand, just getting the experience of reverse engineering *any* popular PLC will be worth while. Once you have that working you could then decide if you wanted to re-target the effort to another model.
I think what you would want to start with as a first target is to just be able to:
1) Take a text file of IL and compile it to whatever format the PLC uses,
2) Download it to the PLC.
3) Upload the program from the PLC.
4) Decompile it back to IL.
Those would be four individual command line programs. I would suggest not even thinking about a GUI or ladder, or anything like that until you had those basic functions working. Siemens launched their S7-300 series with not much more than that (although the distributors were absolutely livid over it).
I started off addressing your other points, but quite frankly I don't think they're really relevant at this stage. The upload, download, compile, and decompile capabilities are the targets that should be aimed at first.
As I think about this some more, I have a few other suggestions about an implementation.
As I mentioned in a previous reply, you would want to start with a basic uploader, downloader, compiler, and decompiler. I guess you would want a 'Y' cable so you could listen in on the conversation between the programming software and the PLC. That will let you work on developing an uploader and downloader.
When you get the upload/download protocol worked out, you would probably want to also write a version that acts in place of the PLC. That would let you "download" programs from the programming software to your development PC (Linux PC) and capture them to files without having the PLC plugged in. That should make the next stage (decoding the instructions) easier.
There will be hundreds of instruction combinations to deal with once you take the op code plus address type into account. You will probably want to auto-generate test PLC programs in IL to create these combinations (using Python, Perl, or something like that).
Once you have the upload and download process worked out, and you have captured a complete selection of instruction samples you won't have a lot of use for the original programming software. You will need to haul it out from time to time as you think of new things to test, but at this point you are mainly working from a known set of test data.
The basic boolean logic instructions should be a small proportion of the total work. The bulk of the work will be the word instructions, simply because there are so many of them once you take address combinations into account.
You would also want to keep track of the results for each instruction in a big spreadsheet. The spreadsheet format will depend on what you eventually do with the data, so that is something that will change quite a bit as you design the compiler and decompiler. However, it is really the only practical way to keep track of all the data plus whatever tests you have done. I know the DL205 has over 200 instructions, and I don't think the DL06 is much different in that respect.
What I did for my soft logic system was to export the spreadsheet to a CSV file and then run that through an small AWK program to auto-generate the Python data structure (a big dictionary) which controlled the IL compiler. That way as the program design evolved I could update the data structure automatically. That is a much faster and less error prone way of doing things then updating the code for each instruction by hand. Your spreadsheet columns and data will be totally different from mine, but the principle should be the same.
When you have the instruction format worked out, then you can upload programs directly from your Linux PC to the PLC and test them. What you would need to do is to write a series of PLC programs that test themselves and report the results in the data table. You would then read the data table (probably using Modbus) to verify that the tests are working correctly. I do something similar, although I my case I am testing what the instructions do, rather than testing whether I have the correct instruction. You will want to automate this testing because you will do it over and over again with each new version to make sure that you haven't introduced any new errors.
Another suggestion from my own experience on this is that when you design the IL compiler (to convert IL to the binary format) it will be tempting to do it all in a single stage. However, you may want to break it up into multiple passes so that the different levels of analysis are available to the editor when you get to that point. That is, in one pass you break it up into rungs and subroutines. In another pass you analyse each instruction to see that it is syntactically correct. In another pass you convert it all to the final format (whatever that is). That way you can do things like check to see that if a subroutine call is made, that the subroutine actually exists somewhere, etc. It's not something to get too hung up on, but if you don't take care of it at the start, then be prepared to rewrite it all later (which is what I had to do).
I think at this point the whole project is starting to look a lot more practical. At this point however as I said before, don't worry about how to do a GUI or how to edit ladder. Worry about how to convert from a text file with IL to an executable PLC program and then download it to the PLC. Once you have that done you can sit back and evaluate where the project would go from there.
> As I think about this some more, I have a few other suggestions about an implementation. <
> As I mentioned in a previous reply, you would want to start with a basic uploader, downloader, compiler, and decompiler. I guess you would want a 'Y' cable so you could listen in on the conversation between the programming software and the PLC. That will let you work on developing an uploader and downloader. <
Yes, I am looking for a linux datascope program so I don't have to write one first :^) Host also offers a free download/upload program. I have thought of looking at using the save format as an intermediate if it's not too bizarre. This would have meta data the IL wouldn't. Of course, it will not be generic at all but, I may look at it anyway. It would buy file compatibility with the original tools. That would be handy.
> When you get the upload/download protocol worked out, you would probably want to also write a version that acts in place of the PLC. That would let you "download" programs from the programming software to your development PC (Linux PC) and capture them to files without having the PLC plugged in. That should make the next stage (decoding the instructions) easier. <
First step is to get the thing to talk at all.
> There will be hundreds of instruction combinations to deal with once you take the op code plus address type into account. You will probably want to auto-generate test PLC programs in IL to create these combinations (using Python, Perl, or something like that). <
Yes, I am hoping that there is some regularity based on the fact that they can't be sparing much code on the target for up/download. Whatever they do has to be dealt with in a fairly straightforward manner. They don't have a Cray onboard and they worry a lot about kbytes. I'm thinking static addressing and storage.
> Once you have the upload and download process worked out, and you have captured a complete selection of instruction samples you won't have a lot of use for the original programming software. You will need to haul it out from time to time as you think of new things to test, but at this point you are mainly working from a known set of test data. <
> The basic boolean logic instructions should be a small proportion of the total work. The bulk of the work will be the word instructions, simply because there are so many of them once you take address combinations into account. <
---- snip ----
> I think at this point the whole project is starting to look a lot more practical. At this point however as I said before, don't worry about how to do a GUI or how to edit ladder. Worry about how to convert from a text file with IL to an executable PLC program and then download it to the PLC. Once you have that done you can sit back and evaluate where the project would go from there. <
Yes, the encouraging part is that these are currently, very small and simple computers and there are only so many ways to do the job. And for example, I expect all the "V"addresses to be contiguous, along with counter regs, etc. After a certain point it will become more predictable. The newer generations will have the hp to do much more clever things.
In reply to Anonymous: If you are worried about what Rockwell might do if they found out who you are, then I would recommend not revealing the information until circumstances changed. You're never really anonymous on the Internet as long as web and mail servers keep things like IP logs.
People have reverse engineered protocols and formats before, and if they went about it the right way there was nothing the originator could do about it. However, you would want to consult some competent legal advice before trying this yourself. There would be no point in putting a lot of effort into this and then letting AB get a court injunction preventing the result from being re-distributed.
However, the fact that you believe it is possible at all does tell us a lot. That might inspire someone else to give it a shot.
So I just read the Control Engineering magazine annual awards. Not one category of a non Windows product was listed. Apparently Windows based packages are ok for the masses.
What is the market share for Linux supported Pc sales......minimal
Percentage. Industrial Pc sales with Linux even smaller.
I will NEVER get a large client to deviate from an unproven, unbacked control system.......period.
Can we please move on from this now 13 year old debate with no change in outcome. My employer and almost every one I have contact with has enough trouble supporting the softwares they have on the defacto standard OS, without trying to run on multiple flavors of "everyone will help you" software.
I will stick to me "Best in class" Rockwell ladder software and it's price. I make money writing code and so should they.
I suppose that this same argument holds that music artists or any artists for that matter should give their work away for nothing. The plumber should not charge me and I should give him free tools so he can do it for me. And the car dealer should give his computer diagnostic machines away for free. Shouldn't the DCS manufacturers give away their software for free also and put it on free OS and free hardware.
Bottom line, I do not want free ladder editors because then someone will want free machine code. The market has spoken, over and over and over.
Cmon let's move on already......
Control Systems Engineer
Sent from my iPhone
Dave Ferguson said:
>I will NEVER get a large client to deviate from an unproven, unbacked control system.......period.
Yes, I've always suspected that.
> So I just read the Control Engineering magazine annual awards. Not one category of a non Windows product was listed. Apparently Windows based packages are ok for the masses. <
I don't find that remarkable, since none is offered by any advertiser in the magazine. I'll bet all the winning products are. Purely coincidental, I'm sure.
> What is the market share for Linux supported Pc sales......minimal
> Percentage. Industrial Pc sales with Linux even smaller. <
Absolutely, since it is still extremely challenging to buy any PC without a copy of Windows installed, whether you want it or not, that is hardly remarkable either. But Linux usage is enough to have IBM and Novell and RedHat profiting in a down economy, as well as most of the embedded players that are thriving.
> I will NEVER get a large client to deviate from an unproven, unbacked control system.......period. <
That one I believe.
> Can we please move on from this now 13 year old debate with no change in outcome. My employer and almost every one I have contact with has enough trouble supporting the softwares they have on the defacto standard OS, without trying to run on multiple flavors of "everyone will help you" software. <
Oh, but the outcome has changed, many of the hottest consumer products are running Linux, with many more in the wings. And even on these pages we've seen a lot of Linux in automation activity. You're probably using it in some facet of your business without even knowing it. And I agree the status quo is far too hard to support. Doing more of the same is unlikely to fix that. That would defy Deming's definition of insanity.
> I will stick to me "Best in class" Rockwell ladder software and it's price. I make money writing code and so should they. <
That's fine. I would like a choice and to perhaps divide the pie a little differently.
> I suppose that this same argument holds that music artists or any artists for that matter should give their work away for nothing. The plumber should not charge me and I should give him free tools so he can do it for me. And the car dealer should give his computer diagnostic machines away for free. Shouldn't the DCS manufacturers give away their software for free also and put it on free OS and free hardware. <
The music thing is a great analog. Many artists are finding that they do a lot better if they are not supporting the record companies and getting screwed. I don't mind paying for music, but the policy of selling you 10 songs you didn't want to get the one you do is far inferior to simply buying the ones you do want. It's a choice thing. I choose not to pay the plumber, I can buy the tools and do it myself and come out far ahead. What you do with the plumber is none of my business. And until recently, I did drive Chrysler products because all the diagnostics I needed were available by turning the ignition key on and off and it would blink out what was ailing it. The whole OBDC racket put it back under dealer control until third parties offered scanners. But I liked the simple thoughtfulness of the Chrysler idea, it was better for us users. And certainly not too much to expect. And I don't recall suggesting the DCS vendors give away their software, but the one that ports it to a free OS and runs on commodity hardware would certainly be doing his customers a favor. I would never advocate forcing you to use anything you don't want to. Indeed, that's what the whole discussion is about, choice.
> Bottom line, I do not want free ladder editors because then someone will want free machine code. The market has spoken, over and over and over. <
I'm fairly sure someone will pay you to do what you do regardless of what it runs on. Even most of the Linux kernel developers get paid these days because they are doing something someone wants them to do. Free tools wouldn't change what we do for customers, just how we do it. And I've already admitted, I would be happy even with commercial tools if they run on Linux. That would be part of the mess taken care of. The market can't speak when the vendors think like Henry Ford, "They can have any color they want, as long as it is black" How silly would that be today? Too many choices :^)
> Cmon let's move on already......<
We are in full agreement on that point. We've been in this same situation for way too long. Let's change it.
> Sent from my iPhone<
That's a lot of typing on a phone, thanks for the effort.
cww Itinerant automation guy.
Sent from my Linux box.
In reply to Curt Wuollet:
> I don't find that remarkable, since none is offered by any advertiser in the magazine. I'll bet all the winning products are. Purely coincidental, I'm sure. <
With the more reputable publishers "annual awards" come from the editorial staff. With the less reputable ones, the "annual awards" list comes straight from the ad sales staff and is based strictly on per vendor ad sales revenue. For many magazines and web sites "annual awards" only exist for the purpose of rewarding (or pressuring) their major advertisers and they have a set price list for winning in each category. I don't know Control Engineering's policy, so I don't intend any of the preceding to apply to them.
As for the rest of the discussion, I think he's simply trolling you because he knows he can always count on you to bite. I seriously doubt that he actually believes most of what he posted, so you are wasting your breath arguing with him.
You can however tell him that he is welcome to pay for your software. For $2000 he can have the "enterprise edition" that comes with a really nice shiny "enterprise edition" logo. Now that's value!
Yes, but it's hard to do with someone else's PLC. Not a problem with a Linux PLC. It doesn't solve my problem though, until Linux PLCs become ubiquitous.
I admit that for "simple" to intermediate projects that a web interface
ladder editor would be a nice thing. You could do this with a fanless PC
to start, and maybe do an open source "Brick" PLC as an addition later
I wonder how difficult it would be to use Beremiz project or something
else existing and have the editor run in a browser? Either that or
rewrite the front end to be able to be run in a browser and tie into an
existing projects "runtime".
In reply to Ken E: I think it's a lot easier to write your own soft logic system than it is to reverse engineer a closed proprietary one so you can interface a programming package to it. Some older PLCs documented their binary codes and memory maps, but I'm not aware of any current ones which do.
You can still design the soft logic system so that it is source code and data table compatible with a popular model PLC. That way people can port their existing programs over to the new hardware and they can use their existing knowledge on the new system.
Once you have the hardware to run the programming web server on, why wouldn't you run the soft logic system on it at the same time? That way you can integrate the two and they can share code instead of duplicating functions.
There is lots of interesting and very inexpensive hardware coming out now that is suitable for that, a lot of it ARM based. It's a totally different situation today from what it was 10 years ago. I expect to see PLC vendors eventually simply using this same hardware in their own branded cases because it will be much cheaper than designing their own boards. It's the same situation as when they started using Ethernet instead of RS-485. The low cost of commodity hardware components simply made it impossible to ignore if they wanted to remain competitive.
If PLC vendors wanted to use the web approach, they could add web server software to the PLCs. An actual web server itself is a simple program. The difficult part would be the parsing/compiling back end which would run inside the PLC itself.
I'm calling that "difficult", but I believe that actually that's how PLCs used to work with hand held programmers. That is also why you used to be able to use the same version of programming software for years with different models of PLC, while today you have to upgrade every time you turn around. It's a design choice by the vendors.
What I am describing above is for a simple programming package. If you want a lot of bells an whistles, then that is a lot of work no matter how you write it. However, most people are probably only using a fraction of those features anyway.
> I wonder how difficult it would be to use Beremiz project or something else existing and have the editor run in a browser? <
You might be able to use parts of it, but Beremiz is designed as a conventional "fat" client that runs on a GUI desktop. A web application would have a completely different internal design. What is more, Beremiz is designed to work as an IEC-61131-3 system using MAT. I would be surprised if you could easily adapt it to something else. I looked at the overall design, and I didn't see any obvious way to do so. It's one of a number of alternatives that I considered before deciding on the approach that I intend to take.
In my opinion the only way you have any chance of doing this is browser based. Otherwise you will not compete.
You will not reverse engineer a major player. After Icom days they will see to that, where is Icom, Taylor etc, AB will not make that mistake again.
Liability will be your next major roadblock. I know many a company who will not take a small or unproven app because they want someone with deep pockets to go after if things go wrong.
Next would come the challenge of making hardware or getting buy in for soft control. Since you will not succeed at reversing a major.
Lastly IMHO would be the lawyers and insurance. We are not talking about "What would Google do" here, we are talking machines that move and KILL people. BIG difference than an App that tells you stock prices etc.
Much bigger hurdles to overcome than just writing the code....
PS: I lived the Icom experience as Wintegrator #1 wish it could happen again but much, much tougher.
Control Systems Engineer
Sent from my iPhone
> In my opinion the only way you have any chance of doing this is browser based. Otherwise you will not compete. <
There is no need to compete. I'm obviously not in it for the money, and if the folks that want to use Linux and I can do so, that's good enough.
> You will not reverse engineer a major player. After Icom days they will see to that, where is Icom, Taylor etc, AB will not make that mistake again. <
Perhaps, but they would have to prove damages and sue their customers. That is fairly poor CRM and I doubt that we would do any substantial harm, after all, you'll still buy from them, and the people using the project would still buy hardware. Unless the project got extremely popular, I don't think it would be worth their while to take my 1998 Sunfire or 95 Buick. I submit that going along with the project would do them more good with their customer base than stomping on it.
> Liability will be your next major roadblock. I know many a company who will not take a small or unproven app because they want someone with deep pockets to go after if things go wrong. <
If it compiles and runs correctly, it should be fine. The biggest liability would still be the person writing the ladder code. That's one of a kind and a lot more likely to have unfound errors than an often used programming tool.
> Next would come the challenge of making hardware or getting buy in for soft control. Since you will not succeed at reversing a major. <
Lot's of other people are working on that, as I have. It's not in the scope of this project, at least initially.
> Lastly IMHO would be the lawyers and insurance. We are not talking about "What would Google do" here, we are talking machines that move and KILL people. BIG difference than an App that tells you stock prices etc. <
Somehow factory people manage to do a lot of things without legal counsel. Are those replacement bolts certified? Will those weld repairs hold? Is that the very finest duct tape? Life is full of risks.
> Much bigger hurdles to overcome than just writing the code.... <
Most are irrelevant to a community owned project that operates in the public interest.
> PS: I lived the Icom experience as Wintegrator #1 wish it could happen again but much, much tougher. <
You see, there is some value in trying to change things, Regular old people trying to make things better for themselves and others is a force that's time has come.
cww Itinerant Automation Guy.
I have to re-iterate that I think reverse engineering a PLC download is ill advised. Doing what ICOM did was [in my opinion] only possible because in the old days the PLCs were ROM based. Now that just about everyone is using flash you are really "asking for it" in terms of needing to keep up with their neverending upgrade path. I think an open source project needing to keep up with [potentially] dozens of firmware revisions is going to fail. Can you require firmware "downgrades" to run the alternate uploader.... Maybe. But usually you are limiting capability of new products when you do this. Koyo may be better than some, but I doubt they will open up their doors to the community or keep their design static.
In reply to M. Griffin, my comments about web browser editor was in regard to a completely open source CPU running some kind of softlogic. Contrary to what some have said, I believe that a common open source hardware project would help with software design because there is a defined target that people can program around and not have to try and be everything to every piece of hardware. I found myself looking at the sheeva plug computers, and I don't think they are that useable by themselves (you could argue with this, but hear me out...), but the internal System on Chip (SOC) device by Marvell is incredible. It has two ethernet ports, digital IO, I2C, etc.
My goal for any linux based "PLC" device is to have the following:
- Modern processor to handle softlogic, web server, X server (can be remote), program compilation, etc. GHz class ARM/Atom machine will suffice.
- Dual Ethernet to separate optional remote IO from corporate LAN and/or HMI.
- Cost under $200 to purchase the complete board (Qty 1).
- Can be offered in two types of physical packages:
* light version is a tiny brick PLC with small amount of built-in IO and remote IO....
* Rack version that can be used on a rack, also with remote IO
- Any built-in IO will have removable screw terminal blocks
What is missing is someone to design the CPU guts of the board. Dealing [and most importantly troubleshooting) 400MHz memory busses is not trivial. I've done a fair amount of PCB design work, but this is outside of my personal experience level (I'm an EE who has done automation my whole career). Im almost wondering if there is a hardware group that we could collaborate with at least to develop an open module that would include CPU, RAM, FLASH, and provide headers to break out the CPU signals to a carrier break-out board that will be specific to the design (I know I could handle the latter on my own). There already exists a project called the "linux Stamp" which is really cool, but it is somewhat limited in capability of the processor and memory (at least compared to the Sheeva CPU).
I have a comment with regard to programming environment executing on the embedded computer. Would we not be better off using a specially packaged X windows client that could be made to easily install and run on windows, Mac, Linux? This already exists and is well supported. It has (almost) all of the requirements as a web based approach without getting into coding a new "web" based front end for any package we team up with (MAT, ClassicLadder, etc). That is to say that program software living on the device will be free of the upgrade nightmare, and one installation of (just about any) X client will cover many different versions of the PLC that the user might have. The user also need not know they are running an X client, just ask them for an IP address upon startup and they are hooked up to the system viewing the PLC editor. Just an idea, what do you all think? I think it gets us much closer as we will be hooked up to a lot of software already designed for Linux.
In reply to Ken E: You said: "My goal for any linux based "PLC" device is to have the following:"
Like the following? "http://www.logicsupply.com/products" There is lots of off the shelf hardware there that meets your criteria. There is no need to design boards. If there is anything that you want to design, then you might want to design a case that mounts at right angles in a panel rather than flat.
As for using 'X' for programming, that's fine for on-line programming or troubleshooting on a system that is already installed. How would you handle a project however where you were working on the PLC program but hadn't installed the "PLC" yet, or where the PLC is not accessible to you via the network? You need to be able to install and run the software anywhere.
I don't want to give the impression by the way that a web interface is the answer for everything. I don't even want to swear that it is the solution to this problem until I actually have it working. Even if it does work the server will still need to be cross platform because you will always need to have the ability to do stand alone programming. In fact, when you are creating a new project you would normally do it using a server (soft logic system) running on your desktop (or laptop) PC.
In reply to M. Griffin:
**** In reply to embedded PC for PLC application: *********
I have to admit that the pico ITX from www.logicsupply.com is very attractive from the aspect of a miniature computing platform and this is the type of thing I would probably use on a medium sized system when you have the real estate for remote IO. I've also looked at Advantech and the like, but they are usually more money.
I think what I had hoped is that there would be interest in developing a PLC brick that could have remote IO and/or developing an open card cage design. Having a open source hardware computing platform with built in 24V IO (that you could expand) seems like a good thing to me. Let me ask you though, if there were a completely open platform that packaged a fanless linux processor and sat on a PLC looking rack with IO that could be accessed at bus speed wouldn't you use it? I'm not talking about a PC with miniature PCI boards, but a full blown PLC rack system with field wiring on the front, like a Koyo Click or Contrologix.
Realistically is it worth the effort? Probably not. As I have said before a small PC with ethernet fieldbus is probably sufficient for even 1ms updates given its own segment. I still would like to see someone say "I've tested Wago slice IO with modbus/TCP at 500us rate for 256 IO bits and 16 analog IO words." So far I don't know of anything stated as tested at these speeds, and I don't have a modbus/TCP "slice IO" setup handy. And yes, as I have stated in the past, I do need 1ms update rates for our equipment.
I do often run into the scenario where there is a "small" project that needs to be automated. This is where I thought an embedded linux "PLC" with built in IO (call it a brick PLC) would be handy. For small projects I've always used Keyence brick PLCs which are archaic in their programming, but they work fine. The saving grace is that these small automation projects often do lend themselves to these simple ladder programming PLCs. I guess I'm growing tired of dishing out company money for such limited devices.
********* In reply to using X server/client for PLC programming: *************
I agree with you about "offline" programming. This is a big downside in the idea that "you don't have to install any software to use it" concept. Whether it is web based or X server based you will need a piece of hardware (or emulator software) to host the development environment. I have seen more and more systems that require you to plug in to program them and it is strange when you come from the days of editing on a PC "in buffer memory" and then compiling/uploading to your device. Most devices requiring you to plug in to program have a way to back them up to a file, but it is somewhat backward from what traditional editors do. Usually it's a device like a smart servo amplifier or a vision system. So yes, I agree with your point.
In reply to Ken E: The speed of the I/O is more closely related to how fast the software in the field device can turn around a message than it is to the actual protocol. It therefore tends to be very product and model specific. I haven't looked at sub-millisecond I/O because I've never needed it so far (except for wave form data acquisition, which needs a different class of hardware altogether).
Fairly often the slowest part of an I/O update cycle is getting the data between the communications module and the actual I/O points. This is often a serial bus and is much slower than the actual network speed (although the overhead can be much less). If the communications module has to address each I/O module in the rack one at a time, then a large rack can be slow to update. The result can be a trade-off between high speed stand alone modules with low I/O count and low cost (per point) racks with high I/O count.
When it comes to a small, low cost, shoebox PLC however, you are going to find it very hard to beat companies like Koyo on cost alone if you use a custom hardware design. They are buying enough components to get very good discounts, and they are amortizing their moulds and assembly tooling over larger production volumes. The way to match their costs is use commodity hardware and to use I/O from companies that specialise in it. For some niche applications a specialised hardware vendor like Keyance is always going to be better.
What I am looking for in an open system is the ability to do things that you simply can't do with a cheap (or even an expensive) PLC. I would like a better integrated HMI, integrated recipe management, built-in reporting of status and production statistics, better management of program versions, etc. In other words, I am looking for things which are in addition to just making the machine go, and that is what I am working towards. That is the additional value that the proprietary systems don't offer today.
I wanted to explain my position of needing low IO latency. I don't think you are questioning me, just wanted to give an example where fast IO can add up even for a non DAQ or signal processing application. I do a lot of high speed pneumatic and servo actuated assembly equipment. The servos get actuated by a motion controller and have little latency. For the pneumatics, the IO speed is critical in not needlessly increasing cycle time. I'll give you a brief analysis based on 50ms pneumatic actuations. 30ms-50ms is typical for small cylinders and high flow valves mounted close to the actuator and moving small masses, of which we do a lot of, confirmed by oscilloscope and high speed camera. Also assume that every action has a sensor on the end stroke, which at these speeds you really need to do to get maximum performance without compromising reliability:
50ms * 10 actuations = 500ms cycle (assuming no latency on IO).
Also, assume that the IO latency adds up both ways, as it will when you have a networked bus on both inputs and outputs. (You know, read input, process logic, set outputs) For the following we get these added delays simply due to latency of IO:
For 0.5ms IO latency:
Added cycle time = 0.5ms * 10 operations * 2 (for input and outputs) = 10ms
Latency added to cycle: 2%
For 1ms IO latency:
Added cycle time = 1ms * 10 operations * 2 (for input and outputs) = 20ms
Latency added to cycle: 4%
For 2ms IO latency:
Added cycle time = 2ms * 10 operations * 2 (for input and outputs) = 40ms
Latency added to cycle: 8%
For 5ms IO latency (Modbus TCP default for some devices):
Added cycle time = 5ms * 10 operations * 2 (for input and outputs) = 100ms
Latency added to cycle: 20%
So as you can see, even a 2ms latency is getting up to 8% theoretical latency for this application, which is typical for these classes of machine I deal with. This of course is the worst case latency, and there are probably statistical analysis that says you can expect some fraction of this to be a real average (I bet its more than half the theoretical...).
So this is the reason I keep inquiring about field IO that is tested to respond to 0.5ms polling rates. For packaging, service, and reliability I'd like to stick with something that is packaged for the field, like the slice IO from Wago, B&R, Moxa, etc. In the end, I can't help but think that a backplane system would be better for these types of applications. The beauty of the remote IO is that it leverages the availability of multiple ethernet ports.
I agree with your points about brick PLCs. They kind of have their niche and it is probably hard to beat the price and reliability. Effort here might be wasted.
I also agree with your points about needing more than anybody offers in the PLC world. I think I am in the same boat here, its just that I also need the performance stated above as well. I don't think this is unique to us. I also don't like having separate boxes and programming environments for control, HMI, motion, and database. Its a lot to manage. There are times where you are putting a lot of time into interfaces that pass data around. I am encouraged that RTOS like Xenomai can have an application with mixed RTOS and "conventional" linux threads in one memory space. Picture HMI and control threads sharing the same global data structures without having to resort to a RTOS shared memory interface (yes, you probably need to use Mutex or Semaphores here...). Imagine RT threads writing to some data logging queue that a non RT thread is interfacing to database, etc. I know you can write shared memory interfaces to separate these (and in some cases you WANT to do this) but sometimes it is better to do it under one hood. Xenomai can supposedly switch in and out of realtime automatically, although I don't claim to know how this works. Current commercially available HMI/SCADA systems seem to piece together database functionality with slow complicated OPC mess running on a separate windows PC which I can not stand. I think we are preaching the same thing on this front.
I respect your experience and contributions here. I just want to stress that realtime and low latencies are not just for niche applications. Certainly for process and slow automation its not required. Unfortunately the tools to make things flexible are not always RTOS friendly. I'm hoping to find one popular fieldbus vendor that offers a fast slice IO. Maybe if I end up going down that road I'll try and give the manufacturers the third degree on their internal "slice IO" serial bus speed. This is usually like pulling teeth.
In reply to Ken E: I am quite familiar with these types of I/O scan delay. However, in between high speed packaging and low speed process industry is a very broad middle where the sort of times you are talking about don't make a significant difference. 50 ms cylinder strokes will often either damage the product being worked on, or else catapult it through the air.
You might also want to compare those times to factors such as MRS positioning accuracy and cylinder charging time which make such high speeds impossible for anything other than the very smallest of pneumatic cylinders. Also consider that a small (20 amp) motor contactor can take close to 100 ms to close. In most applications these things matter much more than the I/O scan time. This is why you don't find customers scrambling to "upgrade" their PLCs whenever the vendor comes out with a faster version.
There are however applications where this does make a difference. For those sorts of things you might want to look at the I/O that Beckhoff offers. A lot of their I/O is designed specifically for high speed. You might have to adjust your designs to their packaging however.
It sounds as if what you want is the sort of thing that Armin Steinhoff is doing (his latest systems run on Linux), except you want the actual logic engine to be open source and program using a type of textual language. He doesn't have very much detail about his products on his web site, but you may wish to have a look at it for ideas.
Replying to KEJR::
<<Let me ask you though, if there were a completely open platform that packaged a fanless linux processor and sat on a PLC looking rack with IO that could be accessed at bus speed wouldn't you use it?>>
Something like this? http://www.advantech.com/products/PC-based-Controllers-I-O-Modules/sub_1-368QKF.aspx
There are suitable systems that would require only a port of Linux and drivers. I think AD has one that could use an H20 port. But they are really expensive. But they do have the whole PLC ball of wax> I have done a little design work on adding a backplane bus to a PC104 processor. With a little money I could generate the Gerbers and have the boards made and package them. But that's the problem with Open Hardware. Hardware costs money and you end up with a business rather than a project. And then it's not Free anymore. And you can publish the plans, but very few people want to build their own.
I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. I can't help but think once you add room for the cardcage rails, front panel, and connectors you will be looking at a form factor that is about the size of a 3U rack computer, which may be too large. What rough size was your initial design? Was it Euro rack based (VME)? Did you find any cost effective PC104 modules? These always seemed to be in the $400-$800 range when I bought them, probably because of demand. I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104.
It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing.
There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) but over the last ten years I have seen these things come and go like the wind. PC104 seems to be the only true standard (that I am aware of) that has lasted in the embedded arena. I tried to get a price on a new SOM from ADLink but I think they blew me off once I gave them my personal home address and quantities. (pricing for 1,10,100). You know that when it is hard to get a price that they don't intend to sell it to end users, which is a bad sign already.
> I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, <
No, no ... the ISA bus isn't simple because you have to handle all resources manually by jumper settings a.s.o. That means you have to know all hardware details about ROM, RAM. IO addresses and interrupts. PC/104plus is much better ... it works also on Compact PCI carrier boards. There is also PC104plus based on PCIexpress ...
> fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. <
PC/104 isn't designed for the use only as piggy backs. It allows to build small ans stable PC systems for the harsh environments.
> I can't help but think once you add room for the cardcage rails, front panel, and connectors you will be looking at a form factor that is about the size of a 3U rack computer, which may be too large. What rough size was your initial design? Was it Euro rack based (VME)? Did you find any cost effective PC104 modules? <
Yes ... I have seen professional CPU boards (800Mhz CPU clock) for less than 200 Euro. ( e.g. http://www.icop.com.tw/pddetail.aspx?id=127&pid=4 )
> These always seemed to be in the $400-$800 range when I bought them, probably because of demand. I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104. <
No problem ... there are other format available e.g PMC.
> It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing. <
> There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) <
Also available: http://www.icop.com.tw/pddetail.aspx?id=135&pid=4
> but over the last ten years I have seen these things come and go like the wind. PC104 seems to be the only true standard (that I am aware of) that has lasted in the embedded arena. I tried to get a price on a new SOM from ADLink but I think they blew me off once I gave them my personal home address and quantities. (pricing for 1,10,100). You know that when it is hard to get a price that they don't intend to sell it to end users, which is a bad sign already.<
Well, I'm not sales guy from icop .... this hardware is just one selection of other possibilities and is available since years.
> I looked back at your idea a while back when you were heading down the PC104/backplane path. I thought this had merit at the time because I too agree that ISA is simple, fast, and built in to many boards. I do somewhat think that PC104 is a bit large for a piggyback design. I can't help but think once you add room for the cardcage rails, <
----- snip ----
It's a bit off topic here, but the height (width?) would be controlled by thePC104 stack and the bus width. It would not be any standard, as most require specific connectors, some of which cost more than I would hope for a whole module. The lowest cost, suitable, connector would be a .100" pin header. These are cheap and if the better grades are used, reliable. Using the whole ISA bus would be overkill and require high pin counts. By decoding and using hard card selects, you could keep the address bus size down to the number of registers expected on a card and make the cards much simpler and cheaper. Of course a narrow bus means longer scan times, but not out of the range of popular PLCs. The cards could be pretty simple as they would need few glue chips and little decoding. The PC104 processor is too expensive, but would have the advantage that you could stack special functions and make for a very versatile PLC. It would also give a measure of protection against single sourcing and to a lesser extent, obsolescence. The PC104 bus is on pin headers already so, you aren't going to find something much smaller to be of advantage.
> It is true that someone would have to take some risk and dish out the cash to make some prototypes. Given the interest I've seen so far from this list, I don't think I would bank-roll the project. I think that sometimes open source projects need momentum though before people start to buy into it. I know I might be able to scrounge/beg/ebay a PC104 module and some rack hardware, but there would be a few bucks on misc items and interface boards. You would have to gamble that you could sell enough "kits" to make the initial investment worth designing. <
Yes, the big question mark would be getting a stable, quiet. backplane, but at ISA speeds, this is feasible without extensive R&D or special fab. But. it's beyond my current means, or my former means, for that matter, but I felt it had to be done. At least far enough to show people that it could be done, and that there is no real magic behind PLCs. I also think it lends a little credibility to the issues with "Free Hardware". But they are not insurmountable.
> There is some hope with System on module (SOM) standards (much like PC104, but more like a credit card package) but over the last ten years I have seen these things come <
----- snip ----
Once again, smaller is not necessarily better, cheaper would be better. But the whole point is that a good PLC could be done with OTS components, 20th century technology, by an old electronics guy who is not even employable by today's standards :^) and maybe 25 individuals or companies willing to risk the price of a commercial PLC. And you could run whatever your heart desires on it, including full blown DAQ cards, video frame grabbers, and whatever else is available for PC104 from a variety of vendors. And would network with whatever you have a mind to talk to, and using the tools of your choice. This is the antithesis of the current PLC offerings and the advantage should escape no one.
As I've mentioned before, things don't have to be the way they are. So, if I'm not wowed by new systems whose features are quite overwhelmed by anti-features like lock-in, single sourcing, and marriage to a predatory monopoly, it's probably because I have a clear vision of how we could have the good without the bad. Suppose there was a Foundation for Open Industrial Automation? Very modest projects and cooperation with the many authors waiting for a platform could greatly change the slope of the playing field.
KEJR Said: "I do really think ISA is a perfect bus for automation, I just wish there were more choice besides PC104."
Have you ever seen an STD bus system? They are fairly obsolete now, but they were designed for embedded computers. The cards plugged into a rack similar to a PLC and had an eight bit bus, which was similar to the 8 bit ISA bus. Some companies adapted a 16 bit bus, but it was not as popular. The STD systems were tough as nails and fairly compact. Early systems used 8 bit micros, later x86 chips and became popular. The narrow bus was the downfall of the STD bus, AFAIK. A Linux based STD system would be very nice today.
See Curt's reply. If you have a local bus attached to the CPU you can have the CPU carrier decode the ISA address space into 8 or 16 divisions, which will end up being your rack IO address limits. Each IO card will get a decoded "card select" from the rack based CPU carrier board, so no jumpers will be necessary. In this way you can develop cheap and simple IO cards with a simple PLD or 74 series chips.
PCI is somewhat more difficult for a rack based "simple IO" interface because of its high speed and need for interface chips. I think you can do a PCI interface in a $5 Altera chip, but I haven't confirmed this. In real life the PCI board still needs a physical address, so you will have to have your backplane have some kind of additional jumper or slot ID anyway.
Or if you can tear yourself loose from the wide bus thing and go thoroughly modern, you could now implement with a serial bus (SPI@1.5mHz) and the plethora of I/O expanders from Microchip,etal. and have a very low cost backplane and still make very respectable scan rates with cool stuff like interrupt on change at the cost of software complexity. That would require a library to hide the nasty serial details. I've just been looking at that as part of a search for suitable IO port chips. That would open a large variety of non PC104 options. Sadly, it's getting very difficult to find through hole components. But there are a lot of inexpensive processor boards that can do SPI. I would lament the loss of nostalgia and the easy repair and interfacing the traditional approach provides, but the cost advantages would be fairly large.
In reply to M. Griffin and CWW:
I thought about a serial bus, and although the hardware is arguably more complicated, it is within our grasp, especially if we can use one of these SOM devices (Linux Stamp, ICOP, etc). Using an 8 bit micro (I'm partial to AVR) on the IO cards to talk to the bus is a good idea especially since you can program them to be event driven on change of state (as Curt suggests).
I did a study on our typical machines and found that although we benefit from a fast scan rate that we weren't moving much data at all during any given millisecond (Maybe one or two changes of state per ms). I don't think this is unique and probably represents a typical machine. Analog will still probably want to be polled, but we could offer a choice of a data averaged analog value or the instantaneous value and let the little microcontroller do the work there.
Event driven or not, I think 1.5MHZ bus with a very simple protocol would be fine for most people. I belive SPI has an addressing scheme already (I have to check this).
I know VME cards are expensive, but why couldn't we use the Euro-card *hardware* to make our own simplified system with these available components? I've worked on these systems before and they aren't much more than off the shelf rails cut to length with sheetmetal endplates and covers. Sheetmetal can be REALLY cheap in any kinds of quantity, and even cheaper for prototypes if you have a shop (I do...). We could customize the package to be close to PLC sizes. Developing a backplane for a serial bus is rather easy once the mechanicals are taken care of.
> I thought about a serial bus, and although the hardware is arguably more complicated, it is within our grasp, especially if we can use one of these SOM devices (Linux Stamp, ICOP, etc). Using an 8 bit micro (I'm partial to AVR) on the IO cards to talk to the bus is a good idea especially since you can program them to be event driven on change of state (as Curt suggests). <
Even better than that from a cost standpoint is that the expanders I was looking at don't need a uP to do the interrupt on change (report on exception), and a card would need little more than a local regulator( to use 24V power), the chip and 24V interface. And since they are programmable as either inputs or outputs, the cards would be the same except for the interface stuff. And SPI D/A and A/D are widely available. If you find an embedded processor that already has the SPI work done and a Linux port, you could be in business in the time it takes to layout and fab cards. The only kink I can see is enough chip selects, but if the processor card chosen has utility outputs, these could be used as high order address and preselect a bank for the provided cs lines. One might want to do some sort of an output enable for the interface to keep the outputs defined while you initialize them, I forgot this on the board I did as they default to inputs on power up. Even better might be the chips that can be programmed in a shutdown mode, then brought up all at once.
> I did a study on our typical machines and found that although we benefit from a fast scan rate that we weren't moving much data at all during any given millisecond (Maybe one or two changes of state per ms). I don't think this is unique and probably represents a typical machine. Analog will still probably want to be polled, but we could offer a choice of a data averaged analog value or the instantaneous value and let the little microcontroller do the work there. <
> Event driven or not, I think 1.5MHZ bus with a very simple protocol would be fine for most people. I belive SPI has an addressing scheme already (I have to check this). <
You don't really need to design a protocol, in fact you can't. You do what the target chip wants. Once programmed, there is very little overhead and read and write should be symmetrical. An extra line per slot for the interrupt would let you skip input regs with no change. And you can do the same in software for the outputs since you know if you changed them. > I know VME cards are expensive, but why couldn't we use the Euro-card *hardware* to make our own simplified system with these available components? I've worked on these systems before and they aren't much more than off the shelf rails cut to length with sheetmetal endplates and covers. Sheetmetal can be REALLY cheap in any kinds of quantity, and even cheaper for prototypes if you have a shop (I do...). We could customize the package to be close to PLC sizes. Developing a backplane for a serial bus is rather easy once the mechanicals are taken care of.
Even the VME rack parts are really spendy, out of all proportion, and the connectors would be the major cost of your PLC. I envision PC mount wire clamp connectors for the world end ( the little blue jobs you see all over) and pin headers and sockets for the bus end. Vector and others used to sell card racks, but I would look at the packaging AD and Optomation and other low cost folks are doing. One way to deal with this is to find extruded shapes that can be cut to length and the cards mounted, then a simple pair of slotted rails can be all you need. You might even be able to use a ribbon or flex bus to eliminate the connector strain issues. All of this could be done with little or no tooling cost. A guy with a mill/drill would suffice. I've been thinking about this while waiting for the funds to buy a used AD DL06 or similar. I need to be doing something.
In reply to Ken E: If you are thinking of putting a microprocessor on each I/O card, then you might want to give serious thought to using USB as your I/O bus. It might not be an obvious choice at first sight, but it has a number of advantages.
It could be configured such that each rack is a USB hub. The backplane connectors to each card could be USB type A connectors.
Power to the electronics in each card could be provided via the connector (provided the current draw was low enough). I/O power would of course be provided conventionally (through the card's front connector).
Racks could be daisy-chained via USB cables. You could have a maximum of 127 USB devices (including rack hubs). That should be lots for most applications.
Off-rack expansion to a device which won't fit in a rack could be provided by USB cables. For example, you could have a dummy card which simply brings the USB connector out to the front of the rack.
This configuration means that all the electrical engineering issues of cables, connector designs, signal characteristics, etc. are already taken care of. You can also use off the shelf cables for making connections between racks.
If you can map the device characteristics to one of the common USB device classes, then the driver on the PC end is taken care of already. For example, a digital I/O card could appear as a USB mass storage device (the same is true for anything else whose I/O or data table could be memory mapped).
A single USB device can have multiple "pipes" for transferring data. There are 4 types of pipes: isochronous transfers, interrupt transfers, bulk transfers, and control transfers. Between these 4 types you ought to be able to find something which suits your applications.
As far as speed is concerned, USB has a lot of bandwidth. The current version (USB2) is 12 Mbps. USB3 will increase that to 4 Gbps. Actual throughput after overhead would be a lot lower than that, but either should give you all you can use (and perhaps more than a PC could handle). I don't know how that will translate into latency however.
Using USB would give you the following:
1) Electrical design is done. You just need to follow the specs,
2) Connectors are fairly robust, and should be quite cheap.
3) Cables are off the shelf.
4) Hub chips for rack interfaces are off the shelf and hub designs should be easy to find. You are just basically adding a mechanical rack mount to a (stretched out) hub.
5) USB device chips are quite common. For example I believe that AVR sells micro-controllers as USB devices. Things like A/D converters may not be available with USB interfaces on them (SPI has the advantage there), but you could interface those to a micro-controller that has one.
6) I/O cards could be hot-plugged.
7) Expansion racks can be daisy chained.
8) Up to 127 devices (including hubs). This is comparable to the capabilities of most mid range PLCs. You may be able to go beyond that by simple plugging any additional rack chain into another USB port on the PC (I'm not sure what the OS limits are however).
9) If you can map the I/O cards to a common existing USB device class (with existing drivers) then you can use existing drivers that are already installed.
10) A lot of the software interfacing issues are already handled in the OS. For example, if you plug in a new card, it shows up in the OS without having to scan for it (automatic discovery). You may be able to use existing desktop tools (e.g. Nautilus) to browse the device for testing and troubleshooting purposes.
Those are the pros for this idea. For the cons, I don't know if there is a USB patent pool which would demand royalties. It is quite possible however that any patents apply to the chips themselves and that you are OK so long as you are simply using those chips (you certainly aren't going into the chip making business).
The USB name will be trademarked, and you probably won't be able to use the "USB" name or logo anywhere on your hardware unless you were a member of the USB vendor's association. That probably wouldn't be a problem however as far as you are concerned.
Oh yeah, I've seen A LOT of STD bus boards! Just last year I had to have some legacy boards scanned and converted to GERBERs so I could have more made for spares. That is the good thing about those old boards that were DIP based, you can actually work on them. We have a lot of legacy systems running z80 embedded control from the days when PLCs were way too slow to do the job. Occasionally we have to reseat a card or replace a ribbon cable connection, but that's about it. I'm waiting for some electrolytic capacitors on our old obsolete PMAC STD boards to start popping. Some of them are approaching 15-20 years of service.
I know you can buy Pentium class CPUs for STD bus, but I can't help but think it is still dated. I was also wondering about 3U VME since it has a rugged mechanical spec. I've never used it and it seems like it would be expensive, but I don't know this. Maybe a version that is VME in mechanical but electrically simpler.
In reply to Ken E: The problem with the older bus standards is that the supply of interface chips is dwindling and will disappear.
As for VME, I believe that it is much more expensive than STD. The reason that STD bus existed was that it was cheaper than VME while still being good enough for many applications. VME seemed to be for applications where cost was no object.
Although STD bus was a "rack" that was superficially like a PLC, it wasn't as easy to work with as a PLC. The cards were exposed and you had to be very careful not to drop anything into them. The wiring connectors were on the edge of the PC boards without any mechanical support and could be damaged if you were not careful. The wiring usually had to be tie-wrapped to the card cage to avoid putting any mechanical stress on the cards or the connectors. If you had an electrician who liked to use his "big" screwdriver on everything, you needed to keep him away from any STD bus equipment.
The companies that I know of that used STD bus used it as a hardware platform for their own soft logic system. PLCs didn't do what they needed from a software perspective, and they also needed to avoid vendor lock-in so they could guaranty the availability of parts to their customers based on their own product lifespan plans rather than the product schedule of a PLC vendor. All of the companies that I know of that used STD bus no longer use it and have switched to networked I/O with a single board computer or passive backplane PC.
If you are looking for a design for creating your own backplane bus system you might want to look at I2C or SPI buses. There are a lot of chips which support these protocols and I can't think of a better way of getting a low package count design.
And I promise to rev it every year or so, so he can pay for it again. But really, Dave has a role in the cause, if for no other reason, than a debate is much more interesting than a monologue.
OK I'll bite.....................for one thing, if you think that I need to see Control Magazine to tell you who the TOP players are in each category, you are very sadly mistaken. I could have made the entire list (with my eyes shut) and been within one place in every category from 25 years of experience.
Second, if you think I give a rip what OS the controls run on, you are also sadly mistaken, I use them all (and PS, I DON'T BUY THEM). What I am making a point and have said it a million times over the many, many years of listening to this VERY OLD debate is that I am a TOOL USER. I do not care what TOOL I use to do it, the value (ie Intellectual property) that I wield is in WHAT I DO WITH THE TOOLS, not which tool I do it with. Sort of an auto mechanic who actually fixes cars, or the carpenter who BUILDS houses, I don't sit around and whine about how good I would be with a different hammer or wrench.
While this debate has been going on and on, I have quietly been busy selling my services. If you are so adamant that this is the way to go................QUIT TALKING ABOUT IT and get busy doing it. GO, START, BEGIN, quit trying to convince us.............it is a free market world, go for it. Less talk, more action............in the meantime I will be happily employed using the tools not worrying about making them.
Control Systems Engineer
Gainfully employed with too much to do and no time to worry about what tools I am employed with
Sent from my IPhone (with non Microsoft Software)
On Dave Ferguson's post:
TA> What is the market share for Linux supported Pc sales......minimal
TA> Percentage. Industrial Pc sales with Linux even smaller. <
if it would be, for example, a web-like interface, the core software did not bother the end user... Wintel, or Lintel, or wxWorks+Motorola. So, the idea has the right to exist and to be implemented.
TA> Bottom line, I do not want free ladder editors because then someone will want free machine code. The market has spoken, over and over and over. <
And what? Let it be. Free machine code does not mean a work without any payment. So, free machine code does not contradict the market laws.
Vladimir E. Zyubin
Hostile takeover :^) of a commercial PLC is certainly not the easiest way or the best. But it's probably the only way to change what I _have_ to work with. The PLC hardware thing is not that difficult, it's just registers on a bus and level translation and sometimes an A/D and D/A convertor. That is, it's not much different from any _old_ uP design where the I/O was off-chip. Until quite recently when they started doing ASICs, most of the chips were off the shelf items and how they work was no mystery. The packaging costs money because the tooling is only practical for reasonable volumes. But I digress......
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.
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.
When it comes to traditional hardware PLC i use XP within VMware on a linux host system, because i can use what the PLC vendor delivers.
When using (embedded) PC hardware i do not use ladder at all. The ladder code is the minor part in an automation system anyway.
Our principle can be seen here:
As you can see we have a data acquisition that reads the inputs cylically and stores the values within a shared memory. Output commands can be send over a mailbox to the daemon that will send them to the hardware outputs. The daemon(s) are configured with an ini file.
Once the I/O is connected to the computer you can do visualization.
Instead of ladder code we now use C/C++ for the PLC logic. In principle this is a endless loop where inputs are read, some logic is applied and outputs are written. This "PLC logic" can run as a separate process with access to shared memory and mailbox. Programming is supported by a library that handles the frequently used stuff.
If you want to have a graphical programming environment you would need a graphical editor which allows you to place "blocks" and to connect them with other "blocks" and I/O.
From that you would generate our C/C++ program.
The above principle is used in
for example. But this is Windows only.
As graphical editor
http://www.scilab.org/ (similar to LabVIEW)
would be a good starting point. You would now need a code generator that produces the C/C++ code for that model.
Additional to my posting i send you this link
At the risk of being ridiculed, have you thought about Java? You immediately get cross-platform support, and NetBeans / Matisse (or even Eclipse with Matisse) is an excellent GUI builder. True, Java isn't fully open yet, but it's getting there. And there are LOTS of open source projects out there to draw from. Another advantage of your ladder editor being written in Java: put the editor on the "PLC" and pull it up remotely using a Web browser. No more worrying about which version of the editor was last used on that system, or running around looking for the project file.
Sage Automation, Inc.
I don't often ask a question then ridicule the answer. One problem is I've done very little with Java. I'd have to learn it pretty much from scratch. I don't know if there is an equivalent to GTK or QT or better yet, higher level GUI builders. Of course, the learning curve applies to almost anything but C. And I'm not at all concerned with Windows compatibility. It would expand the scope and probably limit the project to what can be done on both. And there is already free Windows software for many PLCs and to many end users free obviously means more than Open. Right now, I'd settle for a commercial shrinkwrap package that runs on Linux, to get the ball rolling. Did I say that out loud? If Java would be the easiest, it's still in the running. I'd need some help though. I'm sure it could be done, I've seen some pretty cool Java stuff lately. Right now, If I had to come up with something soon, I'd probably do it with ncurses and a custom character set for the Linux console. Almost anything would look more modern than that :^), But it would be fast and small and in C.
In reply to James Ingraham:
>At the risk of being ridiculed, have
>you thought about Java? You immediately
>get cross-platform support,
I believe that Python would be much better for that. Cross platform support is excellent, and GUI programming is easier than it is with Java. You would also have a very rapid edit/test cycle which makes development faster in that type of application.
>Another advantage of your ladder editor
>being written in Java: put the editor on
>the "PLC" and pull it up remotely using
>a Web browser. No more worrying about
>which version of the editor was last
>used on that system, or running around
>looking for the project file.
What would be a good toolset to do a quick GUI in python that would be cross compatable? Is a certain GUI builder and/or widget set easier to get started with?
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.
Standard Python distributions come with something called TkInter (or often just Tk).
a) Comes with Python.
b) Easy to program.
c) Good documentation.
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.
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.
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.
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.
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.
wxWidgets (formerly known as wxWindows) is a cross platform GUI toolkit. The Python binding for this is wx-Python.
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.
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.
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.
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 :^).
In reply to Curt Wuollet: I think you are jumping into the middle of the problem instead of starting at the beginning. Before you can worry about editing ladder, you need to be able to display ladder. Before you can display ladder, you need to be able to read in IL and parse it into elements that your editor can understand.
Lets start by assuming the following:
a) You have picked out a specific PLC.
b) That PLC has a fully specified IL format.
d) There is a one-to-one correspondence between the IL instructions and the ladder symbol representation.
d) We aren't going to worry about getting the program into the PLC.
e) We aren't going to worry at this stage about import and export to the OEM's file format. We are just reading the file in from a straight text file with one IL instruction per line.
If we break things up into stages, they would be something like this:
1) Read in the file and split it up into lines.
2) Go through the list of IL and analyse each instruction. Basically, we are doing most of the same work we would need to do if we were compiling it. Fortunately, IL syntax is normally very simple. That would work like this:
2a) The first symbol on the line is the instruction. Any symbols following it are parameters.
2b) Attempt to look up the instruction. Does it exist?
2c) Compare the parameters to the the definition the table. Do they match?
2d) Since the instruction names are sometimes overloaded, you might have more than one instruction with the same name and can only distinguish between them by the parameters.
2e) Add each parsed instruction to another list. In this list we store whatever information we may have figured out about the instruction in a form which lets use retrieve it more easily.
2f) While we are at it, we also break the program up into rungs and subroutines (so we have lists of lists).
3) Assuming everything is OK so far we can now display the ladder. Basically, you have a "matrix" of display references that you use to draw the rung on the screen. An "AND" moves your current position to the right. An "OR" moves your current position down and to the far left. A branch in the middle of the rung essentially starts a whole new rung which you have to knit back into the middle of the main rung (this can be recursive, as you can have a rung within a rung, etc.). I will pass over the details of this at present, but you might have questions about this later. This requires a series of heuristic rules, so this is dependent on the model of PLC you are using.
4) Some sequences of IL may not be able to be represented as ladder. In this case you need to default those rungs to IL.
5) Now you can add, delete, or replace instructions. As to how you get the mouse clicks, well there are different ways of doing this. You can draw the whole thing on a canvas and get the mouse clicks as X, Y coordinates (and then you figure out which contact this represents. Here is a reference as an example: http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html
You can do it as an array of custom buttons, and get the mouse clicks just like an ordinary button click. You can do it as an array of windows, with one window for each contact. The best way of doing it will depend on a lot of factors, including what programming language you are using and what sort of editing features you want to support.
6) You don't let the user add instructions anywhere they want. Rather you do something like this. If they are adding a contact to the right of the current position, then you are inserting an AND instruction. If they are adding a contact below the current position, they are adding an OR instruction. It can get more complex than this, but that is the basics.
7) Each time you change the rung, you redraw it.
8) At some point in the edit cycle you may need to re-parse the rung to validate it.
9) During this whole cycle you need to limit what the user can be done at each stage to avoid having to deal with their mistakes.
10) When you are done editing, you go back through the edit list and extract the instructions and parameters and make a new output file.
>> At the risk of being ridiculed, have you thought about Java? You immediately get cross-platform support, <<
> I believe that Python would be much better for that. Cross platform support is excellent, and GUI programming is easier than it is with Java. You would also have a very rapid edit/test cycle which makes development faster in that type of application. <
The PLCOpen editor from
http://www.beremiz.org/documentation/the-plcopen-editor supports ladder logic. It is written in python, wxPython and wxWidget or wxGTK
So you have not to reinvent the wheel completely :)
> I just don't see that type of SFC programming being easier to write than text programming using a system such as I described earlier. I've done it both ways and am at least 5 times faster with a structured programming language and RTOS. Maybe we'll just have to say it's a matter of preference. <
It is not only a matter of preferences and SFC is not the same as function block display (FBD).
We have reimplemented a complex graphical application - written in C/C++ by 6 developers within 3 years - with FBD and 3 developers within ~6 months. It is more effective to work without the syntactical overload of textual languages and application specific composite function blocks ... just caring about the semantic of function blocks.
PS: please write this lamp on/off example in C++ ...
In reply to Armin Steinhoff:
If my interpretation of your on/off example is correct a version if this in C (I won't use C++ since you really don't need it for this example) would be as follows (or very close to it). I'm assuming the button is a real switch and has been debounced by external software, or the debounce could be handled in the Waiting function with some modification. I won't include the function internals because they are simple and obvious.
****** Begin Code ******
******* End Code ******
What makes a system in C or C++ useable/readable/maintainable for automation is the specific function calls and/or classes available for you to use. In some cases using OOP could be bad but again it is all up to whoever programs it. I stress that a bad IEC 61131 program can be just as bad as a bad C/C++ program.
What CAN be difficult is that non RTOS programmers will struggle with synchronizing tasks using RTOS constructs and I think these things need to be addressed. I have seen flowchart and/or SFC types of languages defining the overall program flow, but why could not these internal flowchart elements be RTOS functions and tasks running in series/parallel with a RTOS support?
In reply to KEJR:
> [ pseudo code deleted :) ]
> What CAN be difficult is that non RTOS programmers will struggle with synchronizing tasks using RTOS constructs and I think these things need to be addressed. I have seen flowchart and/or SFC types of languages defining the overall program flow, but why could not these internal flowchart elements be RTOS functions and tasks running in series/parallel with a RTOS support? <
That's exactly what we do.
In reply to Armin Steinhoff:
You mention your system can develop an outline for overall top level structure using graphical language (lets say SFC), but can you have parallel execution of SFC elements that are coded in text code and happen to contain "blocking" code? In the case of automation I'll define blocking as waiting on an external resource such as an input bit from a sensor. i.e. code equivalent to:
While(Mysensor == OFF);
What I'm getting at is that I have seen systems that allow you to definea system structure in SFC, and to have the internals of the SFC blocks consist of a text language (usually Structured text, or ST). The problem with a lot of IEC implementations, especially related to ST code is that the internal ST code must not block or else the system will watchdog.
Does your system allow parallel execution when one or more of the executing SFC elements are blocking? Is this accomplished via multiple RTOS threads, or do you do the technique of skipping to the next parallel element once a blocking condition is encountered on the current element?
If you have hardware, ControlLogix could certainly be a target. I don't and only would if, by chance, I find a job working with it. Let us know what you hear. But I'm encouraged to hear someone who thinks it's feasible.
In reply to KEJR.
DACHSview-SDL doesn't support SFC ... it supports function block display (as done by other newer standards - e.g. IEC61499). Besides the FBD is also supported a subset of elements of Petri Nets .... used for the lamp ON/OFF example.
The thread concept used for FBD includes blocking/non-blocking threads scheduled by the RTOS. These threads can be assigned to individual cores of multi-core CPUs. That's provides any kind of parallelism.
> You mention your system can develop an outline for overall top level structure using graphical language (lets say SFC), but can you have parallel execution of SFC elements that are coded in text code and happen to contain "blocking" code? <
Yes, blocking function blocks are allowed.
> In the case of automation I'll define blocking as waiting on an external resource such as an input bit from a sensor. i.e. code equivalent to:
> While(Mysensor == OFF); <
Bad example ... waiting could be done on semaphores, mutexes, messages and software/hardware interrupts
> What I'm getting at is that I have seen systems that allow you to define a system structure in SFC, and to have the internals of the SFC blocks consist of a text language (usually Structured text, or ST). The problem with a lot of IEC implementations, especially related to ST code is that the internal ST code must not block or else the system will watchdog. <
Yes, this a one of the most disadvantages of the polling operation of IEC61131-3. Blocking function blocks/calls are not allowed in that environment.
Distributed application are also not allowed.
> Does your system allow parallel execution when one or more of the executing SFC elements are blocking? <
Yes, the threads of the DACHSview target are not scheduled by an internal proprietary co-operative scheduler of the target ... they are scheduled as system processes (or threads) by the RTOS scheduler.
> Is this accomplished via multiple RTOS threads, or do you do the technique of skipping to the next parallel element once a blocking condition is encountered on the current element? <
We are using multiple RTOS threads coded with function blocks. This allows us e.g. to run parallel execution of these threads on different CPU cores ....
We use function block display as a general purpose development language ... without the restrictions of IEC61131-3.
In reply to James Ingraham:
> put the editor on the "PLC" and pull it up remotely using a Web browser. <
I have no idea what is the background, but it looks like an implementation of the approach you describe.
Vladimir E. Zyubin
In reply to Vladimir E. Zyubin:
>> put the editor on the "PLC" and pull it up remotely using a Web browser. <<
> put the editor on the "PLC" and pull it up remotely using a Web browser. <
I gotta admit, that is an excellent idea...
I quite agree that we could use a truly open hardware platform. And yes, that can be done. I have several PCs operating as Linux PLCs in use in various places with hardware add-ons that I offered here. And I have, on paper at least, a design that will give a PC104 computer industrial grade I/O. And between the two, I'm confident it will work and meet the practical needs for reliability and "hardness". But, there are relatively few who will build gear and push it through management and naysayers and assume the risks. What people seem to want is a fully "productized" system with the proper certifications and ratings and approvals. That I can't do on unemployment. Even a band of brilliant hardware hackers can't do that. I'm not even sure that a well funded startup can do that because you'd burn cash until the approval bodies got around to making you jump through hoops, eventually approving or not, depending on the golf schedule. And I'm not sure you could compete on the low end with the $69 Koyo Click or similar offerings that are popping up.
But Koyo gets at least some, and I think most, of their software from a small outfit called Host Engineering. I've corresponded with the Host folks on a few occasions about various things and they are nice folks, but are singularly uninterested in Linux.
But suppose someone like Koyo could get a Linux programming toolset for their hardware at little or no cost. And it would be supported by the community. The community could do more than Host or Automation Direct to make the stuff really good. Where's the downside?
That's what I would like to try to make, the machine independent part of a programming package. It would need a "driver" to adapt to a particular machine, but they support a whole range of machines with one package. They could certainly keep their old package, but also offer an Open Linux package. And how handy would it be if you could program several PLC brands with the same package? The community is the only hope for that.
I think in a way we are going backwards in our attempt to use sophisticated software tools (C/C++, Python, Java) to generate mediocre automation software (Ladder, SFC, etc).
I think it would be more interesting to see an automation system based on C/C++ running on an RTOS with all of the familiar automation concepts easy at hand (timers, IO access, Monitoring/debug). I have had some experience evaluating a commercial motion control product that used Xenomai but had a sophisticated front end editor/uploader GUI (yes, it did run in windows, but you could do something in Linux too, albeit on your own...). What was interesting to me is that you had the power of a hardened embedded linux device that could be programmed at the RTOS level but had access to IO, servos, ethernet, etc through shared memory.
One could argue that there is no point in creating an open source automation platform based on an RTOS. Its already available, what is the point? Not all automation guys (even sophisticated ones) have the time or ability to configure target OS, hardware, and development environments. They want something they can purchase, install the software, and be up and running. I believe the following is necessary for the masses to accept such a platform:
- Crafting an environment that allows normal [i.e. not Computer Science level] automation engineers to easily work with creating RTOS tasks and synchronization tools. Basically this could be a simple library of calls that set up task creation and mutex/semaphores with the least amount of work and confusion so that the automation professional can concentrate on the application, not stack size or pthread task attribute structures, etc.
- IO drivers for commercially available industrial IO in HARD REALTIME. Maybe something like Wago/Beckhoff/B&R "slice IO" using Modbus UDP for speed. You could represent the Modbus address space through function calls or shared memory interface to the user application. Some work will have to be done to figure out how to configure the Modbus polling in the driver (Maybe something already exists...) Each system I've worked with does this in a different way. I do like rack based IO in a traditional PLC, but I don't know of anyone who is selling an open PC platform CPU card for their PLC for [relatively] cheap money. Doing custom IO racks that are as nice as the plastic housed PLC IO modules is very expensive.
- Modbus TCP drivers for hardware based HMIs. Even for a system that has a VGA port, some people and applications will still appreciate a commercial HMI with all of its features. In some instances this is hard to beat. This probably can be scheduled in normal linux priority using commonly available libraries/utilities.
- Lastly, but certainly not least, a preconfigured programming environment that you can do uploads and monitor/debug. This application certainly wants to run in windows at least as an option. You have to remember that most automation people are more familiar with "C:\" than "/". The difficult question here is, do you put work into being able to run on two platforms, or do you let the high powered Linux guy do his own thing? This is fairly easy with the programming/compiling, but maybe not so much with things like a preconfigured debugger that is aware of this automation framework since it will be customized to handle specific automation related things. Maybe working in a browser is the way to go here, who knows?
At the same time it almost seems necessary to include some form of graphical ladder logic to get buy-in from people, and maybe to do some sinple logic things that ladder excels at. You have to admit that you can easily.
I do agree with Bill that a hardware platform for an open PLC would help things out, I just would like to see one work with a high power computer that can run Linux based RTOS with ease. I think in some ways the hardware is going to be difficult to overcome and that is the beauty of the slice IO systems, at least for medium sized projects. It definitely won't replace a Brick PLC, but I don't think the problem is in finding a good brick PLC since they can be had for under $100 with free software.
You're preaching to the choir :^)
Most of that has been done and you can get the source. Well, not the translation so your average automation type can do kinematics and HRT easily, but IMHO, once you start dealing with things that need HRT, building the system and writing the software are actually not the hardest part, even my crude little 2 page PLC used memory mapped outside of Linux so it could communicate with an RT process. This is outside the scope of what I am trying to do at the moment, but hardware is a major limitation, not that you can't make hardware to do it, but that the world becomes extremely hard to deal with at even microsecond speeds. The reason garden variety automation gear is easy to use is that it's so slow. Inputs have 15 mSec filtering and outputs are totally inadequate to switch at more than a few kHz. And we live with one scan uncertainty. What you would start to see to generalize HRT stuff would be controlled impedance (Coax) wiring and totem pole outputs. It isn't just a matter of making the software easy to use. Everything becomes more complex and most of it defies simplification because physics get in the way. That said, I'm in complete agreement that a single Linux system could do all the parts, that's why MAT came to be. And I agree that slice I/O is the way to go with a 100+ MIPS processor that can do gHz networks. And you won't find anyone who is more a proponent of doing automation work in C or of building libraries to reuse code. That was my idea for a Linux PLC, to do all the things that a powerful computer with a powerful OS can do.
But, again, most of us stare at a programming tool, doing boring old ladder logic much of the time. And, if and when I get a job, chances are I will have to deal with the whole crappy Windows experience again, just to program PLCs. And spend more time keeping the crud working than programming. And maintaining everything from DOS to Vista. Someone needs to solve that problem.
Writing a Linux Ladder editor as a module in the new Ignition platform from Inductive Automation would work out really well.
A lot of the framework is already in place: A cluster aware web server with database, Java NIO for multi-threading, built in serialization, built in Authentication/alerting/auditing support, Ethernet support, Database support, scripting support (via Python), OPC-UA module for device communication, a built in Java Web Start "Designer" application to house the Ladder editor.
The API exists but isn't yet documented. The platform would be a great fit for such an application - especially as an Open Source project. I can get you in touch with the developers if you're interested in pursuing that route.
Many years ago I used a programming tool from WRB Associates called "Ladders". It allowed a generic ladder program to be developed and you purchased the "drivers" needed to talk to a specific brand of PLC. They had it compatible with the Modicon 384/584, AB PLC-2 and the like. For reasons not related to the capabilities of the program, the package finally died in the mid-80s. That is what I think you are trying to do but today, the complexibility of the task may be more than any one package can handle. Good luck!
One thing I don't see mentioned in this thread that is particularly important is how does a plant maintenance person support these different systems. I am assuming we are talking about a Linux control system that is not necessarily Ladder based. Yes, more and more younger staff have exposure to C and other non-graphical languages but can they figure out what is happening when there is a problem? I sure don't want to be called in at 3 in the morning because the guy can't know why the machine stopped.
Flow chart (with necessary debug and monitoring) can help. Maybe I am just too old but most of the maintenance staff (from the level of skills I have run into at typical plant) "might" be able to follow a ladder diagram but that is still not always the case. They "may" be able to break out the software and look at the flow diagram but I'd have a hard time expecting someone to look at a C++ listing and know what to do.
All the projects that I have been associated with that were considered successful had a common theme. The users had to buy in on the design at least as it related to the HMI and maintenance support functions. Then the equipment had a chance to run well. If they didn't like what they saw or felt that they had no influence on design decisions (and understanding how the program runs is part of that), magically the equipment had all sorts of "issues". Whatever is supplied must be understood and accepted by maintenance or what we provide won't have much success. The major players in Automation have a leg up since more people have been trained on their equipment. Doesn't make their products better, just more accepted. That inertia is tough to overcome.
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
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:
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
> 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.
As I mentioned earlier, I sent a note to AD and CCd Host Engineering. Both sent courteous replies which I'll paraphrase out of courtesy, not having asked if I could publish the replies.
They corrected my impression (from the AD site) that they weren't doing Vista or W7 yet, they are. Host explained that some folks had run DirectSoft on Linux using Wine and that they had never pursued a Linux version because: It's relatively not popular.
My response: Except among millions of Linux users. Neither is DOS, but I run it if that's what the software runs on.
There is not a guaranteed standard version.
My response: Pick a version or make your own and ship it with the product.
My response: I can't see where that is a problem.
They went on to tell me the protocols are not public and Koyo would want an NDA. No surprise there.
Not a word whether they would encourage or discourage or help such a project.
A Mr Jeff Payne Product Manager PLCs, etc.
He said they've talked about a Linux version and he thought it had merit. And perhaps it was time to reopen the discussion with Host about it. He did say he would get back to me. He also said it they did a version it would be with Host and he'd leave it up to them if they would involve the community.
Of course, if they did come up with a Linux version, it would move them to the top of My preferred vendor list, free or not.
But the response so far doesn't encourage a community owned version.
I should CC: Koyo and see what they say. It would be their IP.
In reply to curt wuollet: I think you will find that Automation Direct (and Koyo) have a contract with Host Engineering for programming software, and for some hardware designs. The relationship will go both ways, so AD can't afford to antagonise Host Engineering (HE), and HE really has no incentive to make their position redundant by providing you with information on how to write your own PLC.
I am not quite sure what the actual business relationship between Koyo and AD is - whether AD is a subsidiary of Koyo, or whether they are a distributor. AD's newest PLCs (Click and Productivity) aren't listed on Koyo's own web site. The AD brand only covers certain countries, with other countries have different distribution channels. I have to wonder what is going on there. You might have better luck contacting Koyo directly.
As for a Linux version of the software from Host Engineering, I doubt they would be interested. It would probably be very difficult for them to make an existing MS Windows program run on any other OS. Unix and C (and C++) were joined at the hip from birth, and unix has very consistent designed principles throughout. Porting a typical unix/BSD/Linux program to MS Windows usually isn't too hard (provided you stick to GCC). Going the other way however is usually really difficult. MS Windows is a rag bag of ideas copied from VMS, CP/M and Unix all mixed together. It doesn't have any consistent design principles, so making an MS Windows program "fit" anywhere else is usually almost impossible. Even if you are using something like Mono, it is almost always a port with a good deal of effort.
What the above all means is that if you can get the AD software to work satisfactorily on WINE, then all find an dandy. However, I doubt that HE will think the economics of coming out with an actual native Linux version are worth while. To get what you want will I think require you to write it, with or without Koyo's cooperation.
Electronics with microsecond resolution are certainly doable, in fact, outside automation even trivial electronics operate much faster. But because you can't just casually wire things together and expect them to work at high kHz or Mhz speeds, PLCs are _deliberately_ held to speeds where you can. And sensors, etc, take this into account as well. My crude original Linux PLC with a commodity DIO card would work far above the speeds you need. But not with 10 feet of #16 run through a wiring trough with the ground maybe in another trough. And if it doesn't work that way, the average automation guy will tell you it doesn't work. That's why "high speed" stuff is treated specially and not widely produced. Getting signals 10 feet at mHz speeds is non-trivial. Of course, it's doable, but not with common wiring practices. I can send you the code and the gerbers for the level translators, add a PC and a DIO48 card and you have the timing you need. But keep your scope handy and look into line termination and back matching.
I quite agree, and I did forward the inquiry and responses to Koyo. And it's certainly not above common courtesy to ask politely before you RE someone's stuff. You might just catch the right person or the right time or mood. And there are very good business reasons to do a Linux product when you are in a market with so little differentiation. There will be a first commercial Linux toolset, I would like to accelerate that timeline a little. After all, you would be hard put to hire an embedded engineer that doesn't know all about Linux and I'll bet at least one of the three has application people that could do it. Right now, they could hire me and I'd do it, we'd have to talk about licensing, but I still program what the customer wants, within reason. I spent hours last night wrestling with XP to get a stable environment to run their free demo version. I have not missed the Windows mess at all. But that's another story. I'll putz with it some more once I regain some patience.
In reply to curt wuollet: I agree that it probably wouldn't hurt to ask. So far though, all they know about you is that you are interested in their PLCs. It might not get anyone's attention there.
If you contact them again later and tell them that you are already compiling/decompiling programs and uploading/downloading them, then that is something that is more likely to get their attention. They'll know at that point that you can go ahead with or without them.
Ultimately, it would be to Koyo's advantage (although Host Engineering might perhaps feel differently about it) for you to succeed. At this point however, they don't know if you *can* do it or if anything will come of it. Having something which actually works (even in a limited fashion) answers those questions.
Have a look at Proview developed by SSAB. It is a complete automation system running on Linux on standard PC hardware. For IO connection it supports for example Profibus and Modbus. It includes editors for PLC code in grafcet and fbd as well as inline C code blocks. There is also a complete HMI part in the package. A typical automation project can be divided in process nodes running PLC code (= compiled in to C code) and operator nodes for the HMI. Take a look at www.proview.se