Design criteria are simple: make the solution work. But, when the project changes course for some reason, can your designs normally cope with it?
Are there things that we do that create less time for us? You bet there are. We re-invent the wheel, we redevelop software for a different application, we redesign hardware solutions for a another client of the same equipment because they require some obscure specification.
But it doesn't have to be that way. I tend to believe that we all attain a balance in our lives at some point due to necessity or desire, as we find different ways to do things or find special tools to do a job differently and/or better.
Sometimes I think this comes with age and experience.
Generally speaking, we do things that we are comfortable with,the "we've done it that way for years" syndrome. But, we are in a different world now and there are many time-saving tools to help us create more time for that budding career as a professional fly fisherman. It is common knowledge that most PLC/control people sit at the keyboard and start attacking their control problems. Design criteria are simple--make the solution work. But, when the project changes course for some reason, can your designs normally cope with it?
If the application is written for a given hardware platform, and if you have to change that hardware due to customer specifications, then it's back to the drawing board to redo the software.
Programming styles for control system software has as much to do with time saving as time expenditure. That's to say that the way people program either can save them time--or cost time. You've heard the cop out: there's never time to do it right, but there's always time to do it over. That's rubbish! I think most of it is an unwillingness to get out of the "comfort zone."
On the Control.com automation list, there's a consensus that PLC programming is characterized by "ad-hoc and chaotic practices." The thread is "Programming Styles" on the web site, if you want to follow it. Well, here are a few tidbits that can help get you out of the comfort zone and into the "now."
Although not exactly programming related, AutoCAD 2004 is an electrical design package created by Autodesk's recent acquisition, VIA Development. The power of AutoCAD, however, is pervasive.
Although I didn't have a lot of time (go figure) to really exercise the product, it lends itself well to creating I/O drawings. Since it is programmable, you can change horses quickly--the I/O drawings can be created in Excel, then imported. While it's not cheap, the time-saving component is priceless and hopefully obvious. I hope to provide you with better insight to the product in a later column.
Coupled with I/O drawings is the need to use those addresses in your PLC program. How do you do it now? I'll bet you use discrete addresses--absolute, as I like to call them. The addresses are hardware-dependent, and are littered throughout the program. Relative addressing can save you a bunch. The hardware addresses have to be used or accessed somewhere, but what I'm suggesting is a relative address is easier to deal with.
Modern programming tools call them symbols or tags. A tag database can take a working program and keep it working when project details change. It can also lend itself to modularized programming. You apply the hardware addresses to the working program based on the application.
You can write your program using the tags or discrete addresses, but management of the program and its components can become much more efficient.
IEC 61131 is another of today's programming environments. It uses symbols for programming, thus abstracting the I/O. It also provides function blocks as a development environment.
A picture is worth a thousand words. What better way to display a part of your process to the user than as a block with connected inputs and outputs. The user often doesn't care about the contents, just the results.
No more spaghetti ladder rungs to re-learn when a change order appears.
A machine control scheme always has partitioned control elements in the field. Putting each element into a function block not only allows easier visualization, but provides the ultimate in code and project management.
If you already haven't, do yourself a favor and investigate tags and function blocks in the environment you are currently working in. If they don't exist, then maybe it's time to re-evaluate your environment.
And save your free time!