A Retrospective on 35 Years in Automation

A Retrospective on 35 Years in Automation

Having recently celebrated my 60th birthday, as well as 30 years with Matrix Technologies, I thought the readers might just be willing to indulge me in a bit of reminiscing about the changes I’ve seen in the automation business. Depending on your perspective, you may say, “Hey, I remember that!” or ”Dang, this dude is old.” Either way I hope you’ll enjoy the trip.Process Control

When I first started at Matrix in 1984, we had one computer. It was a shiny new IBM XT with a 10 MB (that’s 10 million bytes, not a typo) hard disc that would store all the files you might ever need. It had two 5¼-inch floppy disks for transferring information on and off the hard drive. We had a sign-up sheet posted near the computer workstation where you could schedule your time (in 30-minute increments) to use this marvel of technology. Today it’s pretty common to find a disc of 2 terabytes (TB), or 200,000 times the XT.

The first PLC project I worked on used a Reliance Automate 32 processor. It had many advanced features, like the ability to write user functions in BASIC, two-point input/output (IO) modules that were remove-under-power. It used a Star-Link cassette tape recorder to save and load programs. Programs were typed into memory directly for testing and operating, based on your handwritten program notes. Don’t forget to save it to the tape when you are done!

In the early years, Modicon was the market leader in programmable logic controllers (PLCs), and had the first redundancy unit allowing two PLCs to be used to keep the process running in the event of failure of one of them. The Modicon 584 was approximately 2 feet wide x 2.5 feet high x 18 inches deep, all made of metal and pretty heavy. The redundancy unit was the same size, so one could end up with a huge panel just filled with processors. Left a lot of space for new PLCs once we were able to retrofit these years later.

Modicon also had one of the first color graphic touch display units (Modvue), to show color screens representing the process and allow screens to be built with software. This unit was also huge, with the processor in a similar box to the 584, plus another color TV monitor that plugged into it. I still recall doing a demo of this new technology for Bethlehem Steel. The Modvue would reboot every time the elevator down the hall opened its doors. Made for a very interesting sales pitch!

GE Series Six PLCs were another industry workhorse, with heavy rugged chassis. Quite a few are still out there. I recall having to program the analog outputs to multiplex signals to the output devices. We started up a machine that had a typo in the output routine, so that every eight scans of the PLC, the output card sent a full-scale signal to a hydraulic cylinder on the machine. This caused the cylinder to stroke with such force that it literally tore the machine out of the concrete and proceeded to walk across the plant floor. We were all working back in the control room when a panicked operator ran through the door making us aware of the problem. E-stop circuits worked well (fortunately) and the machine and PLC program were fixed the next day.

Remember when you had to keep track of the central processing unit (CPU) memory you were using in your program?

  • Generate a printed reference so you could mark off what registers you used.
  • Keep track of what type of memory (retentive, volatile, or global).
  • Different instructions used a different number of words. Math for example, often needed two consecutive words (and three for timers); otherwise it would overwrite the next address.
  • Hope you didn’t lose track or spill coffee on the pages.

So nice to have user-defined data types and automatic memory allocation these days!

Later models of the Modicon 884/984 series included 800 series IO. These had razor-sharp contact pads on the modules for insertion into the wiring base. On a startup I managed to remove a module and drag those contacts across my fingertips. I had to walk around with my hand in my pocket until the bleeding stopped.

Serial communications were a staple of device-to-device information transfer. These used a dedicated cable between the two devices and required compatible data rates and formats, with very little standardization in the industry. These links often took a bit of programming to get working (and a protocol analyzer). Once up and running, they were pretty rock solid, albeit slow compared to Ethernet, for example. A rate of 9600 baud (bits/second) compared to one billion bits/sec now. On the plus side, serial communications don’t need an IP address, are not prone to hacking, and don’t require any special switching hardware. They had their place (and still do) for low-speed device integration.

In the days before Microsoft took over the operating system (OS) market, there were a variety of choices depending on the hardware used. This allowed a specialization toward industry and manufacturing that is lacking with Windows. The closest thing we have today is the configurability of Linux. On the down side, each different OS required specialized knowledge and was generally incompatible with the others. Some of the old operating systems included VMS, Unix, DR DOS, OS/2, CPM and many more. Are we better off with Windows? Perhaps, but the cyber criminals make good use of this standardization and interoperability of Windows. Just sayin’.

