# On Replacing PLC's

C

#### Curt Wuollet

Hi all As you know I have been busy lately on an automation project. This has become a most unusual automation project for several reasons. It started as a more or less normal integration task to tie various machines into a cell. It got bogged down using the normal tools and has been reborn in a lightweight low cost approach out of neccessity. What is remarkable is how the inherent functionality of Linux made the reborn project much easier to realize and substantially reduced the risk of failure. Before with conventional automation tools, the complexity was problematic, the expense was exceptional and everything had the feeling of just barely working. Because of the nature of the project and the difficulty of getting all these standalone automata to talk to each other, an enormous amount of time and energy went into overcoming obstacles and taking the PLC's and other components outside of their element. In retrospect it was a case of the round peg in the square hole syndrome and points out a unique and powerful paradigm that we would be well to study at some length as it has changed my thinking quite a bit on what an optimal automation system should offer as capabilities. PLC's do many things well. Their particular characteristics are modeled on replacing relays and wired logic. They are also widely applied for things for which they are non-optimal but serviceable through the many extensions tacked on and made inflexible by the limitations of the paridigm. Communications is one are where they tend to be rather inflexible. They do give you functions but the functions tend to be quite specific in their appicability and very narrow in scope. They are horrible to handle text with and the math capabilities, while there, are reminiscent of the days I spent writing in assembly language. To their credit, the PLC makers have found ingenious ways of making things possible. It is amazing how many things you can do with them, how many needs are addressed, but, when all you have is a hammer......... I was asked if I could replace the PLC's in the system and lower the complexity and accellerate the development. I was not well prepared for this and had to give it some thought. The lack of preparation caused considerable fear, uncertainty and doubt. I countered this with the certainty that there was no reason why I couldn't and obviously this is what LPLC is all about. I committed. As I did due diligence and worked through the process, I regained confidence almost immediately and I feel great about the project. The powerful and comprehensive tools I have at my disposal greatly simplified and solidified the design and I was operating well within my scope and comfort zone. I can't escape the strong feeling that this is the way it should have been done in the first place. A great weight has been lifted off my shoulders. The last worrisome area as, ironically, doing what the PLC does well, managing the dozens of sensors and valves and discretes that are the forte of ladder logic and IO racks. With the card working and the new approach I took, everything fell into place and for the first time, the project is going really well. I felt this experience was very important as few of us are actually solving automation problems with Linux. I also found that simply replacing the existing methods and functions may be the wrong approach. Using a LPLC to replace the PLC's in this case would not have fixed the project. We need to invent the chainsaw rather than making a cheaper finer and sturdier axe. This has broad implications and will, no doubt draw howls of protest from traditionalists, but if we today were done and had a fully featured drop in replacement for any PLC, it would still be the wrong way to integrate the cell I'm working on. The way I am doing it is simply doing the parts that are not logic with a conventional procedural program. The sequential parts, the communications. my machine vision, the math, the HMI. All these things are infinitely easier to do with "regular" programming than forcing them through the PLC paradigm. The asynchronous logic, the parallel tasks the simple PLC stuff is infinitely easier to handle with an embedded PLC. When you are not driving screws with a hammer or pounding nails with a screwdriver, when you have the proper tool for the task, it simply takes less work to do something like this. A lot less work. Let me repeat that, a lot less work. Months less in this project, the difference between success and failure. My question and challenge to you is: How do we make that power available to those who are not Linux systems programmers without crippling it. How do we get acceptance in the market for a major advancement in the state of the art? Talk to me. Regards cww PS. This lets the PLC process be embarrasingly simple, small, and straightforward. The procedural code simply attaches to the map to gain access to the registers and a small number of functions hide the details so you are not bound to PLC rules. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jeff Thurman

