Warehouse Automation With Personal Computers
Timothy Stryker, Pompano Beach, FL
While this is not a home application – it does demonstrate the capabilities and sophistication of today's personal computers. This is the story of how a Commodore 8032 runs a large warehouse.
Maybe you use your personal computer for balancing your checkbook, or maybe you use it mainly for playing games. Maybe you even use it to control your furnace or air conditioning system. But did you ever use a personal computer to control a sophisticated industrial automated ware-housing system? We did, and it worked out great.
Today's personal computers are sometimes belittled by professional engineers who feel that any computer suitable for home use could not possibly be appropriate for use in an industrial environment. In many cases, they are right: some personal computers are not designed, mechanically, for a great deal of wear and tear, and others have numerous games-related features that would prove less than valuable in an industrial setting. Some personal machines, however, are reliable enough, both mechanically and electrically, not ony to survive, but also to excel when used in industry. The Commodore CBM 8032 is one such machine.
The Project
Our customer originally started out with an ancient (vintage 1974) automated warehousing system based largely on hard-wired controls. The system consisted of three automatic "cranes" running along tracks in the floors of three separate "aisles," one crane per aisle (see Figure 1).
Each crane could move horizontally up and down its aisle, and had a "bed" that could be moved vertically up and down a 20 foot "mast" to reach packages at different heights (see Figure 2). Packages were arrayed in racks on both the left and the right face of each aisle, and each bed incorporated a "shuttle" which could move left and right, energizing an electromagnet when necessary to pull a package on board.
Each of the three cranes communicated, over a 300-baud asynchronous link, with a single master controller, which sent out commands to the cranes to retrieve various packages, replace others, and so forth. The packages being stored and retrieved contained bins of loose parts. The idea was to fill orders for these loose parts by bringing their respective bins to the front of the aisles, where human "parts pickers" would extract the appropriate parts and then send the bins back into the racks until the next time they were needed.
Figure 1: The Warehouse Layout
Our mission was to replace virtually all of the electronic portions of this system with modern, programmable equipment. This involved replacing each of the hard-wired control systems in the cranes with microprocessor-based hardware, as well as coming up with a new master controller, a so-called "Head-of-Aisle Terminal" (HAT).
The HAT would have to communicate with each of the three cranes, and would in addition have to communicate over a 4800-baud "bisync" line with the customer's remote IBM mainframe. Simultaneously, it would have to provide for operator input of bin requests, display of system status, diagnostics, and the like.
Figure 2: A crane, as seen from the front of an aisle, with its bed partway up its mast
We had had good results previously with a Motorola 6800-based approach to the replacement of the crane hardware, so this is what we used for the cranes. When it came to replacing the HAT, however, we were momentarily stumped. We knew we wanted a CRT console for operator input, and it had to be reliable. In addition, the computer part of it had to be easy for us to program, and it had to be fast.
We would need the ability to augment the basic system with things like special-purpose synchronous (bisync) communications hardware. We considered the possibility of using an M6800 in an EXOR-bus configuration, with a high-speed asynchronous line going out to a semi-intelligent terminal of some kind, but we realized that this would tend both to bog down the display and to overload the processor.
What we eventually settled on was, of course, the CBM 8032. This fine personal computer combines a 6502 processor, 32K of RAM, a couple of spare 2532-compatible ROM sockets, and a complete memory-mapped video driver circuit, including the CRT tube itself, in a single enclosure.
One major advantage of the 8032, from my standpoint, was that I could use it to write most of the software needed in RPL, a language of my own design that I had specifically optimized for the development of high-speed, memory-critical applications like this one. You may have seen Robert Baker's review of RPL in the February 1982 issue of Microcomputing; everything he says in that review is the gospel truth.
By using RPL, I could see that I would have the luxury of writing virtually all of the code in high-level terms, resorting to assembly language only for extraordinarily time-critical functions such as interrupt servicing, block POKEs to the screen, and the like. In addition, the use of the RPL Symbolic Debugger would allow me to test and debug the software in record time, which, since I was working on a fixed-price contract basis, was important.
So, we cut our costs significantly by making use of the machine we planned to sell as its own development system. The fact that the video was memory-mapped meant that updating of the display could proceed at processor speed, yielding instant, random screen updating without any interrupt overhead. The fact that the computer and its display were integrated in a single cabinet lessened the potential mechanical problems of upset and breakage.
Also, the 8032's "memory expansion bus" allowed us to augment the machine's built-in capabilities with boards and other components of our own design, physically located in a separate enclosure. Figure 3 shows the external appearance of the resulting HAT: sharp and professional looking enough for the most discriminating of tastes.
Trials And Tribulations
No project of this magnitude, of course, is without its share of problems. The first was that we would need at least 8K of ROM space, thus consuming the two spare 4K ROM sockets, for our control software. Not only did this consume the available sockets, but, more importantly, it also consumed (so we thought) the only remaining, non-dedicated portion of the 8032's address space. As shown in Figure 4, Commodore supplies the 8032 with 32K of user RAM occupying addresses 0 through $7FFF, the memory-mapped video display RAM from $8000 to $8FFF, and the main operating system and BASIC interpreter ROMs from $B000 through $FFFF.
Figure 3: The hat
Now, there is actually a little gap, running from $E800 to $EFFF, which the 8032 decodes as I/O space rather than ROM. It is in this range that Commodore has placed its PIAs ("Peripheral Interface Adapters", i.e., parallel I/O ports) and VIAs ("Versatile Interface Adapters", another flavor of same) for communicating with the outside world via keyboard, tapes, the IEEE bus, etc.
What we did not realize at first is that not all of the address space up there is consumed by Commodore's built-in devices: in particular, the range from $EA00 up would appear to be available for user use. By the time we perceived this, though, we had already committed to a bank-switched approach involving the $C000 ROM (why it had to be the $C000 ROM is too complicated to go into here).
Figure 4: 8032 Memory Map
In so doing, however, we ran afoul of another little peculiarity of the 8032's design, which you may need to know about if you attempt anything like this yourself. This applies whether you use the $EA00 area for I/O or not. What it is, is that the 74LS244's (8-bit tri-state bus drivers) that Commodore uses to bidirectionally buffer the memory expansion data bus are hard-wired to point in the CPU-write direction for all memory accesses to addresses $A000 and above (for addresses in the $9000 to $9FFF range, interestingly enough, this is jumper-selectable).
This leads to the disconcerting problem that, whenever you try to read from anything above $A000 on the memory expansion bus, the data comes in as garbage because the bidirectional bus drivers are stupidly driving the wrong way. Our solution to this was to jumper the direction-control inputs of the 74LS244's to a signal we generated off-board which "knew" when a read to the expansion bus was occurring and inverted the drive direction appropriately.
Another little quirk worth noting (forgive me if I'm being overly technical here, but these little insights will be worth about $2000 apiece to you if you ever get involved in this sort of thing) is that the R/W inputs to the ROMs in the 8032 are hardwired to Vcc, implying that you cannot expect a write to a ROM address to disable the ROM, or for that matter to do anything reasonable at all.
Why would you want to write to ROM, you may ask? Well, suppose you wanted to substitute a 2532-compatible RAM chip for one of the ROMs, for example? It won't work unless you jumper the socket's R/W line to the CPU's R/W line (and, of course, cut the Vcc trace while you're at it). Remembering this can save you days of frenzy and heartburn, when the time comes.
Once these problems were out of the way, the rest of the project went fairly smoothly. Figure 5 shows what the display looked like during actual operation. If you are a Commodore buff, you will notice that some of the characters in the "Bisync Communications Line" box are not part of the standard Commodore character set – this was achieved by substituting a custom 2532 EPROM for the standard character generator chip in the 8032.
This is remarkably easy to do if your character generator chip is socketed (some of the newer ones, unfortunately, are not): you just pop out the existing chip, copy it, with whatever changes you like, into a 2532 (or, if you like, a 2716), and pop the 2532 into the socket. We used a model 2704 PROM programmer/editor from Micro-Link, Inc., of Carmel, Indiana, and found it easy as pie and very satisfying at that.
Software Design
Figure 5: A Closeup of the HAT's Screen
As you can see in Figure 5, our HAT has to keep track of a fair number of things at once. In order to make the system easy for operators to control, I used the "soft-key" technique for input of commands. This unsung hero of a technique, used by Hewlett-Packard in much of their equipment, will, I predict become the standard command-input technique of the future. The idea behind it is to combine the best features of menu-driven operation with the best features of random-command-driven operation by providing a set of "soft-keys," which, in effect, present the operator with a menu of the currently allowable command options at all times.
Normally, a keyboard must be designed with soft-key operation in mind in order to be so used, but one can sometimes improvise. In the case shown here, for example, the soft-keys are the keys 1 through 9 in the 8032's numeric keypad. The little block of legends in the lower right-hand corner of the display can be thought of as appearing directly on the keys themselves, and the only difference between these legends and normal, "hard" legends is that these legends change once you have hit a particular soft-key.
For example, if you hit the "enable" soft-key on the HAT, the word "enable" is echoed onto the bottom line of the "Text Area" shown to the left, and the soft-key legends change to offer you the option of enabling aisle one, aisle two, or aisle three. When you select the aisle you want enabled, your choice is echoed to the Text Area, and the soft-key legends change again to tell you that the only thing you can now do is to hit RETURN (or CLEAR, in case you have changed your mind).
Once you hit RETURN, the command is executed, and the Text Area display scrolls up, retaining a record for you of what you did, in the king's English. Very little possibility for confusion here, especially when you consider that this arrangement makes it physically impossible for you to enter a command with invalid syntax!
A fair amount of "human-engineering" (that always sounds to me like android design) also went into the rest of the display shown in Figure 5. The "Bisync Communications Line" box acts as a continuous window onto the line connecting the HAT with its remote IBM mainframe, so that communications problems can be easily diagnosed and corrected. Bytes received are displayed here in normal field (green on black), while bytes transmitted are displayed in reverse field.
Since the HAT is on a multi-drop, shared communications line, it is "polled" in various ways by a network controller. These polling sequences cause the little circles beside the legends POLL, ACTIVATE, and DATA to light up from time to time. This ability to easily simulate LEDs, discrete scrolling windows, and so forth – as though designing a real, mechanical front panel – is one of the big advantages of a direct memory-mapped video display. I made the most of it.
The upper part of the HAT display is devoted to system status, which is logically grouped by aisle. A queue of pending bin requests is maintained for each side of each aisle, and bins currently active in each case are highlighted through the use of reverse field. Aisle mode and status are displayed in English, with highlighting where appropriate.
These fields are all continuously updated in realtime on the screen – the memory-mapped video of the 8032 makes it possible to maintain a high data rate to the tube with very little processor overhead, while the graphics and reverse field capabilities of the machine allow this information to be organized and presented in a clear and aesthetically pleasing way. The fact that the 8032's display is a full 80 columns wide was certainly a boon to us too, as you can see.
No static photograph can really give you an adequate idea of what the HAT screen looks like when the system is in operation. The bytes in the bisync window are constantly whizzing around, while the status fields for each of the aisles are continually changing as the cranes go through their paces. Meanwhile, the bin queues are constantly filling up and emptying out, allowing you to watch as each bin request gradually moves up in sequence until it becomes current.
The little POLL, ACTIVATE, and DATA lights blink on and off like mad. And, in spite of all this activity, the operator can enter commands to add new queue entries, purge old ones, enable and disable aisles, and so forth whenever he or she likes, without regard to what else the system might be doing at the time. Operating the HAT actually has a lot in common with playing.a realtime video arcade game. It's (dare I say it?) actually fun.
Everybody's Happy
There is a good deal more to the HAT, and to the system as a whole, than I have been able to address here, but I hope that this has given you some feel for what a personal computer is really capable of when pressed to its limits. The HATand its M6800-controlled cranes have been in operation for several months now and, so far, have run virtually trouble-free. Our customer reports system throughput on the order of double what it was before, and his operators are happy because their jobs are now easier and less confusing.
All of this makes my boss happy that we went with the CBM 8032, and that makes me happy because I'm the one that talked him into it. I'm also happy that I could use this project to demonstrate the viability of RPL in a highly demanding and cost-sensitive application. The next time you're designing a process control system for serious industrial use, think twice about the possibility of rounding it out with a "personal" computer.