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.