Hi All

I've been working with a variety of projects lately and diagnosing problems with the usual tools, which vary from pretty good to abysmal. As I've been doing this, it occurs to me that all the action occurs or can occur over a serial link in an interactive environment. As such, it should be possible to reverse engineer the protocols and datagrams and build applications that do the same things with OSS tools. This would enable folks to use the platform of their choice and further end the need to have several specific OS platforms to run specific tools. It would also have the advantage that tools would not conflict and could work together better. Or at least not replace or overwrite each others libraries, grab each others resources, etc. One could also continue using these tools as long as desired rather than being funneled through what is most profitable for the PLC vendor. I will state up front that my interest is, predictably, to work on Linux full time rather than the switching that I have to do from Linux to W2k to W98 to W95 to DOS, etc. But even without including Linux, this would be of great benefit to all who have to work on several ages and brands and operating systems in the course of performing their job functions. It can be very time consuming and non-productive to have to maintain all these seperate environments especially those declared obsolete, not supported, and in fact strongly discouraged even though they are clearly needed and no cost effective options are offered. Having to support at least half a dozen vendors
and old to new is simply and inarguably a nightmare in my experience. Could a community do better? What would be the legal implications? How about an RSLogix clone that produces object or intermediate code for several types of PLC? Or "place you favorite tool here"? I'm interested in opinions on the problem and the feasibility of this solution.

Regards

cww

 

In the pre DMCA age, I would have thought you could just reverse engineer the protocols, but these days when it's potentially illegal to make printer cartridges for a Brand X injet, who knows? (IANAL, that's why I produce stuff that works.)

 

Curt,

You could try to reverse engineer RSLogix but it will be alot harder than using a serial monitor. There are alot of quirks in the hardware of the SLCs and PLCs and ControlLogix. The PLC would be the easiest since the compiler is built into the hardware. You won't get all the little tricks that make it all work. I know because I designed and created alot of the RSLogix software. Your idea on a independent platform for creating control is noble. I have had an idea for a generic ladder editor that can compile to a neutral format for use anywhere. The one thing I don't like about your comments is that your so gun ho on Linux and despise Microsoft. If you want to make real money in this world for client applications they will be running on Microsoft. Embedded controllers, servers, etc Linux is fine. Why don't you work on a embedded Linux PLC with a web service interface. I would be interested in helping build a client windows app for that. Good luck.

 

Well, there is that, But a community approach and public ownership would help. Not only is it bad policy to sue your customers or subject them to the best legislation money can buy (DMCA), it's rather difficult and expensive to try a reverse class action. If a competitor were to do this the result would be immediate and vigorous. If your customer base does this, more caution is indicated. And the DMCA is one slug of corruption that could certainly use a little constitutional review.

Regards

cww

 

You mentioned one goal as being supporting older PLCs which vendors are no longer actively developing. The Siemens S5 has a very large installed base, and it is fairly well understood. The binary codes for all the instructions are documented in the Siemens manuals. The protocols (AS511, RK512, 3964) are either documented, or have been reverse engineered already. These factors would make targetting this PLC series much more of a straight forward software project rather than a reverse engineering project.

Making software that is better designed than the Siemens original would not be so difficult a task either. Anyone familiar with Step-5 knows that improving upon it is not a very high bar to cross.

You might also consider writing a soft logic implementation of an S5 to run on a PC to go with the programming software. People may wish to use the soft logic system to replace obsolete hardware without having to re-write the original PLC program. Separating the software from the hardware would allow a system like this to be supported indefinitely.

 

Hi Tom

This isn't a project... yet. And money doesn't really enter into the picture. It would be worth doing to use software that doesn't suck. The problem being solved, as I see it, is bound inextricably into the whole Windows mess and the need to make money with software. The software development is adversely affected by the version churn and the forced obsolecence cycle which are driven by the use of a gamer driven OS for professional use. And selling only compiled shrinkwrap versions is a major part of the reason that many folks have to maintain several complete closed software environments of which only one or two are still supported and one, if you're lucky, is still supported by both the OS vendor and your tools vendor. That is simply the nature of the beast when everything is profit driven. Nothing wrong with that I guess, except the chaos it visits on those poor souls that have to maintain
these wonders in the long term. The implicit message is "Get rid of all that old junk and buy all new stuff and your problems will be over"