While some of these war stories might give the wrong impression, what I remember most fondly in my work experience are the many dedicated and intelligent people I’ve worked with over the years. This includes my coworkers, customers, electricians, operators, support staff and other team members who all worked together to accomplish the goal of getting the project running. This was often accomplished under tight deadlines, cost pressure, lousy food and long hours, while missing family events and holidays. There is nothing more satisfying than going from an initial need to a well-operating unit. While there is a lot of sweat and tears along the way, one forges friendships that last a lifetime. My heartfelt thanks to each and every one of you.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our industrial automation capabilities and manufacturing process control solutions, contact Charlie Sheets, PE, Senior Consultant.

© Matrix Technologies, Inc.

Pre-Engineering Saves Money, Improves Accuracy

Pre-Engineering Saves Money, Improves Accuracy

The trend of “fast tracking” projects now bypasses the time-proven approach of pre-engineering, leading to greater inefficiencies of project execution and higher costs.

Fast track design simply started as a way to quickly execute small capital project work at the end of an annual spending cycle to spend excess money in the remaining annual budget. This year- end-excused bypass of the normal process has since become a more normal execution method due to constrained resources of corporate engineering departments and the need for quicker delivery of enhancements to manufacturing production areas. However, also integrated in the efforts to quickly bring improvements to plant reliability and production are greater inefficiencies of project execution.

The most popular approach to pre-engineering is the phase-gated approach of project front end loading (FEL)-1, 2, and 3, where some engineering is performed and estimates are improved in accuracy through each phase. This is a widely accepted form of determining capital project estimating, execution and spending.

Why pre-engineering?

There are several reasons why the pre-engineering or phase-gated project methods are important. The goal of an FEL-1 project is to generate a plus or minus 50 percent estimate, but also to perform some very basic engineering to verify the accuracy level of drawings and equipment installed in the plant. To accurately generate an engineering estimate, the engineer must know the quantities and condition of the drawings for all systems in the plant. Just simply overlooking instrumentation, piping runs or additional machinery that may have been installed or removed since piping and instrumentation diagrams (P&IDs) were last revised will lead to expensive change orders in the detailed design and construction phases of a project.

The next pre-engineering phase, the FEL-2, helps test some of the estimating and assumptions made in the FEL-1 project phase. The goal is to update some of the drawings, gather preliminary estimates, perform walk downs and field studies to reach the plus or minus 30 percent cost accuracy goal. At each gate of the project, the goal is to continue to develop the accuracy of the cost estimate and evaluate the viability of completing the project while validating the return on investment (ROI). At the end of any phase, if the ROI does not compute or the project cost continues to increase to a level that is not feasible, then it is easy for the client to decide to abandon the effort.

During FEL-3 the process is continued by performing a marginal increase in the amount of engineering to further improve the estimate accuracy to plus or minus 10 percent. Also during the FEL-2 and 3 phase, contractors can be brought in to provide information such as construction strategies or automation design architectures and new technologies that may save dollars during the detailed design process. The goal should always be to perform detailed design efforts only once, not multiple times. Any rework after the full team is deployed for detailed design project work will be very expensive. It is much more cost effective to adjust engineering directions during early FEL phases since the project teams are smaller and fewer hours are wasted.

Time is the client’s ally

The practice of starting detailed design without the proper due diligence is a setup for less than acceptable rework consequences. Gathering data in a rush and under duress of extreme time constraints, often symptoms of fast-track projects, leads to poor decision making and a reactive engineering effort. Any time the design team must react to unexpected discoveries in the field leading to change orders, the cost of a project increases.

By executing on a deliberate planned schedule with fewer resources, the accuracy of what needs to be done can be determined leading to an efficient detailed design phase. A result of having a well-executed detailed design project can also be having a better prepared construction effort. Any rework will cascade cost changes down the line in the current and sequential project phases. The goals should always be to engineer once with high quality and accuracy for the most efficient implementation. Being methodical by starting projects with a pre-engineering effort is the best way to obtain these goals.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our manufacturing operations management capabilities and manufacturing process control solutions, contact, Mark O’Connell, PE, Associate Director of Capital Project Planning.

© Matrix Technologies, Inc.