C
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