Unfortunately that is a far less than insightful perception of how the customer side of business works. People make investments in equipment which may have an extraordinarily long life. And they are orphaned in the controller area, sometimes in an amazingly short time. And the tools to maintain and repair systems are laughingly transient, dead with the next release of Windows. It amazes me that this model succeeds at all but people are used to it and they have a very short collective memory.

We, for the most part, manipulate very simple objects in fairly common ways. Ladder logic programming hasn't changed a great deal in the time I've been around. A tool that was good 10 years ago should be just as good today. Or would, if it hadn't been deprecated, obsoleted, and could be made to run on something currently available. That is the way one should build tools for professionals. I have some insight from the general computing world. I craft software in that world with the same set of tools I have been using for decades, because C is still C and
nothing more current offers any substantial benefit. The OS versions come and go but miraculously, that doesn't mean I need to buy a new set of tools because it is important to a large group of professionals that the tools continue working. And I can write software for nearly anything and any platform with the same set of tools. That is how professional tools are built. Anything less should make busy professionals angry.

Back in the PLC world. Most people use at least one package that's obsolete. Does it's replacement do things much differently? Usually, not. Does it deliver much better value? Umm...no. Does it pay for itself in productivity gains? Not very often. But hey, it will run on the new OS that came on my new machine. Said OS is seldom a Godsend either, being pretty much the same and doing the same things as the old one, at least as far as our work is concerned.

In one case the important thing is the money. In the second case the important thing is the users and the tools. See the contrast? I would like tools that are built to last and can be brought forward with the change in platforms. That can not be done with the present model as
each layer introduces churn to make money. A community effort with OSS can, and in fact almost certainly will, do this more or less by it's nature. That would make life much easier for the people who build solutions, the people who buy solutions and the people who maintain solutions. And I could use the same tool across brands and run on
whichever platform I have handy.

Regards

cww

 

Hi Michael

Good thoughts. IMHO writing something more pleasant and useful than Step 7 wouldn't be rocket science either. Now, something more complex and generally busy would be a challange. It's kinda like that obfusticated C contest they have. You've gotta admire some of the folks that write these masterpieces. But why? I suppose writing for "classic" hardware would be less likely to get you an international incident. But really useful would be a tool that worked for both old and new. Nobody tries very hard to support their old stuff, no money in it. That's the big flaw in the current model. You can't do it unless it makes piles of money. But there are other perfectly valid reasons for doing things once you remove that stricture.

Regards

cww

 

Step 7 is a thing of beauty -- you should try playing with an old Step 5 system sometime.

I have one that runs only under DOS, and appears to be run under a CP/M emulator -- what a mess!

Mark

 

Curt,

I see the point you make and understand it. Software, software OS's, tools, and hardware are on a very fast evolution track. What has been happening is that change is quick and things get obsoleted. (Even if they still work) The good news is things are slowing down. The Operating systems will last longer and there won't be many versions of software coming out. Linux has made great changes also. In fact, you will see Linux on alot of hardware in future Factory Floor Controllers. Software will be easier to create and will be more stable from the fact that the Developer has better tools that have matured. There is no future in writing tools for old hardware. RSlogix 5/500 have been in maintenance for 5 years with all work being done in China. There won't be anymore changes affecting you and having to upgrade to new tools. The ControlLogix is still being worked on but is also stable and will not change greatly. Even when Longhorn comes out nothing new will happen. So to summarize I do not think it is feasable to write an alternative to RSLogix for Linux or any other OS. I see that you were spearheading a Linux PLC. That is a good place for your energy.

Tom

 