Curt: Many times in the past I have encountered problems similiar to what you have described in your email. Normally I try to get a "full" description of what I am trying to accomplish and how "I" think it needs to be done. Then I search out how others are tackling the same problem and why they are doing things in a particular manner. At this point I compare notes on what others are doing and how I want to do it. I will typically use the concepts that work for others, combine them with mine to create what I'm after. "Use what works" As an example: if your trying to have an HMI as part of the Linux project it might be benificial to see what and how others are doing in this area. Both in the Unix and Windows world. The biggest problem normally is not having a concise game plane before starting. Jeff Thurman Curt Wuollet wrote: > > My question and challenge to you is: > > How do we make that power available to those who are not > Linux systems programmers without crippling it. How do we > get acceptance in the market for a major advancement in the > state of the art? > > Talk to me. > > Regards > > cww > > PS. This lets the PLC process be embarrasingly simple, small, and > straightforward. The procedural code simply attaches to the map > to gain access to the registers and a small number of functions > hide the details so you are not bound to PLC rules. > > _______________________________________________ > LinuxPLC mailing list > [email protected] > http://linuxplc.org/mailman/listinfo/linuxplc _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Ken E.

Hello Curt, I can relate to what you are saying 100%. The company I work for Developed an assembly based macro language 20 years ago because they refused to work with ladder logic (rightfully so). The language and RTOS was taylored to the task at hand and therefore was simple and brutally effective. I can quite honestly say that if we were to implement our machines on existing PLC platforms that the company would not be successful and would have to scale down the scope of our machines to accommodate an inferior programming language. That is just wrong. Now with PC hardware being so powerful and cheap we are using that in combination with a third party soft PLC. This certain soft PLC has worked great for us compared to the alternatives, but I have found that I have spent a lot of time overcoming the problems of the system architecture rather than dealing with the task at hand. I agree with you that conventional programming is extremely effective with dealing with machine tasks, but there are a few hooks needed, such as IO and communication. I think we both agree that this is the niche that the LinuxPLC will provide for its users. So I agree with you. The paradigm must change to meet the application needs. I think that an industrial-ized version of the C language is the best bet. No, I don't suggest changing ANSI C ... perhaps a preprocessor language extension to take up where C leaves off with regards to automation. As with any design, added power and flexibility will add complexity. We will not be able to please all of the PLC Dinosaurs, and to be honest, I don't think the PLC Dinosaurs will go for LinuxPLC. I think that this project will find its niche in defining a more elegant and powerful PLC paradigm. ~Ken _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### jmGiraud

From experience, PLC's, DCS and the bags of functions, miracles ...to the end of the list, are designed and sponsored by some major user. To their taste (no name). This is why, manufacturers are so reluctant to change for odd users. Protectionism. Nice hearing both you, did it. What you did is like drilling a hole in butter. Harder to punch than drill. Thanks the long talk. Also for the greasy round pig in the square hole.

C

#### Curt Wuollet

Hi Jeff The outline or plan thing is a good idea. I use it everywhere else. Here it is somewhat presumptious to put one together without some brainstorming or at least getting some feedback on the concept. I somewhat disagree on surveying what the industry is currently doing. That seems to be the problem rather than the solution. In a nutshell: Automation today has gone beyond relay replacement. More and more, there are portions of a solution that more resemble general computing than definite purpose computing. The ideal solution should be better at communications, interfacing, computation, etc. These are the weaknesses of PLCs in general and of the proprietary status quo in general. I read a good example on the A-list the other day. We have PLC's now that support Ethernet to talk to their racks and perhaps their peers. That is all you can do with it by design. Emulating that is crippling the capability of Linux to communicate with Ethernet to anything. I know why they did that (besides the obvious lock in factor) it is because the languages they offer don't support much more than single purpose use. You load up some registers, hit go and the contents are formatted and sent. The model is to set things up and then on a condition execute a function. This model is exclusive to PLCs, everything else works differently. The industry has recognized the problem. They offer "ascii" modules and various coprocessor modules where you can do the things that cannot be modeled as ladder logic or the functional equivalents. What I am saying is that it might be optimal in some cases to reverse that. Have a procedural language with a ladder "module" as an add in. By having the capability to divide processes according to flow, you can do some things very easily that would be difficult with either alone. It would be most challanging to integrate the cell I am working on without the rich serial comms and fast array processing that writing in C provide. It would be very difficult to do the logic portions in my procedural code with the need for continuous update, etc. But, by having a procedural process and an embedded logic solver cooperating and communicating through a common map, it's hard to believe how much simpler the job becomes. No one seems to be capitalizing on this. I can do this now and that's great, but it would be fantastic if we could make it accessable to the average PLC programmer somehow. The Windows alternatives do some of this but the mix between event driven programming and logic solving is not as powerful and they allow no more access than the canned PLC routines. Maybe I'm all wet or my problem set is non representative or maybe it's because I'm still more comfortable with "regular" programming. But, looking at the distribution of problems on the automation list, many look a lot like those I've just solved. This is not edict or a change in direction or anything of the sort. I'm just trying to access the greatest bunch of minds in the automation field to get them thinking and get a reading. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

