|
Raynes Engineering, Inc. |
|||
|
||||||
|
Control and Automation Engineering
If you’ve arrived here, you may have linked from an equipment vendor site or some technical search, and are looking for assistance with controls, instrumentation or automation engineering in some way. This page, and the Hardware and Software gallery pages, provide some specifics as to how I work with our clients and also the types of projects and work that Raynes Engineering has done over the years. Click on the sidebar links to go to pages that show examples of some of our work. Click here (or on the sidebar), for some extended reflections on important automation industry trends, which I refer to as Grass-Roots Automation. Click on the links directly below for more in depth descriptions of my control engineering approaches and capabilities. |
||
| How I Work with My Clients
I am an instrumentation and controls engineer, both at the circuit and system level, and an automation systems integrator. That description covers a lot of potential ground: to be more clear and specific about who I am and what I do, it also helps to describe a few things which I am not. For the most part, I don’t operate as a turnkey shop, with the exception of fairly small projects. I can fabricate and assemble small-scale control panel assemblies from start to finish, wired to your specifications or mine, and enjoy doing so. It usually turns out that my clients handle that portion of the projects themselves though. I think the reason is that I tend to work on projects that make improvements to existing control or automation capabilities, and often the upgrades are not clean drop-ins that can be fully assembled and tested off-site, and then delivered. A lot of “rip-out and re-configure” goes on. On many projects I do all of the detailed electrical design drawings, other times I simply review and advise. Part of my role is to be an engineering consultant, conducting technical surveys and developing recommended solutions and/or specifications, but I suspect that my involvement is not that of a typical consulting engineer. I also happen to be a top-notch troubleshooter of complex automation systems and processes, and enjoy diving "feet first" into old, often poorly-documented equipment or systems to figure out what's going on. Many of my best projects started like this - an existing system had to be reverse engineered in order to determine the "specification" for a long-overdue upgrade, which I then designed and implemented for the client. Not all consultants are willing or able to work in this manner, and when I get involved in solving a thorny problem, I like to be part of the the design and implementation team that follows things through to a successful completion. I’m not an information technology (IT) or network systems specialist, nor would I ever want to be. On the other hand, I’ve learned much about network designs and implementations over the years, and I have a good sense for how to do things in ways that don’t end-up overusing critical network bandwidth, causing unpredictable system performance. I do function quite effectively as a bridge between control engineering groups and IT departments, as I know enough about both sides of the coin to see how everyone’s individual objectives and concerns can best be met in a given situation. And then, just as importantly, I communicate the decisions and their consequences to all involved in language and documentation that they can understand and internalize. As you can probably surmise by now, I don’t usually work as a typical contract temp engineer, either. I usually do best when my clients utilize me as a part-time extension of their own engineering staff, enabling them to take on projects “in-house” with just a little (or maybe a fair amount) of additional on-and-off expertise as needed. I'm not at my best as a pure desk/cubicle jockey, but rather prefer to get my hands dirty along the way. The greatest job satifaction for me comes from the on-site start up and fine tuning of a well thought-out automation and/or process design. I always try to “bring my clients along with me”, transferring to them what I’ve accomplished and learned over the course of a project, with the intent that they can maintain and extend my work on their own in the future. I also provide continuing support for my own work over its life cycle to the extent I am able, when clients desire me to do so. In summary: I provide hardware/software design, programming and integration for automation of work cells and lines, for test and data acquisition/logging stations, and for other various measurement devices and products. I will do turnkey control panels on fixed bid, but usually my design, software and integration services are provided at a daily or hourly rate as agreed upon at the start of a project or working relationship. |
||
| Primary Technical and Platform Skills
I’m a controls and ATE “generalist”, with strong capabilities in sensor design and specification, electronic and electrical design, systems design, and software design and programming. I do quite a lot of controls programming, both machine I/O and supervisory level, using both PCs and PLCs. Left to my own devices, I normally program in Visual Basic 6, ladder logic, and/or whatever other scripting languages or web protocols are applicable or necessary for the intended environment. To me, VB6 is far superior overall for supervisory PC software when extensive user interface is needed. VB6 lives on in the industry, considering that nothing else has ever completely taken its place, and it lives on in my work due to substantial investment in VB controls libraries and general programming expertise, over a 17-18 year time span. Obviously in larger company and corporate settings, decisions have been made to move to .NET, if for no other reason than corporate licensing and support necessities. Alternatively some companies have moved away from Microsoft altogether in favor of platform-independent C++ or Java. In general, the move to XML, web services and such is making the issue of client-based languages such as VB less of a concern moving forward. Better ways to do things are emerging in the control realm. Since Microsoft insisted on killing classic VB without a suitable replacement, we developers are still finding ways to extend VB, and also to cope and deal without it as time moves on. I'm not a great fan of sequential function chart or block diagram programming, either at the PC or PLC level. I find these types of programming environments to be no less complex than script, but yet obtuse and difficult to debug. It’s usually too hard to get a broad enough view of program logic on a screen at one time, and too much of your "code" is obscured in hidden dialog box settings. For very large (i.e. plant-wide) complex control systems, the big UI software packages like RSView and Wonderware can really shine, but they seem to have been way oversold in smaller applications. Mostly they just feel big and bloated to me, making it tough to write crisp, responsive user interfaces. I’ve used some of them but can’t justify the license costs on my own. Licensing costs alone can exceed your custom applications programming costs for many jobs, and the packages are no less complex to learn and apply effectively in my opinion. If you make investments in those types of packages, you should consider whether or not you can dedicate enough key technical staff time in order to see your investment pay off. My programming education started with writing micro-controller assembly code. C programming is required for many embedded platforms, and I will use as needed. There aren't many tasks in the control programming realm that I will shy away from, with the possible exception of complex numerical algorithms normally handled by computer science specialists. I would much rather dig into a machine control programming task in C or assembler than a similar task in block diagram or function block style code. I’m skilled in detailed database design, as well as dynamic SQL querying from real time control nodes, but try to stay out of company database server implementations. Again, web services are an impressive alternative to remote SQL database connections, when transferring information between the shop floor and central data stores. Whenever a sockets connection/TCP stack is available, very little if any additional overhead is required on the client side. MySQL/PHP looks really tempting as a means to implement a department-level manufacturing data server, but I haven’t found the right situation to try it out just yet. At this point I have over a dozen years experience in implementing automation with real time Ethernet and RS-232 serial communications. I have used standard protocols through various DLL and OCX layers, and have also designed and programmed my own sockets and serial ASCII messaging protocols as needed. These real-time communications solutions have been PC/PC, PC/PLC and PLC/PLC. I’ve written my share of crazy embedded string handling and file parsing code, enabling various instruments, controllers, computers and software programs to communicate with each other in ways that no one realized was possible. Of course, it's easy to get carried away with these types of solutions, leaving an unintelligible mess for someone to try to figure out later. On the other hand, just by knowing where to place a few lines or a page of string handling and decoding logic, my clients have been saved hundreds of thousands of dollars over the years in the avoidance of expensive equipment upgrades. My hardware skills also include analog circuit and interface design, especially low-level DC to low frequency AC applications. I am a skilled sensor interface designer and have patents for temperature compensation of pressure transducers. There has been less circuit design work the past few years but my capability and tools are still there when needed. Below is a sample list of various software design tools, programs, platforms, and technologies which I have utilized effectively, both currently and in the past. I have written custom software for interfacing to hundreds of different intelligent instruments, meters, gauges, machine tools, motor controls, PID controllers, bar code scanners, etc., too numerous to mention here. Electrical Hardware Design:
General Software Development:
Automation Software Development:
Web Standards and Protocols:
Interface/Communication/Control Busses and Protocols used for Real Time Control:
|
||
| Descriptions of Past Projects
Warehouse Multi-Crane Material Load/Unload Control System This was a recently completed system of mine, involving a wide range of networked PLC and PC communications, both Ethernet and Serial. The system manages a set of four load and unload stations each, for four separate two-story material storage cranes. There are two sets of communications between the cranes and the load/unload controls, one set for hardware handshaking, another for information transfer about pallets in transit. The hardware handshake link was specified by the crane vendor as Allen Bradley Tag-based Ethernet/IP, but my client wanted the controls implemented in Automation Direct PLCs, to realize a substantial hardware cost discount. The solution was to use a small CompactLogix PLC as an EIP to Modbus Gateway. A small Automation Direct PLC handles the initial communication with the AB PLC, and then sends appropriate tag data across a dedicated Automation Direct ECOM network to individual DL205 PLCs, one associated with each crane. The informational data link to the cranes required implementation of the vendor's custom sockets ASCII protocol, beyond the capabilities of the PLCs. A supervisory Windows PC was therefore incorporated, with a communications program written in VB6. This program handles the sockets communications with the crane controllers, allows for the necessary supervisory display and control of information at that point, and then sends information to the individual station PLCs (for display on the local operator touchscreens) through a PC-PLC link implemented using the Host Engineering SDK for Automation Direct PLCs. In this system I was responsible for the entire hardware, software and user interface design and implementation, from the top level down through all details, up to the crane communication protocols that were specified by the vendor. The client fabricated and assembled the control panels on site to my engineering layout and schematics. Click on the thumbnails below for samples of some of the block diagrams drawings of the system.
PLC-Based Package Dimensional Measurement Station This next project is far simpler in scope than the one above but I chose to include it since it is a prime example of the power of Grass-Roots Automation. My client came up with the initial idea and first-pass implementation, but needed assistance in developing and refining the concept, and integrating with their shipping processes. The scheme uses three sensors (for height, width, length) to measure package dimensions. They were adopting a new type of shipping software company-wide, and we worked with the shipping software vendor to establish a means of sending the dimensions over an RS-232 link to the PC on which the shipping software runs. Since the client had started the implementation with an Automation Direct DL05 (one of the simplest, lowest cost PLCs on the market), I wanted to see how far we could take things without needing to upgrade to a more powerful processor. We needed to implement the transfer of package dimension data with a user-defined ASCII protocol: incorporating DL05 drivers in the shipping software would have been too involved. The DL05 has one limitation - its user-defined ASCII protocol only transmits and doesn't receive. This was OK, in that we devised a simple continuous broadcast protocol of the package dimensions, with a string to indicate when no package was detected. The scheme has worked well, using just over $200 in PLC hardware and modules. A $150 4-line operator text display provides machine status, through the second built-in RS-232 port on the PLC. Even using the lowly DL05 I was able to implement signal averaging and stability threshold validation using rolling V-memory buffers managed by pointers in ladder logic. I added the means to support an alternate C-More Micro touch display, which connects in place of the normal text display, for troubleshooting, calibration and tuning. |
||
