Once in a control programmer’s lifetime

Figure 1: There was a lot of innovation and code in that little PIC hexagon.

I’m glad he asked me to get this published because now I was aware of all the control magazines. I started reading them. I had very little knowledge of PLCs or ladder logic. I became intrigued as I read each issue and learned new things about motion control, PLCs, field instrumentation, I/O, advanced process control and so much more.

Code and programming

I decided to take a job with an OEM programming Allen Bradley PLC-5 devices. My first project was a burner management system with 1,200 I/O points. My new employer did not realize I did not know ladder logic, Allen-Bradley or discrete control.

I had some quick catching up to do. This application required a lot of sequencers. I applied myself, and soon it was fun again. I was young and still had other interests. I would usually leave by 6 PM to roam the new city. But I did start becoming more aware of what a career is. And I worked late when I got in the zone. Lots of coffee, pizza and candy bars—programmer style.

Another thing my new employer had not known was how little I knew about panels, I/O components, instruments or even the controllers. Most automation and controls guys know some of that. Luckily, I had good techs available. Their disappointment was offset by the fact that my code worked well.

The techs liked the code because it was structured and commented. I did that because it helped me to revise and reuse my own code. But it was always well received by techs and others.

When comments are done as a perfunctory chore, they are often just a redundant English translation of the code. That’s a mistake. What really helps is explaining why you did something. For example, a poor comment might say: “The timer finishes, and then the adjusted weight is recalculated.”

This is not very helpful. You can just look at the code and see that. It’s better to say: “This rung is needed because without it the scan order of the routines sometimes leaves a stale value of the adjusted weight.” See the difference?

Good comments will extend the life of your systems. If there is an ancillary component such as a database, an ERP connection or a Visual Basic program, write some notes about it in the main PLC or DCS program. Write helpful notes, not a rehash of the code. Explain the roles and purposes. I sometimes outline the architecture in a few rung comments at the top of the main PLC program. Your system might not get replaced in five years if they can figure out how to work on it. I know because I worked at a place where our big moneymaker was replacing systems.

Sometimes a system was replaced because no one could work on the code. Another nice thing to do with comments is to explain parameters, drive settings, and network settings, especially if you sweat blood to figure them out. You will be doing people a favor and adding value.

Just after I mastered Allen-Bradley programming, my personal life threw me some curves. I drove out west and started over. I did manual labor, car sales and CNC machining. Then I got a job programming for a small integrator in Phoenix.

The owner fixed plant problems, and grateful customers often accepted his idea to retrofit the controls and clean stuff up. He needed a programmer. I didn’t know that. I just phoned his office on a cold call. I was invited over by his wife. I was a bit overdressed in my IBM suit, and I had to step around grimy industrial equipment on the way into the back office.

We did retrofits that developed from service calls—machines, process lines, packaging lines and just about any kind of manufacturing system you can think of. I’d learn how a machine worked or needed to work, and then I would write a PLC program and make an HMI. Chemicals, casting, cement, dairy farms, plating, food sorting, pyrotechnics, chip fabs, aluminum extrusion—you name it—with customers ranging from one-man shops to large plants. Some customers were just daring entrepreneurs who bought machines and made stuff. Others were large, well-established companies. Sometimes it was culture shock going from one project to the next.

My first project was using an SLC-500 to control fans and misters at a dairy farm to keep cows comfortable in the roiling Arizona summer. This was so they would still produce milk when it got to 110 °F. The sequence would turn cooling off so the cows would be more willing to get up and go inside to get milked, and it switched cooling to the food troughs to entice the cows to go over there and eat.

There was some other logic, too. You’d be surprised what a dairy farmer will ask for when he realizes he can. I had a little routine to predict the sun angle from a lookup table. I made an HMI that the herdsman used to change the sequence and manually operate. This was early HMI days, and this is a good example of computers starting to permeate everywhere. The next project was a plating line with a 4,000-A rectifier. Part of the controls was a standalone embedded unit with a C program. There was no source code. Out it came. In went a PLC.

Next up was the palletizer at a little place that mixed up laundry bleach, bottled and boxed it and sold it to low-cost stores. The chemicals had corroded the sensors and wiring. There’s no telling what it did to my lungs, but I was only there a few days. There were lots of those places. The smaller companies were focused on staying open and making money.

We did a complete retrofit on a Taiwanese injection-mold machine whose embedded controls board died. It had all kinds of nonstandard equipment we had to figure out. The good news was we had a manual. The bad news was it was in Chinese.

I went over to the Arizona State University library and searched for a Chinese speaker who might want to make some money. The shy, startled graduate student I picked was straight out of central casting. He was polite but wary. We had an audience, too.

I might have been tossed out soon if it didn’t go well. But the offer was too good for him to pass up. I gave him the manual and a cash down payment, and I got while the getting was good. His written English was good, and he got on it. We were building panels and programming very soon after that.

One customer bought big paper rolls that weighed about 10,000 lb. It was a family business of hard workers from Iran. They bought slitter-rewinders and a variety of machines on the used, as-is market. They made tissue, toilet paper and napkins.

There was a lot of ingenuity involved, as you can imagine. I programmed some of the machines and HMIs. They made money and eventually built a pristine new plant with a paper machine. Now they didn’t have to buy the starting paper rolls. It was an American success story.

Some places were dirty and dangerous and full of duct tape and bailing wire (Figure 2). One time we went into a casting shop where every square inch of the shop floor was coated in soot. Other places were big and clean and organized to the extreme, like an Intel chip fab or the potato-chip line at a Frito-Lay plant.

Figure 2: An arc welder on a tube mill is down and dirty but interesting and fun to get working.

Big or small, clean or dirty, these customers had things in common. Something was down and needed to get running again fast. Or they had some troublesome system they wanted to fix. Often the fix ended up being a control system retrofit. And I got to I write the new controller program and create the new HMI.

When the Net was young

Occasionally I would get to write a program for an elaborate machine. When you have motion control, vision and complex sequences you’d better like challenges, especially if the machine is no longer running and there is no documentation.

A few years ago, we got a machine with an intricate sequence and four axes of motion to work again. All we had to help figure out the sequence was a poor quality video of it running. This is not for everyone. Some jobs are easy but boring. Other jobs are stressful but interesting. Which one would you pick?

I started out pre-Internet. Cybersecurity was not a big concern for plant-floor control systems. I had complete freedom on HMI design (Figure 3). Some of my early screens look like a black-light poster. I got an alarm banner to play a .wav file of Tom Hanks saying, “Houston, we have a problem.” That lasted a couple weeks until the novelty wore off and drove the operator nuts. We were even worse than some of the gaudy Web designers of that time. We gradually learned to tone it down and keep it simple. Integration with databases and information technology was taking off. Like many of you, I remember getting a cell in a spreadsheet to display a live PLC value. This was a fun time.

Figure 3: A well-received HMI in its day might now be too colorful and busy.

The lure of embedded control

On a Venn diagram, the circle for embedded controls overlaps a little with the one for industrial automation and controls. I had been reading snippets about embedded control for years in Control magazine. The Borders bookstore in Phoenix had shelves of books on science, engineering, computers and, most of all, programming. I sometimes gazed longingly at embedded controls as fertile new ground. That’s the hardcore coder in me. But the closest I could get to them was taking them out. We did that a half dozen times.

One customer even had the source code, but it was not commented. He wanted it out of there. He was tired of hearing how hard it was to work on. We put in a PLC, and I wrote a new program. It was kind of a shame.

Our projects used PLC/HMI. That’s what sold. It would have required almost a career change for me to use things like C or ASP. I considered it. I imagined writing the guidance system for a missile or the operating system for a camera. Or the website for Orbitz. But I liked industrial controls and automation just fine. I didn’t really want to leave it. I just wanted to expand my repertoire.