B

#### Bob Page

Curt, >How do we make that power available to those who are not >Linux systems programmers without crippling it. As you have said "The best place to start is understanding." I believe the best place to start understanding is by working on the documentation. > How do we get acceptance in the market for a major advancement in the >state of the art? By documentation which is understandable by integrators who are able to configure function blocks and can program structured text, instruction logic, or ladder programs, but may not be familiar with C jargon. I believe the prime beneficiary of this effort is the group of integrators who have to keep up with all the plc and dcs implementations. They (we) will see the benefit first and then will be able to pass the benefit on to the user. Perhaps understanding could be helped by a top down approach, a general description which mentions modules and describes how the modules fit together then a description of each module, ie DIO48, which mentions sub-modules, etc. The lplc.txt document does an admirable job of this but I got bogged down in some of the programming terminology. I am working on it a little in an attempt to facilitate my understanding. I will submit the results with the hope it may help others. If it does not, the bit bucket is very handy. For example, "PLCs are usually programmed off-line, using tools running on DOS or Windows. The text-based programs or diagrams are compiled to an intermediate language that is downloaded to the PLC and interpreted." Could we use the same structure to generally state the process for the PuffinPLC? e.g. PuffinPLCs are usually programmed off-line, using tools running on Linux. The text-based programs or diagrams are compiled into custom modules. The user configures the application by selecting the required standard and custom modules. The user then synchronizes the execution of the module.... And stores the results in a configuration file (puffinplc.conf by default). For modules to run, The user executes a utility called puffinplc, using the data stored in a configuration file. puffinplc sets up the shared memory areas and the semaphore sets Copies the configuration into the configuration memory. and launches the modules the configuration requires. Please keep up the good work. More later, Bob Page _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jeff Thurman

Curt: I don't necessarily disagree with what your saying. I guess what I'm suggesting is to look at what others do and why. Typically they try to give the customers what they want. Some of their solutions are not the best and others are very good. Three years ago people from two different companies came by to see a machine that I built in 93. Both used WonderWare in their applications and had spent months on their projects just programming. One of the companies had built a machine which included 8 plcs and 8 computers networked together. I had done a similiar task on a much larger scale than he had with one plc and one pc and about 1/4 the program code they had used. This is what they wanted to see. Perhaps my approach would not directly work in their situation, but a twist here and a twist there may do the trick. One technique I use is to dynamically expand or contract new machines when built. One may have two control heads, another machine that is slightly different may have four control heads. In my programs a couple of variable are changed to tell the program how may devices are there and where they are at. The program makes the necessary adjustments itself. One thing I have noticed about most system integraters now days is their limited programming ability. This is probable why WonderWare, Citec, Genie etc have such a large market. By the way most plc programmers I know can program plcs and thats about the extent of their experience. Thats a shame. jeff _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

B

#### Bob Peterson

In a message dated Mon, 9 Apr 2001 10:24:20 AM Eastern Daylight Time, "Ken Emmons, Jr." <[email protected]> writes: << Hello Curt, I can relate to what you are saying 100%. The company I work for Developed an assembly based macro language 20 years ago because they refused to work with ladder logic (rightfully so). The language and RTOS was taylored to the task at hand and therefore was simple and brutally effective. I can quite honestly say that if we were to implement our machines on existing PLC platforms that the company would not be successful and would have to scale down the scope of our machines to accommodate an inferior programming language. That is just wrong. >> OTOH, for every instance where someone has had great success doing this, there are probably 20 people who failed, and mostly failed miserably. I dread having to go in and try and debug/update/modify some gibberish that was written in C/basic/assembly by some guy who thought he could do it better then AB. So far, at least in my experience, the homebrew guys are batting 0 for 20 (or so). I have yet to see a homebrew system that is effective over the life of the equipment. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

K

#### Ken E.