I'd like to see a PLC with dual processors. The 1st one would be the controller (perhaps with embeded linux) something small robust and fast, this processor would do all the controlling. The second processor housed in a seperate module would be just a small PC - with some RAM and a HDD or Compact flash memeory system. It's role would be as a server and data historian. Things i'd like to see is Direct memory access to the PLC; a Database (SQLlite, MySql, firebird etc.) Apache and tomcat, smtp (for alarms, daily reports etc.) The PC-Processor could be build/configured by the user, and many vendors cold build these. One could run something like www.pvbrowser.org on the browser for process control, and a PHP web page for supervisors to view. I know a system like this can be built with a PC "connected" to the PLC with something like Modbus. AB as a system like this in their ControlLogix Series, but it's way to expensive. OSS offers many cost and reliability benefits to small and medium business , I would like to see the same for small and medium manufactures.

 

Actually, your largest challenge is that tools like RSLinx and RSLogix 500 hide an incrediable amount of "if-then-else" based not only on the PLC model but the firmware level! It is no "accident" that the first request RSLinx sends to a PLC is a query of the model info, as this directs future communications.

So your tool would have to start as "this works with AB SLC5/04 Series B - but not A or C". Overtime you'd create a better tool, but you won't have an easy path. Regardless of WHY one believes Rockwell doesn't publish the details of programming commands, not publishing allows the details to change 'as desired'.

I "just" deal with simple data access (DF1, CSP, Ethernet/IP etc) and the variation between PLC is amazing.

Best Regards
- LynnL

 

Beauty, they say, is in the eye of the beholder. I suppose it's in what you are accustomed to using to accomplish serious work. When I use it, I work more with Step 7 than with the code.

Regards

cww

 

Hi Tom

Yes MAT/PLC is a good thing. But I need to do more. The stuff I use every day still sucks and I don't have that many years left.

Regards

cww

 

While you could do this easily enough. Why? The small PC can handle the whole ball game easily as even a small PC these days might be 100 MIPS. That's a lot of HP if you keep the bloat down to anything like reasonable levels. A modular OS running only what you need would be fine with that kind of resources. I can see dividing the functions if you know the HMI/SCADA side is going to crash regularly, e.g. Windows, but even there, by running the graphical side as a low priority process on a RT scheduler people have been getting by. It does seem that you would
eventually have to boot if you wanted to know what was going on. But with expected uptime of years on both sides with Linux on embedded class hardware (no hdd,etc.) the ability to share memory and coordinate would make for a stronger product and the programming would be simpler. In a year or so it should be possible to run PLC class applications without really special programming. The embedded folks are already confident in this kind of reliability and the good stuff is going into the mainstream kernel. There is a lot of muscle behind this push with telecoms and other high rel fans finally seeing a light at the end of the MS tunnel.

Regards

cww

 

On March 4, 2005, Tom wrote:
<clip>
> Software, software OS's, tools, and hardware are on a very fast
> evolution track. What has been happening is that change is
> quick and things get obsoleted. (Even if they still work) The
> good news is things are slowing down. <

I am not sure what you base this on. I don't see any sign that things are slowing down. You appear to be mistaking a temporary period of stability for a permanent plateau. If anything, we are at the end of a period of stability and the major changes coming up in the near future are at least as great as those which have occured in the past.

> The Operating systems will last longer and there won't be many versions
> of software coming out. <

Why would this be so? The revenue model of the proprietary software industry won't support what you say. The software market is saturated. New versions obsoleting older ones are how these companies make money selling software.

> Linux has made great changes also. In fact, you will see
> Linux on alot of hardware in future Factory Floor Controllers. <

Linux is also being found for more in the office as well. It is perhaps a sign of the times that this seems to be making an impact even in an industry as backwards as our own. A few weeks ago I had a meeting with a vendor from a
company for some hardware I am specifying for a new line. He mentioned that their programming software is written to be portable, and that it will run on Linux. I'm not sure if he means that they currently distribute a Linux version, or if it is just something they have tried out internally. However, he brought the point up; it wasn't something that I asked about. Oh - and they give away their software for free. They figure that since their software isn't any good without their hardware, they would be wasting time and money trying to track software licenses.

> Software will be easier to create and will be more stable from the fact
> that the Developer has better tools that have matured. <

Unfortunately, people have been saying this since at least the 1960s. I haven't seen any sign of it actually happening yet. The development tools get better, but the projects get bigger. If anything, the quality of new software seems to be decaying.