I sat in the opulent café at Borders, examining books. Remember those days? After a few cups and a few hours, I picked a book (Figure 4). I then spent about six months learning and practicing C++ in my spare time. It became a hobby. That is not as dumb as it sounds because with my engineering degree and programming background, I could have clawed my way into embedded control. But I didn’t change jobs, and the truth is I only found one opportunity to use C on a project. I used .net (ASP.net and C#) to build a server-side Internet application with a client-side interface.

Figure 4: There a lot of books on coding, and they sell. There’s just something about the field.

And then there was VB

I had a much better result when I decided to study Visual Basic. I learned how to use VBA in Microsoft Office and in our HMI applications. This paid off immediately, and I’ve been doing it ever since.

Before structured text, writing certain algorithms was a lot of work and created complex ladder logic. I wrote nested looping structures in ladder occasionally. You had to watch out, or you’d set off the watchdog timer. It was hard for others to work on that ladder logic, no matter how good my rung comments were. I needed something better. I needed a way to write some routines in traditional code, not ladder. Since I’d started my career with code, being limited to ladder was always confining.

Structured text eventually solved part of this problem. But before that came along, Rockwell put VBA in its RSView32 HMI. Rockwell did this for a different reason than giving me a place to write code. It did it because VBA turned out to be a great macro language. VBA made programming all kinds of advanced functionality possible. Traditional macros were limited. VBA combined with a fully exposed object model gave us much more power. That’s what Rockwell had in mind.

But I also used it as a place to write code not amenable to ladder. The first time I used VBA in RSView32 I wrote a routine to analyze an order against some formulas and business rules. Lots of “If-Then-Else” and “Do-Until” stuff. One really great thing was you had a rock-solid driver to the PLC data table because the VBA was part of the HMI. And, in the example I just gave, I had an easy way to open a database. The VBA could operate the database just like a person and return results from that process.

But you had to know what you were doing. There were a few lessons, such as don’t prompt the user with a VB message box. That totally stops the HMI until the answer is given. Whoops.

But, if you avoided a few things, the code was not fragile and worked great. It was not an add-on part either. When you installed the HMI software at a site you didn’t have to do anything extra. For me, it was transformative. I could do complex things without creating really arcane ladder logic.

Rockwell’s tech support used to tell me the organization resisted promoting this type of use and refused to help much. But it gradually realized a lot of people were using and relying on this tool.

People do great things when they have good tools and problems to solve. So Rockwell relented. I started seeing better documentation and knowledge-base articles with good tips.

Here’s a little aside about Visual Basic. Everyone knows the significance of Microsoft owning and licensing DOS and Windows. But the story of Basic and Visual Basic is also interesting. In 1975, Microsoft co-founders Bill Gates and Paul Allen realized if ordinary people could program business and personal applications on the new microcomputers it would be a game changer. They didn’t just talk; they acted. There is a famous story about Gates hogging processing time at the Harvard computer center while he worked on his Basic complier. In 1975, he left college and started Microsoft. In 1977, nearly every microcomputer of any significance came with Microsoft Basic. Then in the early 1990s they had a similar intuition about a visual programming language and its ability to boost Windows. Microsoft married a visual tool called Ruby to Basic. Now ordinary people could make Windows applications that really worked. This is an unheralded factor in the success of Windows.

Pardon the disruption

Of course, now the PLC has structured text and object-oriented capability. That’s a better way to write code than VBA in the HMI in most, but not all, cases. I’ve been using that more and more. The object-oriented aspect in the Rockwell world is achieved by using structures and add-on instructions (AOIs). It’s not quite the same as object-oriented programming (OOP) as done in languages like C. But it’s similar from the standpoint of giving you organization and reuse tools.

Warning: traditional techs hate this stuff. They think it’s obtuse and unnecessary (Figure 5). They have a point. Always keep things as simple as possible. But, when you can program 30 burners or 90 mixers with one routine, it’s bad business and bad practice not to. I had an application with 96 mixers. I had six alarms for each. That’s 576 alarms to maintain. But only six if you use an AOI.

Figure 5: A disruptor can be an evolution or a revolution.

Once the tech realizes he doesn’t have to edit 96 routines to make a change to the mixer logic, he will become a fan. And with an AOI you can watch the logic for any specific burner. With the old subroutine method you just saw a blur since the same code was executing all 30 burners.

I’ve followed the PC vs. PLC debate for a long time. After all these years, the PLC is stronger than ever. Just for fun and a little rigor I did a quick search. Technavio forecasts a compound annual growth rate of almost 6% until 2021 for PLCs. That was a typical result.

Occasionally we would recommend a PC, but only a few customers accepted it, and they were later replaced with PLCs. I know PC technology can be put on the plant floor for control. I know they blow the doors off a PLC in some ways. I personally love PCs. They just haven’t penetrated the markets or customers I’ve had the fortune to serve.

Companies such as Cognex make devices that connect to the PLC and provide profiles and add-on instructions that are very pleasant to work with. In the old days it was different. One time we integrated a servo to an SLC over DeviceNet. It took a site visit by the servo vendor to get it all working without hiccups. The servo was a top-notch device—fast, accurate, durable—but the DeviceNet interface had variations you had to sort out from one application to another.

This situation has been improving steadily. We recently integrated an ABB robot to a ControlLogix controller. The profiles and add-on instructions worked right from the get-go. A lot of energy and innovation seem based on the PLC as a focal point.

The field of automation was great to fall into, and its future seems bright. There is a bounty of technology and applications—robots, vision, deterministic Ethernet, function blocks, the rise of servos, safety PLCs, not to mention innovations in modeling and advanced process control, the Industrial Internet of Things, which is still in its infancy, and so much innovation and opportunity.

There are some problems reported in the media, such as the aging workforce, loss of expertise and a lack of upcoming STEM talent. Diversify your skill set and interests. Who knows where the boundaries of automation, IT, embedded control and other branches of technology will be or what opportunities will exist?

ALSO READ: A walk down automation programming memory lane