Any Volunteers?

C
Yes, and the important thing is that it _be_ reusable. This would almost require some sort of an IL at the interface that individual compiler/decompiler modules could be written to. So the same front end could be common to PLCs from various sources and the many software PLCs that are popping up. This seems to be the part that's missing from many projects. The online monitoring function could consist of a virtual PLC at the interface with a memory map containing an array of Integers, Floats, Bits, Timer structs, etc. that are common to all targets so that assigning tags or references in the editor would determine where to put the bits read back when online. I think this would be reasonable to deal with for PLCs that simply blast a map back or those that send address and data. The personality module writer could then use either or both depending on how the PLC does things. Just my thoughts as I have little carnal knowledge yet. The only depressing thing is that I will have to find another machine to put Windows on to do research and pay the monopoly for a copy. I don't anticipate any cooperation from my workplace so I'll have to pollute my home. The PLC software is often available in a demo version that will suffice. Hardware requires an investment but I can probably scrounge a Micrologix with a bad input or output. I may have to buy an AD brick as there isn't much around here. We will need some background to get a good idea of what's involved. Intuition is only good to a point.

Regards
cww
 
M

Michael Griffin

In reply to Steve Myres: - You may be thinking of FAMIC. I believe they were selling programming software that converted a grafcet chart into ladder logic for a number of different PLCs (you simply picked your target and it wrote the ladder). I tested an evaluation copy of this in the early 1990s, but did not use it on a real life project.

It supported multiple targets by using only a few basic ladder boolean instructions (contacts and simple coils). You could not access the advanced features in the PLC using this software. It was also strictly "write only" code, in that the generated code was not very readable (this is typical of auto-generated code).
 
C
Not wanting to step on any dialog: RFC

1.) The problem as I see it is that everyone who has done work on Linux ladder editors seems to have integrated it with the other components of a PLC and the model is different than what we need here.

2.) This is regrettable as we have many rather than one and this is a small enough arena that we could really use the concentrated effort and reuse that a good ladder editor would inspire.

3.) It would be far easier to write a PLC or module for a commercial PLC to a finished. documented editor than to always "roll your own" which is exactly where the commercial folks duplicate effort and burn resources. Saving resources would be our advantage. And serving both commercial PLC users and backend developers would move things forward much faster than the status quo.

4.) More people would be interested in this idea so we might achieve critical mass.

Regards
cww
 
M

Michael Griffin

In reply to Jiri Baum - I don't think automatic translation is practical as the various PLCs are too different. This is would be similar in principle to the requests we occassionally see for automatic translators between existing PLC programs. It may be possible, but the return would not be worth the effort. I also believe that it is not what most people would actually want.

The biggest problem is there is no such thing as "standard ladder" except for the simplest "ladder" instructions. The more complex instructions and techniques for one model of PLC may have no eqivalent in a different model. The "standard compiler techniques" you refer to have a simpler task in conventional computer programming in that micro-processors limit themselves to very simple building block instructions. PLCs however, have a great many specialised high level instructions (and "magic" special addresses) that would not translate directly. You would either have to limit yourself to instructions that form the "lowest common denominator", or provide subroutines that can emulate these functions for each type of PLC.

I think it would however be possible to create ladder programming software with "pluggable" editor and utility modules. This would let you have a common "framework" for the programming software, but different editor modules would let you write Omron style programs for Omron PLCs, AD style programs for AD PLCs, etc. The same would apply to cross referencing, symbol editing, etc.

A "pluggable" system should not mean re-implementing the editor from the ground up for each PLC. A set of base classes or functions could provide most of the editing functionality, with additional classes added for features unique to each PLC model. Editor functions such as copy/paste, find, search and replace, file open/save, etc. would be common to all PLC families. However, the pallet of available instructions and the rules for combining them (in ladder format) would be different for each PLC family.

Instruction list could be much simpler as you could limit the functionality to just doing a syntax check at appropriate times. If you wanted to do IL syntax high lighting or editor tab-completion, then again you would need a custom template for each family of PLC. This however wouldn't be any more difficult than that seen in the many existing syntax oriented programming editors.
 
Hello,
Michael Griffin asks:
> In reply to Jiri Baum - Which open source soft logic interpreters/simulators
> are compatible with which existing conventional PLCs?

I think most of the open source soft logic interpreters are to some extent
based on a specific family (or the standard). Not necessarily to the extent
of being compatible, but certainly enough to be similar from the user's point
of view - as you say, just another PLC in the same family - and probably a
good starting point if you wanted to make them compatible.