> There is no future in writing tools for old hardware. RSlogix 5/500 have
> been in maintenance for 5 years with all work being done in China. There
> won't be anymore changes affecting you and having to upgrade to new tools.
<clip>

I believe that Mr. Wuollet's point *was* that there was no additional development being done. I ams sure that most of us have software that we need to use to support existing production equipment, and this software won't run on a computer that we can buy today.

> Even when Longhorn comes out nothing new will! happen. <

If nothing new will happen, it is only because Windows "Longhorn" has so far been a complete fiasco. "Longhorn" is now years late, and Microsoft has been spending the past year pitching new features over the side in an attempt to simply get a product out the door and fill an upcoming hole in their revenue stream. What eventually ships as "Longhorn" may end up as just being "XP+", but that doesn't mean that Microsoft will give up completely on their plans. These changes will just be pushed out into the next release.

The "new" WIndows was supposed to involve: 1) A new file system. 2) A new graphics interface. 3) A new GUI. 4) A new API. In other words, this was supposed to be as big of a change as the transition from DOS to Windows NT and
compatability with older WIndows software was to be secondary to addressing some of the worst long standing fundamental design problems in Windows. At the moment, these plans have been put on hold, but they haven't been
abandoned.

On another note, perhaps you haven't noticed, but Windows has been lagging all the other major operating systems in adopting 64 bits. It is something that Microsoft will have to deal with though. Everyone else has found that changing from 32 bits to 64 bits isn't just a matter of re-compiling the OS and applications. Word size assumptions are built into many programs in non-obvious ways. If you try to run 32 bit binaries on a combined 32/64 bit system, you have lots of potential for library conflicts. Drivers are also especially a big problem. If the vendor isn't interested in redeveloping old drivers, you are stuck.

Given the above, I think it is therefore a bit presumptuous to assume that we have reached some form of computing perfection, and that all future changes will be just minor improvements on what already exists.

> So to summarize I do not think it is feasable to write an alternative to
> RSLogix for Linux or any other OS. I see that you were spearheading a
> Linux PLC. That is a good place for your energy. <

Why would this have to be an either/or question? Why would it not be possible to clone a widely used PLC as a soft logic system (a "Linux PLC") and write programming software for that? This software could be used for the soft logic system or for the original hardware PLC. The soft logic and programming software would complement each other rather than being mutually exclusive.

 

So the answer is let's write applications for Linux because it is open source and we will always have our Linux around as long as we want and our tools will keep on working forever. Sounds great. I also agree with free software if it is only used to program proprietary hardware. RSLogix, RSView, and RSLinx should be free and the lost revenue should be added to hardware.(just treat it like firmware). No copy protection. Distribute the source so we can all improve it or add to it for the benefit of everyone. The hardware gets more popular and the hardware company makes more money than it could imagine. That idea has floated around but the problem is changing the thinking that has existed in a large corporation. It is akin to eliminating a dictatorship that has been around for 25 years and putting in a democratic system. Lots of lives will be lost and severe pain will have to be felt before change will occur. Rockwell and other Control companies could donate developer time like IBM does to the open source efforts. It would be a nice world but I do not think it will happen in my lifetime. It takes a leader with a vision and lots of guts to make that call and I have not seen a guy like that around here. The other wild card could be another open hardware platform for control that takes out the proprietary hardware vendors.

 

Just getting the customer base to glimpse that all the pain is artificial and could be easily eliminated may well be enough. Things don't have to go this way. Suppose Microsoft released Longhorn and nobody came? No billions of dollars spent on a new wave of products whose only real reason for being revved is the new OS is incompatible. No obsoleting current products to force upgrades. No start over from scratch list of bug fixes. Imagine one set of upgrades for the right reasons, to make the products
better. Once you step out of the mad hamster wheel, life would be better for all involved. It's just one port away. And that other mess could go on careening down the mountain. One port to kernel 2.6 and the next change when there is good reason for the automation market. It will come to pass. The difference between gamers and manufacturers will eventually become a checkbook issue.

Regards

cww