Hello there, That is why somebody like the Linux PLC project needs to be involved with the development of such system ... to make it *not* a home brew solution anymore. I don't know about you, but I find the following a lot easier to read: Wait_For_Tag_With_Timeout(ValveLimitSwitchBack, 500ms, Error26); Set_Tag(MyValve, ON); Wait_For_Tag_With_Timeout_And_Retry(ValveLimitSwitchForward, 200ms, 3, Error27); The above code would make sure that the Air cylinder is back before trying to actuate it forward. It even waits for 500ms in case it is in travel. Upon timeout it generates and error and waits for an operator to acknowledge it. If all is well it actuates the valve to the on state and the cylinder moves forward. It gives it 200ms to complete this operation and then retracts it and tries again 3 times before generating and error and waiting for operator acknowledgement. This is very readable, and I don't want to think about the ladder logic Equivalent. And what if this routine is called from many different places in the code and the actual valve and limit switch names are passed down fom the calling function for code re-useability and fault tolerance?? With C language as a backbone this works well. I wasn't suggesting Hieroglyphics or assembler, just some easily readable code that goes beyond the Ladder/IEC paradigm. And, lets face it, computer languages (Like C) evolved to be flexible for a reason. Having said that, I also think that Ladder should be supported for legacy applications and personel with traditional training. BTW, if you are a big AB fan, why are you in the LinuxPLC discussion group? ~Ken _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

B

#### Bob Peterson

I am not necessarily a big AB fan, but it works a whole lot better then you let on. The gibberish you suggested up there is totally unreadable to an electrician in any plant I have been in. I don't know what kind of automation you are involved in but a LOT of what I do involves almost constant change, debugging, and patching, often on the fly, and usually by the plant electricain, while the plant continues to run. Can you system do that? If not, it is not viable alternative to PLCs. It may well be fine for an isolated machine or process that never changes, but would never fly in most applications. These things have to change continuously as the plant figures out how to make minor improvements to the machine or process. As for why I am on the list, I thought it was a Linux PLC clone, not something that does not even remotely resemble a PLC. If it is not going to have any the critical characteristics of a real PLC, stop calling it a PLC and call it something else. It would be nice to have user defined function blocks that can be called, however, they need to be live at all times so status of the internal data can be viewed for debugging purposes. Just callinga subroutine where the data is hidden, or not easy to get at does not cut it. You may write perfect code that never has to change, but no one else does, and no machine or process of any size is static. they all change, and a LOT of the changes are on the fly with the machine running. Stopping to recompile is not an option. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

B

#### Bob Page

[email protected] and Jocelyn, Would the IEC 61131-3 language be satisfatory for your needs? Some electricians I worked with prefered function blocks to ladder, some prefer statement list. I actually like ladder and it can be structured Note: the proposed IEC 61131-3 compiler will translate IEC 61131-3 statements into C code. So the user would not have to see the C code. Curt, isn't the purpose of the Vitrine module to display the value of the plcPoints? _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

P

#### Philip Costigan

