By Jeremy Pollard, CET
IT WAS A COLD March day in Nairn Center, at one of the biggest lumber mills in Northern Ontario. I had just sold them on a brand new Allen-Bradley PLC-2/20 processor system to control an existing trimmer-sorter.
Now we had to decide who would write the software to make it work. I decided to take my vacation week to do the software project at no cost.
I actually looked forward to it. What an opportunity to actually do something with one of these new-fangled PLCs so I could tell people how to really do stuff.
A trimmer/sorter system takes planed lumber in varying lengths and cuts it to defined lengths. The board widths vary from 4-12 inches.
A wheel actuated by the board indicated the width of the board, and limit switches revealed the length, and saws on gimbal/gantry units cut the board to the desired lengths. The saw system would make the desired cuts, then sort the results on a flat accumulation conveyor, which bundled the boards into pallet lots and fired it out for the drying process.
The whole process was at least 300 feet long. The control cabinet was behind a wall, so we didn’t have a clear view of the action.
The old system, which did about 90 boards/min., was relay-controlled. There were many limit switches, motors, and I/O wired to the PLC, but we had no control prints. We had relay logic prints, but this process was imported from another location and some were missing.
We made up prints as our first step. Mitch and Barry did the wire tracing and created the I/O drawings. Sorry guys, 1980 means no AutoCAD. Heck, the IBM PC hadn’t been commercialized yet. This stuff was hand drawn on D-size paper.
The nomenclature on the drawings was many things, but informative wasn’t one of them. The guys knew the location and description of the devices, but I didn’t. So my hen scratches were all over these original drawings. Here again, there were no spreadsheets to do data import.
The I/O points were extensive: 400, both DC and AC, and the I/O cards were in the same cabinet as the PLC processor. Remote I/O was another year or so away from being available.
"There was a major oversight. How was one supposed to tell the system what boards go where, and how long they were supposed to be? Ahhh, yes. It seems we needed an operator interface."
After a few months of design and tracing and drawing, the PLC was installed and wiring terminated. There was a window of opportunity because a recession had been “declared” and the machine was down. No one knew how long we had to finish before demand required the machine back in production.
So, as always, the software guy gets all the pressure. Once the power was off, it was off to the races.
“I’ll only be a couple of days,” I said to my family. Of course, I was totally wrong.
On Sunday afternoon I began the I/O checkout, so I could locate the devices and discover what they did. Additional hand-written notes were to become my I/O listing.
Remember that this is my very first automation project. Try not to laugh.
There was a major oversight. How was one supposed to tell the system what boards go where, and how long they were supposed to be? Ahhh, yes. It seems we needed an operator interface.
We decided to create a panel of toggle switches to tell the system about the boards we were trimming and sorting, and where the resulting boards were to be deposited. We needed four switches for length and five for width, for each of the five bays. That’s 45 switches and we needed it done quickly. Ted, a former Siemplekamp (wood processing OEM) engineer on contract at the mill, would get the parts and build the operator panel.
It was to be directly wired into the I/O. There was no display to tell anyone what recipe the process was running, and it always was a riot when someone flipped a switch in the middle of a run. I fixed that, too.
Writing the program was a treat. The PLC 2/20 processor used a sealed keyboard programming panel called a T3. The keyboard was tactile feedback--the keys are flat and don’t travel very far. You hit the symbol of the instruction you wanted, and then put in the address. There were cursor keys to move around, and branch editing was a big challenge. A wrong cursor position and Bam! Gone. There was no “undo” key.
The program approached 800 rungs of logic, which translates into about 100,000 tactile touches, not including edits. All programming was done online, attached to the processor. Since there was no UPS, and the power quality was always questionable, program backup was <ital>really<ital> important. If a spike blew away the program, then you were back to the starting block, with nothing to show for it. So backups were done with a metal-clad cassette recorder--the most expensive device I ever played REO Speedwagon on.
As I placed the program into the PLC, I had to physically write down the rung of logic and document what the rung or group of rungs did, constantly referring to the aforementioned I/O list.
Every once in a while I would print out the program to library the result. Anyone remember the fun of a 300 baud serial printer that used thermal paper? Not only that, the paper is tough to write on.
Next, I had to document the program. This is where the idea of programming-on-the-fly came from, I’m sure. No sense writing it out first, then inputting it.
As the program was being developed, it was being tested as well. It was a very complex process, and a very big test for this recent graduate. I was passing, but my sleep deficit was growing. It was Thursday, Day 5, and if I’d had 10 hours of sleep since Sunday I was lucky. I only had a week, and the progress was good, albeit slow.
The operator interface was done and wired in, and all the I/O was tested. A lot of the program was physically written and input by this point. Testing was complete on an area basis, but I still hadn’t put a board through yet.
My troubleshooting tools consisted of viewing four rungs of logic at a time: logic that had no documentation on it, no cross-referencing, and no printed lists; just a hand-written collection of disparate information.
Contact histograms and searching tools (by address only) were the only options on the menu. It became clear that I needed to be in two places at once. The programming device had to be connected to the PLC via a 10 ft. cable. That was my leash.
I put the first board through the system and, of course, it went right into the dump bin. I had no idea why--I couldn’t see the process and the rungs of logic at the same time.
During testing, I had to start the chain conveyor to check the latency of a photocell and how fast it could respond to gear teeth. I started the contact histogram and the chain conveyor. Sleep deprivation had apparently set in: I forgot there were boards on the conveyor near the start of the process. I also didn’t see the mechanics fixing the saw gantry because of the obstructions and my inability to take the troubleshooting tool to the process. No, wireless networks weren’t an option yet.
Fortunately, the guys got out of the way and, at that point, I all but demanded a second person to help me.
By the afternoon of Day 8, we had the compete system running pretty well. There was one problem, however. The system couldn’t run faster than 60 boards per minute. That photocell that was counting gear teeth (a crude encoder) couldn’t react fast enough and had to be changed. However, it was being changed by a hired gun out of Vancouver. The job was taken away from me.
So after eight days, no sleep, many miles of walking, and 15 miles of thermal paper, I was taken off the job. Fatigue kept me from seeing the obvious (well, obvious now).
The new guy worked for 48 hours straight to get things running--seems he decided to re-invent most of the wheel because that’s the way he did things. He used at least another 15 miles of thermal paper.
How would have this project been different with computer programming software with documentation, electronic HMI, and networking? Well, I would have been fishing a lot sooner, and well-rested, too.
By any reasonable comparison, it is so easy to do projects like this now. In my next columns I want to tip my hat to the innovators who helped all of us get more sleep.
|About the Author|
Jeremy Pollard, CET, has been writing about technology and software issues for many years. Publisher of The Software User ONLINE, he has been involved in control system programming and training for more than 20 years. Browse to www.tsuonline.com or e-mail him at firstname.lastname@example.org.