Two off the top of my head are classicladder and opencontroller; but there are
probably others (I haven't done a search recently).

> I haven't seen any working ones. I have seen several which are based
> on their own architecture, but that is not what I was referring to. Note I
> am referring to something that interprets the instruction list directly,
> not something that compiles it to 'C' source.

As for compiling to C, it's not necessarily what you want in itself, but it is
useful in general - because a program that can compile to C can be made to
compile to other languages, for instance to a proprietary dialect of ladder.

All you then need is to write front-ends and back-ends for various dialects of
ladder, and you have a very useful tool...

Jiri
--
Jiri Baum <[email protected]> http://www.baum.com.au/~jiri
 
M

Michael Griffin

In reply to William Sturm - The following is a bit off topic, but I thought I would address the concerns you raised on other matters. With regards to driver problems, your issue seems to be with proprietary communications protocols. Proprietary protocols are a headache for automation customers regardless of OS used, and I don't believe this was something this project was attempting to address.

With regards to "lack of an IDE" for Linux, I am a bit puzzled by this statement from you as there are a great many available for Linux. A typical "large" distribution will come with several and there are also numerous proprietary IDEs available. In addition, the IDE which most of the computing industry has standardised on (Eclipse) is most certainly available for Linux. You will find that many professional programmers who work on very large or complex projects prefer not to use an IDE, but this true regardless of operating system.

With regards to what happens to a file system on power loss, this is what a journaling file system is for. Some of the older Linux distributions required you to choose if you wanted a journaling file system when you installed it, but journalling is now the default install on most. Journalling file systems include ext3, XFS, JFS, Reiser, etc. The main non-journalling file system was ext2. Each file system has its pros and cons, and which is best depends upon your particular application. The reason why journaling was not the default in the past was because it inherently exacts a performance penalty for each write operation which most people in server applications were not willing to pay. Changing hardware and the increased use of Linux for non-server applications means the trade offs are a bit different these days, so journalling has become the default for most. The points regarding journalling are not unique to Linux and apply regardless of OS.

A common file system technique for embedded applications would be to mount the drive the OS boots and runs from "read only" and put the temporary (scratch) files into a RAM drive. This protects the main file system and is also more practical if you want to use a flash drive. If you need to be able to write data, then you can either temporarily make the drive "read/write", or you can have a separate data drive which is read/write. I have seen this technique used for Linux and also for QNX. Because the boot drive is being used read-only this can done using low cost flash cards instead of the much more expensive IDE flash drives. I don't know if this technique is possible with MS-Windows.

As for the evaluation you are planning to do on "MS-Windows XP Embedded", I would suggest that you also look into how much longer Microsoft intends to support it and just what the "support" will consist of. The "embedded" version is just a cut down version of the normal desk-top install, and MS-Windows XP is being replaced early next year with MS-Windows Vista. MS-Vista is supposed to be a significant change (although not as significant as they had originally planned) and a lot of existing software is not expected to run. Drivers are expected to be a particular problem. You will particularly want to look into the implications of their policy regarding "signed" drivers.
 
C
Hi Bill,

>Funny, my Linux experience has been quite the opposite of yours. I spent months trying to get Linux working on an embedded PC project before I threw in the towel and switched back to Windows. In the Windows environment, I had a program running in a few weeks.
>

Part of that has to be what environment you are used to. And also what level you are comfortable developing at. Most Windows folks are used to event driven programming with a lot of the structure pre-ordained and pre-built because that's how you build Windows programs. And that has advantages in that arena, not the least of which is consistancy. They work at a fairly high level often interacting with whole subsystems. You can feel free to correct me if I'm wrong there, I've never developed for Windows but have inevitably encountered the art from time to time. It is quite different from what I've done which is not event driven and almost totally concerned with operating on data and manipulating hardware. Even here, I make use of libraries and subsystems but they tend to be at a much lower level. For example, the *nix idea of serial port control is exquisite in it's detail at one level, but also lets you pretty much default everything and write to a file for common tasks.

>The problems in Linux were mostly related to the lack of industrial hardware support. The drivers for Galil and A-B were either out of date or non-existant. Also, the lack of an IDE made it harder, in my opinion. Recovering from power loss situations were also a concern. I let my son use Linux and I had to boot from a CD and run fsck at least once a week.
>

The support for non-mainstream hardware is an issue. It's a prime example of the "chicken or the egg" problem. But it's getting better rapidly because of the huge numbers of embedded Linux projects. I've had to write or adapt drivers for even simple hardware but that's in the past. For example, I've been mulling over doiug more sophisticated machine vision projects. The specialized frame grabbers and libraries were a Windows only game until very recently. Now I have dialog with vendors where hardware cost is more of a consideration than Linux support. Of course, some are binary only drivers, which doesn't help much, but the prospects look good for me to be able to do a system unbeatable on per seat or per camera costs because I'm only buying hardware. I'm not sure how your son corrupted fliesystems on a regular basis. Turning the system off or losing power will still have risks. I've only had to fsck or even shut down when I asked the system to tight loop indefinitely or created segfaults or the like. But even here, the fairly new journaled filesystems mean I very seldom twiddle my thumbs through an 90 Gbyte fsck. Of course the embedded versions still prefer the smaller, lighter, components of yore.

>I am currently using a non-embedded XP setup, which may run headless. I now have my choice of Visual Basic, Visual C++, or .NET and many third party and/or vendor supported drivers. I am hoping to switch to XP Embedded, but I need to evaluate the cost/benefit ratio.
>
They have become more attuned to the needs of embedded developers and non-graphical applications. I suspect that you have Linux to thank there as well. Even if you never use it, Linux has really freshened the embedded landscape. With wins at Motorola, Nokia, and lots of other tele and network vendors, Linux has succeeded in making everyone else a lot more user oriented and cost concious. But, ultimately, in embedded, no cost per copy is going to beat out royalties and licenses simply because after development those costs directly erode profit. Our low volume arena is more mixed. I can see where developing with what you familiar with is less costly for a one off, or even for X number of systems. But at some point, If I compete with you and develope with what I'm familiar with, I can probably sell each unit for less. Or I can sell the hardware and give the software away. Or I can give the customer all the software and sell services consulting on how to modifiy it to exactly suit. Best of all, they aren't always buying something I make no money on. I'd like the revenue to stay here rather than accrue to Redmond and their partners. There are a lot of trade offs and not all of them are positive, but not paying for canned software and dealing with their upgrades and business model seems like a plus. None of that is any good for me. Instead I front for them and take the abuse.

>I know that many of the programs that run on Windows have their issues, but I don't see how switching to Linux will solve that.
>

Running on Linux is only part of the solution. Having software that you control and can understand or even fix is the large part. The low barrier for entry and freely distributable tools and extreme flexibility don't matter in all situations, but in an all-custom arena they are a natural fit.
 
C
Really, what I'm hearing is the same idea with the interface being pushed back or forth a bit. An editor module that is personalized to each PLC or reasonable grouping to account for the differences in ladder might even be needed. One thinks of Siemens with their flip-flops for storage and the interesting differences in timers, etc. But I wonder how great the differences are at the IL or ML level. And this is actually merging FB and ladder. I for one, would be quite content to use AB semantics to program a Siemens PLC, but they do have some frequently used dodads that are quite unlike anyone elses. And I would not like to use Siemens semantics to program all PLCs, I'm not that fond of them natively. But would it be a deal killer if we didn't support every oddball construct? If I could accomplish the same thing in a different way? Many Siemens programs, and I'm picking on them only because they are the most different programs I'm familiar with, have chunks of stuff in IL embedded that don't translate to ladder anyway.

Could we have a common body of RLL and support the eccentricities that same way? Or alternatively, could the unique items be handled by having the editor simply call up a different symbol set depending on the target? These symbols would then compile to the proper stuff for the target PLC, That way the editor could do the same things changing only the objects. I'm not saying this is possible or good, just throwing ideas around. This would actually be using the same framework and using the same editor. A new PLC would then require making up a symbol set of it's instructions and each symbol could carry the resultant IL or something that the post processor would translate. Could that work? I kinda like that idea. Or is that the coffee talking?

Regards

cww
 
S
But if your solution for a given brand isn't comprehensive, how do you deal with uploaded programs? Or do we have to say that's an unavoidable cost of writing a multi-PLC editor?

Also, in an earlier post, you talked about AB breaking this project by changing protocols so our driver would no longer work. Don't forget
there's a huge installed base out there so unless they can convince their customers to flash the majority of installed PLC's to the new
"non-Automation-List" protocol, there's limited incentive for them to do that. And even if they do we can still work on the existing ones, and
specify someone else's for new work.
--
Steve Myres, PE
Automation Solutions
(480) 813-1145
 
Hello, In reply to Michael Griffin - I'm sure having an automatic translation would be practical, but I guess it's probably not worth writing just as a translation system.

However, if it's part of an editor, it may be more realistic: instead of using a particular PLC's language, it would use its own, with translation to (and from) each dialect. Translation between dialects would then be "for free".

Perhaps PLCs have specialised high-level instructions, but then so do many CPUs - before RISC came on the scene, assembly was intended for use by humans and had moderately complex instructions. Some CPUs, as the Intel '86 line, have multiple layers of backwards compatibility and a non-orthogonal design. PLCs aren't that special. Similarly, magic special addresses are easily handled, probably better by computers than by humans. There's nothing intrinsically difficult - it's just a "simple matter of programming", as they say (which is to say: easy, but tedious).

However, I'm not writing any of that any time soon, so I guess I can't complain if nobody else does either...

Jiri Jiri Baum <[email protected]> http://www.baum.com.au/~jiri
 
M

Michael Griffin

<p>In reply to Curt Wuollet - I had a look at the "Open Controller" and "Classic Ladder" projects. I have scribbled down some notes below which give a general outline of the state of each project. This is intended to discuss whether either of these existing projects meets or is close to your stated goal.

<p>Both of these include a ladder editor and a soft logic system. In the case of Open Controller these are two separate executables, while with Classic Ladder they are normally combined into one.

<p>I didn't run Open Controller because I didn't have wxWidgets installed and I didn't want to bother installing it. I did however run Classic Ladder. I was able to load and run the sample programs, but I wasn't able to figure out how to do any editing.

<p>I have a short comparison of some major points about the source code OpenController and Classic Ladder below. I don't know if this table will come out very well on everyone's e-mail client.

<pre> OpenController Classic Ladder
Current Version: 1.1.0 0.7.60
Release Date: March of 2003 27-May-2006
Language: C++ C
GUI Toolkit: wxWidgets GTK+
Code size (editor): 16,949 N/A
Code size (PLC): 8,312 N/A
Code Size (total): 25,261 12,056
License: LGPL + Other LGPL
</pre>
<p>In the above, "code" size refers to the number of lines in the '.c' or '.cpp' source files, including comments and blank lines. It is worth noting that for Open Controller, the editor is approximately twice the size of the soft logic system. It is also worth noting that Open Controller appears to be twice the size of Classic Ladder.

<p>There does not appear to be any design notes or documentation for either program, and the comments appear to be rather sparse.

<p>The Open Controller project has some general notes that it is licensed under the LGPL. However, most of the files do not have any license information in them, and some are third party files released under a different license. This code could be messy to work with from a licensing stand point unless this is cleared up.

<p>Classic Ladder is released under the LGPL. This was clearly stated in all the files I examined. This code appears to be straight forward from a licensing standpoint.

<p>My preliminary conclusions are:

<p>A) Neither of these existing projects in their current state appears to meet your project targets.

<p>B) Neither appears to have any software design documents or notes, unless these can be obtained from the original authors. Both also appear to be sparsely commented. To make use of either of these as a starting point would require a preliminary reverse engineering effort.

<p>C) Both are supposedly licensed under the LGPL, although the licensing situation is unclear for OpenController. This means code could be re-used from at least the Classic Ladder project if it proves useful.

<p>D) If written in C or C++ and using wxWidgets or GTK+, an editor could reasonably be expected to be a minimum of 8,000 to 15,000 lines. Alternative development techniques could be considered to reduce the development effort.

<p>E) Neither of these existing projects were written to be international (supporting multiple languages). For example, error messages are hard coded in English in "printf" statements. The new project could allow the later support of other languages through standard techniques.
 
M

Michael Griffin

In reply to Curt Wuollet - The first question to be answered is whether the programming software should be capable of eventually supporting more than one family or architecture of PLC, even if there is only one target initially. That wasn't part of the original discussion, but it seems a reasonable goal.

If a PLC is supported at all however, it would be important to support every instruction and addressing mode. If not, then people would still need the OEM software anyway to deal with programs that haved the "unsupported" instruction in them. If then you still need the OEM software, then why bother with the "free" one?

There are several functional aspects to be addressed. These include (in no particular order): program editing, utilities (cross reference, search, symbol entry, etc.), file storage, program download/upload to the PLC, control and monitoring of the PLC status, hardware configuration, on-line monitoring of the PLC program and data, and user preferences for the programming software itself.

------------------------------------

A) IL Program Editing: Different PLC families have different instruction list (IL). Supporting the display and entry of multiple families of IL seems fairly straight forward, as we are dealing with just text. IL editors that I have used do not enforce editing rules other than each individual instruction must be syntactically correct. Generally, you can enter any sequence of instructions you wish provided that each is syntactically correct. The syntax check is performed at some suitable time during the editing process.

This is little different from syntax oriented text editors which have been available for many years for conventional computer programming languages. Likely some form of replaceable syntax template system could be used.

------------------------------------

B) Ladder Program Editing: Ladder editing is more difficult because the syntax is more strict. There are two aspects to this. One is converting existing IL to valid ladder, and the other is allowing the user to directly enter valid ladder (which is eventually stored as IL).

Not every possible sequence of IL has a ladder representation. Also, for at least some PLCs (e.g. Siemens S5, Siemens S7-300/400) not every IL instruction has an equivalent ladder representation (or at least the OEM doesn't define a symbol for it). This means that handling conversion of "invalid" ladder is typically easy - you could just default to displaying that rung as IL.

However, deciding what is "valid" ladder is not so straight forward. Generally, typical existing programming software will recognise certain patterns as being "valid" ladder. The rules for these patterns vary betwen PLC families, and also between different programming software for the same PLC family.

For example, there are several different programming packages available for the Siemens S5 family (and Siemens also sold third party software under their own label). The more complex ladder "instructions" (e.g. timers) would actually be constructed from several IL instructions. How these complex ladder instructions were constructed was to some extent arbitrary. What one package might recognise as a valid rung of ladder therefore might not be recognised by another. The meaning of the IL instructions which make up a ladder instruction may have to be derived from the context within which they occur.

What this means is that for ladder, the representation depends upon a complex set of rules that will not be the same for different PLC families. There would also have to be a conscious effort if it were desired to ensure the valid IL "ladder" patterns are the same as people are used to for that PLC.

To accommodate this would likely require separate ladder editor logic for each family of PLC. This could mean either a separate version of the programming package for each PLC family, or some sort of "plug-in" architecture (similar to that in a web browser), or some form of embedded scripting (where the appropriate editing scripts are loaded as required).

------------------------------------

C) Program download/upload to the PLC and Control, Monitoring of the PLC Status, and Hardware Configuration:

The methods required for these will be very dependent upon the particular type of PLC. These could require a combination of a communications driver collection, and some sort of embedded scripting. Alternatively, a set of separate program(s) could be used for these hardware dependent functions, where a new program is written for each application. These functions don't have a lot of interaction with the editing process, so it may be practical to simply separate them into a different program. However, it would be nice to not have to write a completely new program for each type of PLC.

This part also has to address the question of formatting or compiling the program source code into the format required by the PLC. In cases where the "compiler" (whatever that may consist of) resides in the PLC, that may simply require checking and tokenising the source code. In cases where the "compiler" resides in the programming PC, things could be a lot more difficult, possibly prohibitively so. Reverse engineering a compiler (and any associated libraries) is not a trivial task.

Another problem to address is PLCs which have upgradeable firmware. For some hardware lines, the firmware may be upgraded by the OEM programming software when you download a PLC program if you are using a newer version of the software. It may be possible to deal with this by having a separate firmware upgrade utility if the firmware files are available separately from the PLC OEM.

------------------------------------

D) Utilities: Utilities would include things like cross referencing, searching, symbol entry, printing, etc. Again, these are affected by the details of the particular PLC family. For example, cross referencing would be affected by the form of addressing used by that PLC. Perhaps some sort of template could accommodate most of the differences, while the print system would have to rely on the ladder editor module to produce printable ladder images.

------------------------------------

E) File Storage: Some sort of file format will have to be defined for the program, symbols, and comments. The format should be designed to be flexible and extensible so that if features are added later we don't end up with incompatible file format versions. I don't think it is practical to think up everything we would ever need in advance, so it is probably better to have a format to which features can be added without rendering the file incompatible with older versions of the programming software. It would probably also be a good idea to use file parsing routines which are as off the shelf as possible.

------------------------------------

F) On-line Monitoring of the PLC Program and Data: This is where the PLC hardware meets the editor, and so may be the most likely place where problems would be encountered in keeping the editor hardware independent.

------------------------------------

So to summarise:

1) Supporting multiple PLCs with IL looks straight forward.

2) Supporting multiple PLCs with ladder is possible, but requires the software be designed for it in the first place. That doesn't necessarily mean putting in multiple architecture support right from the beginning, but the software design should be laid out so that adding it doesn't mean a complete new software design.

3) A PLC should be programmed in its native "language" and syntax (for both IL and ladder), and all features of the PLC CPU should be supported. If you open up a manual from the PLC manufacturer, the instructions in the manual should match what you see on your screen. This doesn't mean the ladder symbols have to be identical, but the instruction parameters should be the same.

4) The previous point *doesn't* mean we need to provide programming software for all the special programmable add-on cards (servo, etc.). Most people don't use them, and it is a reasonable design compromise to not support them. Some PLC OEMs offer different versions of their software, where the low cost version doesn't support at least some special modules, so this is evidently a reasonable compromise.

5) Dealing directly with the PLC hardware for upload/download, configuration, etc. should be handled by a separate program. Different programs can be written for dealing with different PLCs if necessary.

6) The above more or less suggests the project would consist of a single universal program editor plus a separate (but closely associated) non-universal program(s) for dealing with the PLC hardware.

------------------------------------

Some final points are:

i) I suggest the system should be multi-platform, at least to the extent of supporting both Linux and MS-Windows.

ii) I also suggest that ease and speed of development should be a major criteria. This would particularly apply to areas where people would wish to add or improve support for different hardware.

iii) I would suggest that most of the project be GPL licensed. It may be desired to have parts such as communications drivers be LGPL, but that can be a matter of discussion.

iv) Documentation should be considered an import part of the project. This includes both user documentation (how to use the PLC programming software), as well as design documentation (to be used by developers). Since we are targetting existing PLCs, the OEM documentation can explain how the PLC itself works.
 
J

Jeremy Pollard

Good afternoon to all. I am a grey hair (or no hair) in this biz, and have grown up with the IPDS ICOM Taylor Graysoft ASAP etc etc etc . time of automation life.. They didn't survive and couldn't survive on their own.

They HAD to be attached to hardware.. SoftPLC (aka Teledenken Resources) had to develop/license their own brand of PLC in order to be successful.

No where is there any company that has gained a foothold by selling software by itself.

One might argue that ISAgraf is .. but it is more for the embedded market.

Customers don't care about licensing costs, as such. They want to get the job done. Would anyone disagree with that??

Having said all that, IEC-61131 (I was the NA managing director for 6 years for PLCopen) is/was supposed to be that. Well it isn't.. and why not you ask????

Hardware, market share, captive audience, licensing fees, and making money come to mind.

Any 'open-source' (like the Puffin Project that Ken Crater created) project will not be successful in the open and general marketplace for the aforementioned reasons.. plus the cost and effort to HAVE to deal with legacy.

The solution can be viral however. The approach can be like PLCopen.. where we have members - us - and committees that look after the design of the components.

Steering committees develop the strategies, and it is voted on. And the benefactors of the results is us.. and when others see the benefits
(assuming there are some), they might be joining in.

Online stuff .. man that's tough - ask anyone who's developed a driver . but the protocols are mostly public.. for a cost!!

Maybe a good start would be to define an export format, then a pre-compiler for the current hardware programming software (or file format if available)

Then maybe a direct downloadable file for the target PLC and software, and eventually the vendors software can be replaced... maybe ...

All of s/ware is free.. IEC software cannot download to any other hardware than what it is/was designed for. And that is BY design.

Tiny steps .. I would suggest an executive committee and members to begin the execution.. First starting with a mission statement and a target design and time line.

I've worked for a software vendor and consulted for more ... the effort is not insignificant.. who's ready for the commitment?

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

PLCopen North America - [email protected]
www[.]plcopen.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579
 
C

Curt Wuollet

Hi Michael

On June 3, Michael Griffin wrote:
>In reply to Curt Wuollet - The first question to be answered is whether the
>programming software should be capable of eventually supporting more than one
>family or architecture of PLC, even if there is only one target initially.
>That wasn't part of the original discussion, but it seems a reasonable goal.
>

It has always been in my mind and is indeed implicit in the concept of a Reusable ladder editor. Otherwise, I guess micrologix would be reusable because you can program as many AB plcs as you want. I was leaning toward a common subset bas as you mention, you _need_ some of the oddball stuff.

>If a PLC is supported at all however, it would be important to support every
>instruction and addressing mode. If not, then people would still need the OEM
>software anyway to deal with programs that haved the "unsupported" instruction
>in them. If then you still need the OEM software, then why bother with the
>"free" one?
>

Were I not obligated to use some of these PLCs, I wouldn't bother with _them_ at all as some species are definitely more trouble to use than they are worth. And even more so when you are working after the fact. I haven't had a lot of
time to ponder as I'm suddenly and deeply involved in some machine vision work, but the
thought I had about one editor that supports different "instruction objects" or "symbol sets" hasn't fallen flat yet. This entity could contain the symbol for editing display, the
various addresses that the instruction uses, even the code to be generated when compiling. So when you place an instruction, the editor would "know" what blanks need to be filled in. And for online monitoring, the refresher would
know where to look for the bits, all in this instance of the instruction object.

So each instruction could be a struct with the bitmap, the output code, the addresses, etc, etc. and each function would know how to deal with these structs to do their task.

That takes care of the ladder part, but then you have wiggy stuff that embeds IL or huge blind function blocks. It took years to resort to that sort of depravity but those would probably have to be exceptions to the rule. Or perhaps each IL instruction could be a similar struct. I haven't wrapped my head around supporting FBs yet.

>There are several functional aspects to be addressed. These include (in no
>particular order): program editing, utilities (cross reference, search,
>symbol entry, etc.), file storage, program download/upload to the PLC,
>control and monitoring of the PLC status, hardware configuration, on-line
>monitoring of the PLC program and data, and user preferences for the
>programming software itself.
>
> ------------------------------------
>A) IL Program Editing:
>Different PLC families have different instruction list (IL). Supporting the
>display and entry of multiple families of IL seems fairly straight forward,
>as we are dealing with just text. IL editors that I have used do not enforce
>editing rules other than each individual instruction must be syntactically
>correct. Generally, you can enter any sequence of instructions you wish
>provided that each is syntactically correct. The syntax check is performed at
>some suitable time during the editing process.
>
>This is little different from syntax oriented text editors which have been
>available for many years for conventional computer programming languages.
>Likely some form of replaceable syntax template system could be used.
>
> ------------------------------------
>B) Ladder Program Editing:
>Ladder editing is more difficult because the syntax is more strict. There are
>two aspects to this. One is converting existing IL to valid ladder, and the
>other is allowing the user to directly enter valid ladder (which is
>eventually stored as IL).
>
>Not every possible sequence of IL has a ladder representation. Also, for at
>least some PLCs (e.g. Siemens S5, Siemens S7-300/400) not every IL
>instruction has an equivalent ladder representation (or at least the OEM
>doesn't define a symbol for it). This means that handling conversion of
>"invalid" ladder is typically easy - you could just default to displaying
>that rung as IL.
>
>However, deciding what is "valid" ladder is not so straight forward.
>Generally, typical existing programming software will recognise certain
>patterns as being "valid" ladder. The rules for these patterns vary betwen
>PLC families, and also between different programming software for the same
>PLC family.

This is where it would get sticky.

>For example, there are several different programming packages available for
>the Siemens S5 family (and Siemens also sold third party software under their
>own label). The more complex ladder "instructions" (e.g. timers) would
>actually be constructed from several IL instructions. How these complex
>ladder instructions were constructed was to some extent arbitrary. What one
>package might recognise as a valid rung of ladder therefore might not be
>recognised by another. The meaning of the IL instructions which make up a
>ladder instruction may have to be derived from the context within which they
>occur.
>
>What this means is that for ladder, the representation depends upon a complex
>set of rules that will not be the same for different PLC families. There
>would also have to be a conscious effort if it were desired to ensure the
>valid IL "ladder" patterns are the same as people are used to for that PLC.
>
The method above would help here as we could define what a timer cooks down to. And if need be you could have a symbol set for the alternate
tool. Defining these would be contributed work as interest serves because no one else is
likely to have your particular mix of junk to support:^) Now the stuff that is context
sensitive.....

>To accommodate this would likely require separate ladder editor logic for each
>family of PLC. This could mean either a separate version of the programming
>package for each PLC family, or some sort of "plug-in" architecture (similar
>to that in a web browser), or some form of embedded scripting (where the
>appropriate editing scripts are loaded as required).
>

Again where you push the interface.

> ------------------------------------
>C) Program download/upload to the PLC and Control,
>Monitoring of the PLC Status, and Hardware Configuration:
>
>The methods required for these will be very dependent upon the particular type
>of PLC. These could require a combination of a communications driver
>collection, and some sort of embedded scripting. Alternatively, a set of
>separate program(s) could be used for these hardware dependent functions,
>where a new program is written for each application. These functions don't
>have a lot of interaction with the editing process, so it may be practical to
>simply separate them into a different program. However, it would be nice to
>not have to write a completely new program for each type of PLC.
>
>This part also has to address the question of formatting or compiling the
>program source code into the format required by the PLC. In cases where the
>"compiler" (whatever that may consist of) resides in the PLC, that may simply
>require checking and tokenising the source code. In cases where the
>"compiler" resides in the programming PC, things could be a lot more
>difficult, possibly prohibitively so. Reverse engineering a compiler (and any
>associated libraries) is not a trivial task.
>

If the target is machine language, yes it would be ugly. But I suspect some sort of tokens for an interpreter as online edits would be very exciting with hard coded jumps and addressing. Could be completely wrong though, too. It's a job just making educated guesses about what they are doing. I suppose one could dump some ROMs and see what makes sense, if anything.

>Another problem to address is PLCs which have upgradeable firmware. For some
>hardware lines, the firmware may be upgraded by the OEM programming software
>when you download a PLC program if you are using a newer version of the
>software. It may be possible to deal with this by having a separate firmware
>upgrade utility if the firmware files are available separately from the PLC
>OEM.

Perhaps. Like I said, a cooperative vendor would make this a lot easier. A really hostile one could make it rather difficult.

> ------------------------------------
>D) Utilities:
>Utilities would include things like cross referencing, searching, symbol
>entry, printing, etc. Again, these are affected by the details of the
>particular PLC family. For example, cross referencing would be affected by
>the form of addressing used by that PLC. Perhaps some sort of template could
>accommodate most of the differences, while the print system would have to
>rely on the ladder editor module to produce printable ladder images.
>
> ------------------------------------
>E) File Storage:
>Some sort of file format will have to be defined for the program, symbols, and
>comments. The format should be designed to be flexible and extensible so that
>if features are added later we don't end up with incompatible file format
>versions. I don't think it is practical to think up everything we would ever
>need in advance, so it is probably better to have a format to which features
>can be added without rendering the file incompatible with older versions of
>the programming software. It would probably also be a good idea to use file
>parsing routines which are as off the shelf as possible.
>
> ------------------------------------
>F) On-line Monitoring of the PLC Program and Data:
>This is where the PLC hardware meets the editor, and so may be the most likely
>place where problems would be encountered in keeping the editor hardware
>independent.
>
> ------------------------------------
>So to summarise:
>
>1) Supporting multiple PLCs with IL looks straight forward.
>
>2) Supporting multiple PLCs with ladder is possible, but requires the software
>be designed for it in the first place. That doesn't necessarily mean putting
>in multiple architecture support right from the beginning, but the software
>design should be laid out so that adding it doesn't mean a complete new
>software design.
>
>3) A PLC should be programmed in its native "language" and syntax (for both IL
>and ladder), and all features of the PLC CPU should be supported. If you open
>up a manual from the PLC manufacturer, the instructions in the manual should
>match what you see on your screen. This doesn't mean the ladder symbols have
>to be identical, but the instruction parameters should be the same.
>
>4) The previous point *doesn't* mean we need to provide programming software
>for all the special programmable add-on cards (servo, etc.). Most people
>don't use them, and it is a reasonable design compromise to not support them.
>Some PLC OEMs offer different versions of their software, where the low cost
>version doesn't support at least some special modules, so this is evidently a
>reasonable compromise.
>
>5) Dealing directly with the PLC hardware for upload/download, configuration,
>etc. should be handled by a separate program. Different programs can be
>written for dealing with different PLCs if necessary.
>
>6) The above more or less suggests the project would consist of a single
>universal program editor plus a separate (but closely associated)
>non-universal program(s) for dealing with the PLC hardware.
>
> ------------------------------------
>Some final points are:
>
>i) I suggest the system should be multi-platform, at least to the extent of
>supporting both Linux and MS-Windows.
>
>ii) I also suggest that ease and speed of development should be a major
>criteria. This would particularly apply to areas where people would wish to
>add or improve support for different hardware.
>
>iii) I would suggest that most of the project be GPL licensed. It may be
>desired to have parts such as communications drivers be LGPL, but that can be
>a matter of discussion.
>
>iv) Documentation should be considered an import part of the project. This
>includes both user documentation (how to use the PLC programming software),
>as well as design documentation (to be used by developers). Since we are
>targetting existing PLCs, the OEM documentation can explain how the PLC
>itself works.
>

Good points and summary, certainly frames the discussion. I'm on UPS, gotta go.

Regards
cww
 
M

Michael Griffin

In reply to Jeremy Pollard - You have raised a large number of points which are best addressed in turn.

> Customers don't care about licensing costs, as such. They want to get the
> job done. Would anyone disagree with that?? <

I would disagree with this. Customers do care about every penny. Purchase price is however as you said, not everything. The licensing terms for most non-free software is a major headache for maintenance and engineering
departments. Software budgets must be projected and managed, and licences must be tracked. Lose track of where you've installed the software and your company is at risk of getting sued by your supplier. Someone also has to keep
track of key disks and dongles (which can be individually worth more than what the average bank robber nets in a "job"). This is not a productive use of time or skills.

Software piracy is wide spread, for both programming and CAD software. That alone should tell you that there is a major gap between the interests of the suppliers versus that of the users. Compare this to being able to *legally*
just down load the software as and when you need it, and install it on as many computers as you want.

The other point in all this is that every PLC seems to need a different package to program it. Learning to use the new software is usually harder than learning the new PLC. Why not one package that can program many PLCs?

> Having said all that, IEC-61131 (I was the NA managing director for 6 years
> for PLCopen) is/was supposed to be that. Well it isn't.. and why not you
> ask???? Hardware, market share, captive audience, licensing fees, and
> making money come to mind. <

IEC-61131-3 was a nice idea, but as they say the mountain hath groaned and brought forth a mouse. In retrospect, I think the idea was doomed to failure despite the best efforts of the committee members. None of the major suppliers had any incentive to standardise in a manner that would benefit their customers. They will need to be presented with a fait accompli before their attitude will change on this.

> Any 'open-source' (like the Puffin Project that Ken Crater created) project
> will not be successful in the open and general marketplace for the
> aforementioned reasons.. plus the cost and effort to HAVE to deal with
> legacy. <

With all due respect to Mr. Crater, I believe that he registered the copyright on "Puffin", and er, that was about it. Which was probably just as well because I don't think many end users were actually looking for a new and
novel soft logic system at the time. A *different* group of people went and worked on something they called "MAT". It hasn't been a huge success in terms of adoption in industry, but the same could be said for any other soft logic system. This time however we are talking about creating programming software to support hardware that people are already actually using.

> The approach can be like PLCopen.. where we have members - us - and
> committees that look after the design of the components.
> Steering committees develop the strategies, and it is voted on.
> .. I would suggest an executive committee and members to begin
> the execution.. First starting with a mission statement and a target
> design and time line. <

Er, at this point I was more or less just planning to write some proof of concept code and ask people what they thought of it. If everyone else thought it was dumb and someone had a better idea I could always just throw it away and try that instead. I'm not sure what anyone else is doing at this point.

So far I've got a few implementation ideas. I've outlined the general split between the generic editor and the architecture dependent parts in a previous e-mail.

For the editor I have been digging into what can be done with the Mozilla application platform. Activestate based their Komodo IDE for Perl, PHP, Python, Ruby, and Tcl on Mozilla, so this is not a totally new idea. I think a Ladder and IL IDE can be built using XUL, XPCOM, RDF, SVG, and Javascript. I'm hoping to keep the structure separated from the content (text) so that other languages (e.g. french, italian, etc.) are easily supported by just translating a few files. Ladder and IL dialect features should also be separate from the main application structure so that new PLCs can be added by changing a (relatively) few files.

So far I am still just doing research on this. I haven't got any code down yet, although I hope to try out a "hello world" test in a few days. I haven't worked with the Mozilla application platform before, so I have a bit of a
learning curve to overcome. (The Mozilla application platform by the way, has nothing to do with web applications).

For the file storage format, I think symbols, comments, and project information should just go into an OASIS OpenDocument spreadsheet. The actual PLC code should probably go into a separate file, probably XML. The format
has to be kept flexible if it is to support different PLCs.

As for compiling and downloading to specific hardware, I was hoping that someone else might have some good ideas on that. I'm also hoping that some other people are looking into other approaches in case none of this works out.

You might get some adverse comments on your suggestion for meetings and committees, but it's actually a good idea; just not yet. This approach generally works better with a software project when you've actually got something tangible that works and want to bring interested parties together to discuss it. At that point, the discussions are more along the lines of "what do we need to do to get people to accept it?", and "what do we need to do to get companies to endorse it?". Sometimes that means adding or changing a few things, but more often its a matter of convincing the right people and the right organisations to endorse it.

If automation companies and users do accept it, then there will eventually need to be some sort of forum which will bring them together and lets everyone's voice be heard, so that no-one is afraid that they are going to end up with the short end of the stick. A GPL software licence would
definitely help with this, as no-one can use control of the code to dictate terms to anyone else.

I think first though, we have to prove that we can build it and get it working with at least one real PLC before anyone is going to take us seriously.
 
M

Michael Batchelor

I hate jumping in this conversation, partly because we've all been involved in the same discussion for years (http://www.control.com/1026170363/index_html and http://modbus.control.com/dev/1014142129/index_html search for my last name see some of my old comments). And partly because this isn't really a coherent essay I'm trying to write, but more a random collection of thoughts and facts, and I'm a little afraid someone will look at any oversight I may make and jump on it as proof of fallacious thinking. But here goes.

I've been using gcc since 1989 (before it was really useful), and failed miserably to compile my first Linux kernel in 1992. So, I'm not exactly "new" in the open source world.

Way back yonder in the good old days everyone in the old Usenet community used and contributed to the pool of tools in a very egalitarian way. The primary driver was that the "tools" didn't exist in any of the various Unix vendor's distributions, and the tools didn't threaten market share in any of the vendor's systems. The tools were created by the user community, for the user community to fill an unmet need.

Richard Stallman, genius or madman - you take your pick, started changing the way think about these things. His original claim to fame, Emacs, was just another project to fill an unmet need, but then he got into the GNU frame of mind and started the project that, honestly, changed the way software is developed and marketed. The FSF gcc project, and later glibc, has probably made more difference in the software world than anything short of electronics themselves.

However, I'll still stand behind my assertions made in the first link shown above, that what needs to get developed is the "generic" component. Now, I'll agree that this whole thread is about developing that "generic" component. No argument about that from me. But if you stop and think about the good old bootstrapping days you can see the chicken and the egg problem a little more clearly.

When gcc was a gleam in a small group of programmers eye, the Sparcs it was supposed to run on were essentially a commodity item in the MIT lab they had available to them. As things progressed, and gcc became available for the x86 architecture, things took off because there was "real" commodity hardware available to the general masses, and SCO Xenix was rampant on the x86 boxes. I would argue that without those two items, "a generic component" and a virtual plowed field of "generic" components, the FSF would still be in a two room office.

How does this apply to the discussion at hand? We're all taking about how to support a dozen different architectures with half a dozen different tools. I think this is a mistake.

The discussion is good about how to structure an editor to accept different modules, etc. But what's going to become the "generic" hardware that's also needed to make it a viable project? A commodity based ATX style "PLC" design? No, it's not out there, and MatPLC doesn't count. I like the MatPLC project, but where are they? From where I sit, the only "commodity enough" hardware platform to provide ripe breeding ground is the Allen Bradly SLC-5/0x line.

I know, I know, Siemens, X, Y, Z, P, and Q PLCs are making inroads!!! Forget it. Call 50 plants with over 200 employees at random and ask what PLCs they have. Half of them will be A-B SLCs.

So, my gut tells me that the only way to make this a successful project is to start as an editor for A-B SLCs. And it's going to necessarily (aack, gag) have to run on WindowsXP. Otherwise there won't be enough momentum to give it a critical mass.

Witness, however, that the last successful attempt to make a replacement A-B editor (by a little company named Icom) got bought out and became Rockwell's RSLogix. So, there's a target, supplant RSLogix5, 500, and 5000. These three platforms are different enough from one another that the task of supporting them in a single environment will need to be addressed, plus has the advantage that the hardware is all over the place, and a gazillion maintenance engineers and tech all over the world would be delighted to have a second or third license from Rockwell.

Then, once there are a few thousand active users for the editor on A-B equipment, if a module for an ATX based commodity PLC appeared it would be a ripe field.

Again, this isn't supposed to be a "coherent essay" that's all tightly thought through. It's just a mulling over of a collection of thoughts.

Michael
--
Michael R. Batchelor

www.ind-info.com/training/Schedule.pdf

GUERRILLA MAINTENANCE [TM] PLC Training
5 Day Hands on PLC Boot Camp for Allen Bradley
PLC-5, SLC-500, and ControlLogix

http://stores.ebay.com/Guerrilla-Maintenance-Boot-Camp

If you aren't satisfied, don't pay for. Guaranteed. Period.

[email protected]

Industrial Informatics, Inc.
1013 Bankton Cir., Suite C
Charleston, SC 29406

843-329-0342 x111 Voice
843-412-2692 Cell
843-329-0343 FAX

( Complete thread: http://www.control.com/1026222374/index_html )
 
M

Michael Griffin

<pre>> the thought I had about one editor that supports different
> "instruction objects" or "symbol sets" hasn't fallen flat yet.
> This entity could contain the symbol for editing display, the
> various addresses that the instruction uses, even the code to be
> generated when compiling. So when you place an instruction, the
> editor would "know" what blanks need to be filled in. And for
> online monitoring, the refresher would know where to look for the bits,
> all in this instance of the instruction object. </pre>

<p>I was thinking in terms of a set of base classes that implement editing of the most common ladder functions such as contacts, coils, different types of timers, counters, etc. A set of PLC model specific classes could then inherit from the common classes wherever possible, and add their own specific classes to fill in the rest. This would minimise the work involved in adding support for a new PLC, while still giving the maximum flexibility in adding features specific to that PLC.

<pre>> So each instruction could be a struct with the bitmap, the output code,
> the addresses, etc, etc. and each function would know how to deal with
> these structs to do their task. </pre>

<p>Without getting into the actual implementation, I think that we need to keep in mind that each instruction will have addresses and/or data associated with it, and that these addresses and data will have editor rules as well. This means that for example a contact edit class will need to be able to invoke the correct address edit method to control how addresses are entered and displayed.

<pre>> That takes care of the ladder part, but then you have wiggy stuff that
> embeds IL or huge blind function blocks. It took years to resort to
> that sort of depravity but those would probably have to be exceptions
> to the rule. Or perhaps each IL instruction could be a similar struct.
> I haven't wrapped my head around supporting FBs yet. </pre>

<p>IL should be much easier than ladder. If you are editing a rung in IL mode, then you are just entering text. The syntax can be checked when you "accept" the rung. If the editor is displaying a rung, then if it can't figure out how to display a run in ladder format, it defaults to IL. This is similar to how Siemens Step-5 and Step-7 work, so there aren't really any new concepts there.

<p>As for function blocks, there are two different things with the same name. One sort of function block (FB) is just a specific type of subroutine. In IEC terminology, an FB is a subroutine which has local (private and static) variables. This differs from a plain "function" in that a "function" doesn't have local static variables.

<p>The other sort of "function block" is actually properly called "function block diagram" (FBD), and is just a different form of representation comparable to ladder. Supporting FBD is no different from supporting ladder. However, I wasn't going to suggest adding support for it at this time, due to the amount of work involved and the fact that relatively few people use it. However, the editor framework should allow for alternative representations (including FBD) to be added later (i.e. any sort of "edit_mode" variables should allow for more than two states).

<pre>> >What this means is that for ladder, the representation depends upon a
> > complex set of rules that will not be the same for different PLC
> > families. There would also have to be a conscious effort if it were
> > desired to ensure the valid IL "ladder" patterns are the same as people
> > are used to for that PLC.
>
> The method above would help here as we could define what a timer cooks down
> to. And if need be you could have a symbol set for the alternate
> tool. Defining these would be contributed work as interest serves
> because no one else is likely to have your particular mix of junk to
> support:^) Now the stuff that is context sensitive..... </pre>

<p>No, things like how timer presets work would be determined at a lower level. Higher levels are concerned how instructions are allowed to "connect" to each other. For example, I have created some arbitrary IL below (this is for no particular PLC):
<pre>
Rung #x
A I1.0 ; Cylinder extended.
L 10.0 ; Load timer preset.
SD T2 ; Start timer.
A I1.1 ; Cylinder retracted.
R T2 ; Reset timer.
</pre>
<p>How should the above be displayed in ladder?

<p>1) Scenario #1 - As IL (see above) if the accepted ladder format for that PLC does not allow you to have a timer set and a timer reset in the same rung. If you split this into two rungs (separating the timer set and reset), you would get ladder.

<p>2) Scenario #2 - As a single timer "box" with both set and reset inputs. A valid ladder pattern is {arbitrary set of boolean inputs}, L {timer preset}, SD {timer address}, {arbitrary set of boolean inputs}, R (same timer address again}. (ASCII art ladder version below).
<pre>
Rung #x
I1.0 |-------------|
--| |-------------| S |-----
| T2 |
I1.1 | PRE 10.0 |
--| |-------------| R |
|--------------| </pre>

<p>3) Scenario #3 - As two separate "sub-rungs" within the same rung. (ASCII art
ladder version below). I don't know how common this one is, but I did see
this once some time ago.
<pre>
Rung #x
I1.0 |-------------|
--| |-------------| S T2 |-----
| PRE 10.0 |
|--------------| I1.1 |-------------|
--| |-------------| R T2 |-----
| |
|--------------|
</pre>
<p>Which of the above is correct will depend upon whatever is the convention for that PLC. The editor will have to have sets of "patterns" it can compare each rung to for a match.

<p>4) Of course there is scenario #4 - Allow #2 whether that is convention or not. This might be a problem though if a particular brand of PLC is ladder only (no IL mode), and the OEM programming software flags it as an invalid rung when someone else uses it to look at the program.

<pre>> >This part also has to address the question of formatting or compiling the
> >program source code into the format required by the PLC. In cases where
> > the "compiler" (whatever that may consist of) resides in the PLC, that
> > may simply require checking and tokenising the source code. In cases
> > where the "compiler" resides in the programming PC, things could be a lot
> > more difficult, possibly prohibitively so. Reverse engineering a compiler
> > (and any associated libraries) is not a trivial task.
>
> If the target is machine language, yes it would be ugly. But I suspect
> some sort of tokens for an interpreter as online edits would be very
> exciting with hard coded jumps and addressing. Could be completely
> wrong though, too. It's a job just making educated guesses about what
> they are doing. I suppose one could dump some ROMs and see what
> makes sense, if anything. </pre>

<p>I understand that there are two different ways of implementing a PLC. In method one, the "compiler" is in the PLC ROM and you just download your application source to it (possibly in tokenized format). I believe that most older PLCs work this way, and ones which allow the use of a hand-held programmer almost certainly work this way. These should be simple to deal with, provided we know the tokenised format and communications protocol (in the worst case, this can be reverse engineered).

<p>The other way is where the PLC when originally delivered has nothing more in it than a simple program loader. When you download the first program, the download includes both the PLC program and a binary to run it. This binary is probably something like a threaded interpreter, or possibly something similar to a Java VM. A variation on this is to actually compile the PLC program to binary format (like pre-compiled Java), link it to the main libraries, and send along a copy of the source only so you can still upload it. From our standpoint, either of these variations is equivalent. The downloadable firmware binary could be different for each PLC model, and it may also include new features or instructions from time to time.

<p>Method two presents a problem, in that the PLC is just an "empty box" without the "firmware". Either we would have to get the OEM's close co-operation, or we would have to create our own replacement "firmware" (which is far outside the scope of simply writing programming software).

<p>P.S. - Your forwarded e-mails come out poorly formatted on my e-mail client (I fixed up the quotes above before replying). I think you have your line wrap set at something like 90 characters. If you cut this down to something like 78 (or less), it should come out better. Everyone else seems to be OK.
 
C

Curt Wuollet

Hi Jeremy,

On June 5, 2006, Jeremy Pollard wrote:
>Good afternoon to all. I am a grey hair (or no hair) in this biz, and have
>grown up with the IPDS ICOM Taylor Graysoft ASAP etc etc etc . time of
>automation life.. They didn't survive and couldn't survive on their own.
>
>They HAD to be attached to hardware.. SoftPLC (aka Teledenken Resources)
>had to develop/license their own brand of PLC in order to be successful.
>
>No where is there any company that has gained a foothold by selling software
>by itself. <

Or one might argue that by being proprietary and deliberately working with nothing else, these guys limited their market to below the "critical mass" needed to survive. One does see a pattern that emerges in proprietary technology. First there's one. then it seems there are competitors behind every tree and they divide the market into too many segments for the smaller to survive. Then they sue each other and cut each other's throats until the lucky pick up the pieces and you end up with a few, or perhaps one depending on noncompetitive behavior. It is also almost without exception that really universal things aren't owned by anybody. I'm prepared to argue that it wasn't the software only approach that killed them. It was all the work they did against their customers interests and to avoid cooperation that killed them. But the software only approach does need one very difficult thing. They must make things as easy as the packaged systems. I can do automation any way I please, even start from scratch and build the hardware and write the software. I have noticed very few people want even the hassle they have with the easiest solution. In fact
we get people here all the time that want all their problems solved and a list of equipment so they don't have to read. If you could use one tool for most or all of your systems, that would be much simpler. Especially if you didn't have to track licenses or support contracts and you had interested people to talk to without a credit card. There are a lot of problems to be solved and they are pretty tough, but it wouldn't take a lot of interest to get more people working on them than any one vendor has.

>One might argue that ISAgraf is .. but it is more for the embedded market.
>
>Customers don't care about licensing costs, as such. They want to get the
>job done. Would anyone disagree with that??
>Having said all that, IEC-61131 (I was the NA managing director for 6 years
>for PLCopen) is/was supposed to be that. Well it isn't.. and why not you
>ask????
>
>Hardware, market share, captive audience, licensing fees, and making money
>come to mind. <

Exactly, the Golden Egg that killed the Goose.

>Any 'open-source' (like the Puffin Project that Ken Crater created) project
>will not be successful in the open and general marketplace for the
>aforementioned reasons.. plus the cost and effort to HAVE to deal with
>legacy. <

The CEO of DEC comes to mind here, " Why would anyone want to have their own computer?" The legacy has pretty much gone away simply because the alternative was more attractive and less secret and exclusive.

>The solution can be viral however. The approach can be like PLCopen.. where
>we have members - us - and committees that look after the design of the
>components. <

It could, if that's what people really want.

>Steering committees develop the strategies, and it is voted on. And the
>benefactors of the results is us.. and when others see the benefits
>(assuming there are some), they might be joining in. <

So far consortia have pretty much continued "business as usual" selling old wine in new bottles.

>Online stuff .. man that's tough - ask anyone who's developed a driver . but
>the protocols are mostly public.. for a cost!!
>
>Maybe a good start would be to define an export format, then a pre-compiler
>for the current hardware programming software (or file format if available) <

Adding software complexities to the existing ones sounds like the wrong direction.

>Then maybe a direct downloadable file for the target PLC and software, and
>eventually the vendors software can be replaced... maybe ...
>
>All of s/ware is free.. IEC software cannot download to any other hardware
>than what it is/was designed for. And that is BY design. <

And the major obstacle to growth and widespread acceptance.

>Tiny steps .. I would suggest an executive committee and members to begin
>the execution.. First starting with a mission statement and a target design
>and time line. <

Maybe we could hire some image consultants and do an advertising campaign. :^)

No that's a little too old way. You know the actual work on those was done by a few people who probably skipped meetings whenever possible and couldn't recite the mission statement on a bet.

>I've worked for a software vendor and consulted for more ... the effort is
>not insignificant.. who's ready for the commitment? <

That is what we need, and the most valuable human asset. I can't say how many times I've been amazed what even one committed individual can do.

Regards

cww
 
M

Michael Batchelor

> Sometimes that means adding or changing
> a few things, but more often its a matter of convincing the right people and
> the right organisations to endorse it. <

As per my comments yesterday, I don't think we're ever going to be successful getting "the right people" to endorse it. Success is going to come down the same pathway that success came for gcc. That compiler is successful because thousands of us quietly started using it, not behind our boss's backs - our boss's didn't know because it didn't show up on their radar screen. All the boss cared about was that the user's application bugs got fixed, and my boss in particular didn't even know I used cc or gcc. I doubt he knew the difference. But the problems got fixed and that's what he cared about. Then one fine day someone looked around and every single box in sight had gcc installed on it by the guys who had to work with it day in and day out. And nobody used cc anymore other than as an engine to bootstrap gcc.

A freely distributable editor that lets the machine get fixed, improved, or whatever, won't ever show up on the radar screen of the plant manager who has to answer to his boss about production. But it can show up on the desktop and laptop of thousands of maintenance engineers and technicians. And then one day someone will look around and every single computer in the maintenance and project engineering department will have a copy of the "Great Whiz-bang GPL PLC editor" loaded on it. And only the "official" laptop will have the vendor licensed software so they can get "official" support.

> If automation companies and users do accept it, then there will eventually
> need to be some sort of forum which will bring them together and lets
> everyone's voice be heard, so that no-one is afraid that they are going
> to end up with the short end of the stick. A GPL software licence would
> definitely help with this, as no-one can use control of the code to dictate
> terms to anyone else.
>
> I think first though, we have to prove that we can build it and get it working
> with at least one real PLC before anyone is going to take us seriously. <

And to be taken seriously in a ripe field, that must necessarily mean working in the real world. And the real world is WindowsXP as the OS, and A-B SLC as the PLC, at least in North America. I don't care about who's gaining or losing market share in new sales. I'm talking about what's out there right now if you take an inventory. There are tools that allow decent cross platform development such that anything developed to "target" the WinXP market can also run on the Linux boxes. If nothing else, just distribute Cygwin with the editor. I personally install CygwinX on every machine I get forced to work with, just so I have a decent tool set. If it's just "part of the package" then no one will care.

MB

--
Michael R. Batchelor

www.ind-info.com/training/Schedule.pdf

GUERRILLA MAINTENANCE [TM] PLC Training
5 Day Hands on PLC Boot Camp for Allen Bradley
PLC-5, SLC-500, and ControlLogix
http://stores.ebay.com/Guerrilla-Maintenance-Boot-Camp

If you aren't satisfied, don't pay for. Guaranteed. Period.

[email protected]
 
C
Hi Michael,

>I hate jumping in this conversation, partly because we've all been
>involved in the same discussion for years
>(http://www.control.com/1026170363/index_html and
>http://modbus.control.com/dev/1014142129/index_html search for my last
>name see some of my old comments). And partly because this isn't really
>a coherent essay I'm trying to write, but more a random collection of
>thoughts and facts, and I'm a little afraid someone will look at any
>oversight I may make and jump on it as proof of fallacious thinking. But
>here goes.
>
>I've been using gcc since 1989 (before it was really useful), and failed
>miserably to compile my first Linux kernel in 1992. So, I'm not exactly
>"new" in the open source world.
>
>Way back yonder in the good old days everyone in the old Usenet
>community used and contributed to the pool of tools in a very
>egalitarian way. The primary driver was that the "tools" didn't exist in
>any of the various Unix vendor's distributions, and the tools didn't
>threaten market share in any of the vendor's systems. The tools were
>created by the user community, for the user community to fill an unmet need.
>
>Richard Stallman, genius or madman - you take your pick, started
>changing the way think about these things. His original claim to fame,
>Emacs, was just another project to fill an unmet need, but then he got
>into the GNU frame of mind and started the project that, honestly,
>changed the way software is developed and marketed. The FSF gcc project,
>and later glibc, has probably made more difference in the software world
>than anything short of electronics themselves. <

And it still is the foundation of OSS and important without measure. Because of that effort and the precedent it set, anyone can be a developer without being employed as one. This is a very important factor, as is the ability
of anyone to have a World Class *nix installation and be able to know each part of it. And you can have at least a dozen programming languages to choose from, free of charge. Before this, you pretty much had to be going to college in CS or be working as a programmer to have something to write programs on or a language to write programs in. I wrote in C on proprietary UNIX machines
because that's what they had and C was how you manipulated them. There was very little opportunity for me to write "personal" software. Even the PC Unixes were out of reach (except for Minix) and even DOS programming languages other than BASIC were a serious investment. Contrast that with now when anyone who can get their hands on a PC is on equal footing with anyone in the world.

>However, I'll still stand behind my assertions made in the first link
>shown above, that what needs to get developed is the "generic"
>component. Now, I'll agree that this whole thread is about developing
>that "generic" component. No argument about that from me. But if you
>stop and think about the good old bootstrapping days you can see the
>chicken and the egg problem a little more clearly.
>
>When gcc was a gleam in a small group of programmers eye, the Sparcs it
>was supposed to run on were essentially a commodity item in the MIT lab
>they had available to them. As things progressed, and gcc became
>available for the x86 architecture, things took off because there was
>"real" commodity hardware available to the general masses, and SCO Xenix
>was rampant on the x86 boxes. I would argue that without those two
>items, "a generic component" and a virtual plowed field of "generic"
>components, the FSF would still be in a two room office. <

And because the SCO compiler was still our of reach for private individuals.

>How does this apply to the discussion at hand? We're all taking about
>how to support a dozen different architectures with half a dozen
>different tools. I think this is a mistake. <

Fewer is better for sure.

>The discussion is good about how to structure an editor to accept
>different modules, etc. But what's going to become the "generic"
>hardware that's also needed to make it a viable project? A commodity
>based ATX style "PLC" design? No, it's not out there, and MatPLC doesn't
>count. I like the MatPLC project, but where are they? From where I sit,
>the only "commodity enough" hardware platform to provide ripe breeding
>ground is the Allen Bradly SLC-5/0x line. <

I agree completely, however they are not the easiest target. Well, I agree except for the MAT part. But the MAT part will be by far the easiest to support since we all own the source. But it certainly makes sense to aspire to the most popular machines out there. And I think most people like their software and instruction set. I expect we might have more influence with others though :^)

>I know, I know, Siemens, X, Y, Z, P, and Q PLCs are making inroads!!!
>Forget it. Call 50 plants with over 200 employees at random and ask what
>PLCs they have. Half of them will be A-B SLCs. <

A big problem is that 100% of them have little choice in what they will support or even buy. They are locked in by legacy or edict.

>So, my gut tells me that the only way to make this a successful project
>is to start as an editor for A-B SLCs. And it's going to necessarily
>(aack, gag) have to run on WindowsXP. Otherwise there won't be enough
>momentum to give it a critical mass. <

That adds a level of difficulty and controversy. For my own part, I would go as far as designing for portability so those rich folks that have MS tools can port it. But to be perfectly honest, a major part of my motivation is to use Linux and avoid all the hassles that go along with the MS platforms. And if you have the money for MS and are OK with closed systems, I don't see what we could offer that was a big advantage over RSLogix. But if people want to have two versions, I guess I could live with that as long as the Linux app is a Linux app and not a kludge for the sake of compatibility.

>Witness, however, that the last successful attempt to make a replacement
>A-B editor (by a little company named Icom) got bought out and became
>Rockwell's RSLogix. So, there's a target, supplant RSLogix5, 500, and
>5000. These three platforms are different enough from one another that
>the task of supporting them in a single environment will need to be
>addressed, plus has the advantage that the hardware is all over the
>place, and a gazillion maintenance engineers and tech all over the world
>would be delighted to have a second or third license from Rockwell. <

Or to not need one.

>Then, once there are a few thousand active users for the editor on A-B
>equipment, if a module for an ATX based commodity PLC appeared it would
>be a ripe field. <

The ATX commodity PLC will happen at it's own pace, the hardware case is much different than the software case as most people consider hardware immutable. My personal interests favor cheaper, more versatile hardware, but the
software BS I go through every day makes better software a compelling issue. I estimate I'd gain an hour a day with decent software and much of the misery of PLC work would go away. I could live with using MS only for email and time and attendance.

>Again, this isn't supposed to be a "coherent essay" that's all tightly
>thought through. It's just a mulling over of a collection of thoughts. <

I think you are mainstream on this with a few exceptions, but then I probably have more exceptions than you :^).

Regards

cww
 
Thread starter Similar threads Forum Replies Date
M General Software Chat 2
Top