On Tue, 10 Apr 2001, [email protected] wrote: > In a message dated Mon, 9 Apr 2001 4:08:05 PM Eastern Daylight Time, "Ken Emmons, Jr." <[email protected]> writes: > > << Hello there, > > That is why somebody like the Linux PLC project needs to be involved with the development of such system ... > to make it *not* a home brew solution anymore. > > I don't know about you, but I find the following a lot easier to read: > > Wait For Tag With Timeout(ValveLimitSwitchBack, 500ms, Error26); > Set Tag(MyValve, ON); > Wait For Tag With Timeout And Retry(ValveLimitSwitchForward, 200ms, 3, Error27); > > > I wasn't suggesting Hieroglyphics or assembler, just some easily readable code that goes beyond the > Ladder/IEC paradigm. And, lets face it, computer languages (Like C) evolved to > be flexible for a reason. Having said that, I also think that Ladder should be > supported for legacy applications and personel with traditional training. > > > >> > > I am not necessarily a big AB fan, but it works a whole lot better then you let on. > The gibberish you suggested up there is totally unreadable to an electrician > in any plant I have been in. We have to keep in mind that Linux PLC is flexible enough to accomadate the two or three different worlds of automation. In some cultures is is thought ludicus for an electrician to go anywhere near the complexities of an automation system and in other cultures its is thought that if the control system is not made easy enough for an electrician to use, then its no good because expensive engineering staff would then be needed. I agree with both of these senarios. >I don't know what kind of automation you are > involved in but a LOT of what I do involves almost constant change, debugging, > and patching, often on the fly, and usually by the plant electricain, while > the plant continues to run. > Can you system do that? The structure of LPLC is that many different modules can be created to drive the internal workings of the PLC. So flexible is the structure that most if not all programing paradigms can be implemented. (all at the same time if there is enough memory etc.). eg. [main LPLC] internal I/O for all to see \[IEC STRUCTURED TEXT] module 1 \[SOMEBODIES LADDER] module 2 \[FLOW CHART DIAGRAM] module 3 \[I/O DRIVER] module 4 These four modules run INDEPENDENT of each other so the FLOW CHART code can be waiting for somthing to happen while the ladder does its continuous update. etc. etc. > It may well be fine for an isolated machine or > process that never changes, but would never fly in most applications. > > > These things have to change continuously as the plant figures out how to make > minor improvements to the machine or process. The idea of editing on the fly is being addressed as far as I know. > If it is not going to have any the critical > characteristics of a real PLC, stop calling it a PLC and call it something > else. > > It would be nice to have user defined function blocks that can be > called, however, they need to be live at all times so status of the internal > data can be viewed for debugging purposes. See above Keep in mind that it is your choice to decide what modules you wish to install. If its ladder you want then by all means use that module (when its developped). in theory all programming languages can be developped and used with LPLC. I hope all this makes sense Regards Philip Costigan _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Jocelyn Rest assured that Ladder functionality will be in the LPLC. And whatever functional equivalents we can come up with (IEC1131). And guys, I was not talking about calling blocks from ladder. And I am not necessarily talking about C. There would be nothing new there. I am talking about a mixed code machine but keeping the sections separate. We do comms, protocols, human interaction, perhaps database functions, reporting, text handling, all the things that are kludgy with PLC's in a language that suits those jobs. We do logic, parallel functions, and the other things that PLC's do well in ladder or whatever your favorite logic solving language is. Because we can do the other stuff in procedural code, the logic portion would have fewer "black boxes" and hard to understand kludges. And we could dliminate a great deal of complexity here as we are back to basics. The logic section would run the map as it has fixed and pressing time constraints. The map would be fully accessable to the procedural code as well so it can read and write registers, with certain sanity constraints. You could start, stop, even load a new procedural program while logic continues normally. In this fashion, your PLC has the power of literally anything you can do in Linux. And that makes it certainly the most powerful PLC in the world. And your procedural code can monitor, supervise, communicate and do things in sync with the outside world while the logic section takes care of business. I am doing this already in C. What I think would be great would be if we could make an Automation 4GL for example to make this work for others who aren't interested in bit twiddling but could benefit from the power. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

B

C

#### Curt Wuollet

[email protected] wrote: > Perhaps as a step in defining such a thing it would be a good exercise to > state what are the essential qualities of a PLC are that need to be in a > Linux PLC to make it usable as a PLC (and not some other kind of automation > controller). I get the distinct impression that what is being designed is > not really a PLC. > > Some of the things that absolutely must exist in a PLC to be practical: > > RLL - an absolute must. 5 million electricians know how deal with it, but > not a text based language. Plus its a whole lot easier to understand then any > text language I am aware of. Yes. > Online data display - an absolute must for maintaining and debugging. Even my toy demo has this. > Online programming changes. Must be able to change the machine operation > without having to shut it down. this is critical in 24/7 operations, or just > to be able make slight changes w/o having to shut down 1/2 a plant. If I > need to insert a small time dealy into a sequence, i cannot afford to stop > making cars for a minute or two to recompile (a minutes worth of cars lost > will get you yelled at very loudly by the plant manager-in some plants its > worth a net profit to the company of \$10k or more and they cannot make it up). More challanging but doable. > There may be others, but these are the essentials that i can think of off the > top of my head. Note there is nothing about ethernet, data collection, > reports, graphics, or remote I/O listed. Those are all nice but without the > listed items they are of little value. The problem is I think you are trying > to avoid the RLL/online programming thing cause its not a simple thing to do. > But, I don't think you will be successful without it, and it certainly will > not be a PLC without it. No, Those things are a given and we are looking at where we can advance the state of the art and improve cost and productivity. Without "comfort tools" no one will even look at us. That doesn't mean that we can't provide a superset. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Then the challange is to find a non-homebrew way that accesses the power, is self documenting, and enforces sane and appropriate usage. The IS world uses 4GLs to do this, I think we could do much the same. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

> I can relate to what you are saying 100%. The company I work for Developed an assembly based macro language 20 years ago because they refused to work with ladder logic (rightfully so). The language and RTOS was taylored to the task at hand and therefore was simple and brutally effective. I can quite honestly say that if we were to implement our machines on existing PLC platforms that the company would not be successful and would have to scale down the scope of our machines to accommodate an inferior programming language. That is just wrong. > > Now with PC hardware being so powerful and cheap we are using that in combination with a third party soft PLC. This certain soft PLC has worked great for us compared to the alternatives, but I have found that I have spent a lot of time overcoming the problems of the system architecture rather than dealing with the task at hand. > I agree with you that conventional programming is extremely effective with dealing with machine tasks, but there are a few hooks needed, such as IO and communication. I think we both agree that this is the niche that the LinuxPLC will provide for its users. > > So I agree with you. The paradigm must change to meet the application needs. I think that an industrial-ized version of the C language is the best bet. No, I don't suggest changing ANSI C ... perhaps a preprocessor language extension to take up where C leaves off with regards to automation. > Actually, C doesn't leave off with regard to automation. I'll wager the great majority of automation is done using C in some fashion of another. I'm certain all of the tools and most of the executives are written in some form of C. And due to stubbornness on the part of certain parties, we will always be able to use C to extend LPLC :^). But, although I am enraptured with the stark beauty of unions and structs, the elegance of pointers and the raw power of the bit operators, it doesn't map well to the experience of solving logic with ladder diagrams or people brought up on drag and drop. While I choose C as my ultimate answer that lets me do absolutely anything the hardware will allow, it is not for everyone. Pity. What I am leaning towards is a chainsaw language. Not the gouges rifflers, and burnishers of the pattern and toolmaker, not the razor knife, tweezers and silk pins of the modeller, but a fast pull the rope, yank the trigger and automate language. Sort of a 4GL for automation. High level constructs like open_socket_to_IP_address. And send_this. Things like expect dialogs: Expect stx, send nak, etc. etc. Things that hide the fiddly bits with a carefully chosen set of defaults. I thought of this when I realized that an awful lot of the code I use is recycled with little or no change. I have a block of code I use to configure a serial port. If I am going to open 4 ports, I use the same block 4 times. What's in the block is the beauty of serial comms under Linux. The flags for the tty discipline, the reference to gettydefs, the termio calls, etc. But, for most work, I can use the block verbatim. If I bury the block as a function in a library and pass those few parameters I change, the detail has been abstracted. It is only one step away to build (with flex and bison) a language parser and compiler to take the token "open_port" in a user program and substitute the function call to the library. Anyone can deal with "open_port". Only C people dig ORing in symbols defined in the header file that by convention lives in the directory referenced by the angle brackets which is a macro defined elsewhere :^). 4GL's empower people through assumptions about the environment. If we can anticipate what people want to do besides ladder logic, we could make a 4GL for Automation, skipping over 3GL's that the drag and drop crowd hate. We could even do a 5GL, but I hate those with a passion and it is a step too far to access the power. >As with any design, added power and flexibility will add complexity. We will not be able to please all of the PLC Dinosaurs, and to be honest, I don't think the PLC Dinosaurs will go for LinuxPLC. I think that this project will find its niche in defining a more elegant and powerful PLC paradigm. < Yes we will have elegance for the aristocracy (and poor old UNIX hackers) AND powerful and seductive dinosaur bait. We need a stampede of dinosaurs to change the industry. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Bob Yes, it is an unfortunate truth that programmers tend to assume that everyone else knows what they are talking about. It is a result of living the technology for long enough that enormous amounts of background and detail are simply accepted as a given and taken for granted so we can build on it. This, coupled with the fact that programmers often hate documenting things is a challange. In this context, however, I am nowhere near even defining things to document. I think your comment is perhaps aimed at what we already have? If so, I agree. What is needed is for the coders to document sufficiently well for some person, with appropriate questions and access, to really understand the code. Then, this person can translate that understanding to documents that even dummies like me can understand. We have some of that, and I deeply appreciate time spent in that manner. We could always use more as it is a tedious task and a costly, selfless, wonderful, gift to the project. My own attempts at technical writing tend to confuse more than explain. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc