The MLZ-DAQ — Madison Water Utility

banner.jpgOriginal publication date: May 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

The MLZ-DAQ — Madison Water Utility

Some of our old products were not major stars — a few were dead ends or just plain unglamorous.  One of those not-so-glamorous products was the MLZ-DAQ.  We designed the DAQ as an inexpensive, general-purpose, data acquisition board.  It was a Multibus® I board with 32 digital I/O bits, a 32-channel analog-input multiplexer, and a 12-bit analog-to-digital converter module.  It used static RAM, so we were space-limited to including only 1,024 bytes of memory.

What does make this board notable, however, is that most of the MLZ-DAQs we sold back in 1978 are still in operation — and right here in Madison!  In fact, you are dependent on a Heurikon MLZ-DAQ to meet many of your daily needs.

Like many of our early products, The MLZ-DAQ was engineered with a particular customer in mind.  In this case, it was designed for the City of Madison Water Utility.  They wanted to install a control center that would be connected to the 26 water pumping stations around the city.  This would permit the utility to monitor water pressures, tank levels, and various status signals, and to control water pumps, all from a central location.  Their system design engineers met with us and we used their specifications to design the board.

The telemetry system was put into operation in the early 1980s and has been working fine ever since.  Even though there are about 32 processors in the city’s inventory, we haven’t been asked to make any service calls or repair any processors.  This is because the city is doing their own maintenance.  That’s probably just as well, since no one in our service department claims to remember much about this particular board.

Although we only sold a few hundred MLZ-DAQ boards, that microcomputer board stayed on our price list for years.  Every time we considered dropping it, some impoverished customer, such as AT&T or Boeing, would decide to order a few.

mwu1.jpgThis is an example of the visible part of one of the city’s deep well pumps.  The water from the well pump goes into a nearby storage tank.  From there the water is pumped into underground the water mains.


How Our Water Flows

The water supply for our building comes from the old pumping station on Mineral Point Road (near the high school) or the new station atop the hill on High Point Road.  During the winter, the city pumps 30 million gallons per day to its customers — and 45 million gallons per day during the summer.  Although most of the utility’s sites have a deep well pump and a huge water storage tank, a few locations have storage tanks only.  At night, or when the overall water demand is low, the utility allows water to flow in reverse, thus refilling those storage tanks from the water mains.  Also, since the water mains are all interconnected in a giant underground grid, numerous pumping stations can be off-line or under repair at the same time — and we won’t notice.

When you turn on your water faucet or drive past a city pumping station, remember that Heurikon computers are being used to help keep the water flowing.  The City of Madison shares the honors with Oscar Mayer Foods and Cue-Nique Micro-Logic as having the oldest Heurikon products still in use.

mwu3.jpgEach remote site has a small control box that consists of one MLZ-DAQ connected to 32 optically-isolated I/O modules.  Since there are no other boards in the system, the processor’s bus interface is not needed, so the board is simply mounted to a panel using standoff insulators.  The data is relayed to the central control center using dedicated telephone lines and 300-baud modems.  Don Lautzenhiser, shown here pointing to our MLZ-DAQ, is responsible for maintaining the city’s system.

mwu2.jpgThe control center has three large CRT screens.  Two display well data for the east and west sides of Madison, and the third is used as a console for command and data entry.  Each line on the data displays represents data from one of the city’s wells.  Normally, most data is displayed on a green background.  However, if a water pressure, flow rate, or water level goes outside of certain preset tolerances, the condition is shown in red.  Other colors are used to highlight pump status information.  That’s Dennis Erickson at the controls.

NEXT MONTH:  Spilling the beans
 

The General Electric Company

banner

Original publication date: April 1992

Heurikon Historical Highlights

A series of articles for The Horizon

by Jeffrey Mattox

The General Electric Company

We worked on four interesting projects with General Electric during the early years.  Two of them were with GE’s Large Steam Turbine-Generator (LSTG) Division in Schenectady (“Bet-You-Can’t-Pronounce-It-On-Your-First-Try”), New York — a huge factory that makes steam turbines and generators for power plants.  One of their critical operations is drilling holes for coolant in the thick copper bars that form the generator rotor coils.  Due to the geometry of the generator, each layer of the rotor coil is a different size and shape, but the holes in each layer still have to line up perfectly.  GE asked us to build the equipment that would synchronize the numerical data as it was requested by the hole boring machines.

The other project with LSTG was a welding machine controller.  Most welding machines attach two pieces of metal together, but this one put down a continuous bead of chromium around critical parts of steam valves to prevent wear.

Both of those projects used our MLZ-80 processor and a CRT/keyboard controller board.  We custom-designed a heavy-duty pedestal enclosure so the equipment was protected from the dirt, metal chips, and oil that pervaded the factory.

ge_welding.jpgThink green.  This is one of the three pedestal-mounted control systems that  worked together to deliver data to a large boring machine at the GE plant.  The display controller was the same one we used for the fruit market sign control terminal, hence the special area at the top which could display extra-large characters.  GE put status messages there.  The apparatus on the top provided cooling for the unit.  It used compressed air to generate a vortex — a miniature tornado — that literally pumped the heat out of the box.

Heurikon Scores an Early Win Over Intel

Another early GE project was with their Housewares Group in Allentown, Pennsylvania.  That’s where they assembled their two-slice toasters.  Two small calibration screws on each toaster timer had to be adjusted, but the people doing the adjustment had no way to know if they were setting the screws accurately.  It could take six hours or more before the timers were actually installed in a toaster and checked, and by that time it would be too late to readjust the setscrews.  So, Ben Koltisko, an engineer at GE, having heard about our work from his colleagues in Schenectady, stopped off in Madison to see us on his way back from visiting Intel about his timer calibration problem.  After Ben described what he wanted, we offered to make the electronic controls for his timer calibration and testing machine.  We proposed a system that had features Ben hadn’t even thought of but realized he could use.  Intel, however, merely offered a basic microprocessor, and they wouldn’t do any custom work.  Because we fully understood his problem from the get-go, he gave us the order.

As with many projects, we were caught short on the schedule and had to innovate.  For example, when we couldn’t find anybody willing to give us a short turn-around on finishing our 25 small enclosures, we took the raw computer boxes across the West Beltline to an automobile-painting company — the people there were much more accustomed to repainting vehicles and doing pin stripes, but they obliged us anyway with overnight service.

ge_ttt.jpgThirty of these control boxes were arranged on a slowly-rotating ten-foot Lazy Susan.  A toaster timer would be loaded into a fixture (not shown) and the controller would cycle the timer through a complete toasting cycle as the Lazy Susan turned.  An LED indicated if the timer passed all tests, otherwise the single digit LED displayed an error code.  An infrared LED at the rear sent serial data to a host computer, once on each revolution as the controller box passed under a IR receiver.

The project was a definite success.  After installing the new equipment, Ben said their calibration and test yields rose from 73% to 93%.

The interesting part about a toaster timer is that it has to account for the residual heat inside the toaster so that the second and third toasting works as well as the first.  No small trick.  The mechanical timers were really two-cycle thermostats.  When you started toasting, a bimetal strip was heated to a set temperature by a special heating coil.  When that set temperature was reached, the thermostat clicked, the special heater went off, and the thermostat cooled down.  After it cooled sufficiently (to the second setpoint), it triggered the pop-up solenoid and stopped the toaster.  That click you may have heard when your toast was almost done was not just a warning for you to get ready with the butter knife; it was actually part of the timing operation.

A few years ago, GE’s Housewares Division was purchased by Black & Decker, and the toasters are now sold under that name and made in Taiwan.  The reassuring timer click is defunct, too — probably the result of having gone solid-state.

The Versatron Toaster-Oven

Our fourth GE project was for another toaster-like product, called the Versatron Toaster Oven.  It had a control panel with an assortment of buttons, levers, rotary switches, neon indicator lights, and audible alarms.  Our task was to build the computer controls for sequencing a pneumatic machine that would fully test all functions of the control panel, including the switches, lights, and alarm.  The operator loaded a Versatron panel into the machine and the tester grabbed hold of the switches and went through a sequence of tests, monitoring the panel’s outputs, lights, and alarm.  The unit even had a bed of nails, much like our Genrad.

The machine took about 45 seconds to test one panel, and the mechanism clicked and clanked and hissed the whole time.  Very impressive.  But alas, just when we got the unit finished, GE pulled the Versatron off the market.  They had started selling the toaster-ovens before they had put a service network in place, and the ovens were not operating as planned — too many needed service.  The ovens were being returned for repair faster than GE could fix them.  So, they paid us for our work, took the testing equipment we had built, and, for tax purposes, fed the ovens and our testers to a trash compactor (ouch!).

ge-jeff.jpgThat’s me about to close the drawer on the Versatron bed-of-nails test fixture.  The tester sequenced through a wide array of mechanical and electrical tests of GE’s toaster oven control panel.  Indicator lights blinked, levers clanked, and numbers flashed — it was captivating to watch.  We didn’t have an air compressor, so we used tanks of compressed air to run the fixture’s mechanical actuators.

NEXT MONTH:  Monitoring Madison’s H-I-J-K-L-M-N-O supply.
 

How Programs Were Made in the Old Days

banner

Original publication date: March 1992

Heurikon Historical Highlights

A series of articles for The Horizon
by Jeffrey Mattox

How Programs Were Made in the Old Days

We wrote our first lengthy microcomputer programs using the computer at the University of Wisconsin’s Computer Science Department.  We purchased the computer time, paying by the minute of CPU usage.  We started by reprogramming their mainframe’s macro assembler so it would understand Intel 8080 instructions.  When we had an 8080 program to assemble, we punched a deck of about 2,000 cards, fed the cards in via a card reader, and went to a Teletype machine where we punched a long paper tape of the resultant 8080 object code.  To be more accurate, we “submitted” the deck at the computer room window, waited overnight while the job was run (the night-time rates were cheaper), and then we made the object tape.  If one of the cards had a typo, it took us another day to fix it and rerun the job.  That type of interaction with a computer was called “batch” mode, and it was frustratingly slow.

We brought the paper tape back to our office and read it in on our ASR-33 Teletype machine.  The data went into RAM, and then we made a ROM copy.  Sometimes the tape would break or the teletypewriter would skip a sprocket and the program wouldn’t work — it was a very unreliable system.

Patchwork Quilts

After we tested the program, if we needed to change even a single line of the source code, we had to edit the card deck and repeat the whole process.  To avoid doing that for simple changes, we would frequently just “patch” the ROM version of the program by manually changing certain memory locations in a RAM copy of the program.  Manual changes to 8080 and Zilog Z80 programs were easy to do because the eight-bit machine-code formats used by those chips were simple to memorize.  After making many patches, however, our programs would become impossible to maintain, so we ultimately had to go back to the punch cards and clean things up.

Since we were writing machine-language programs (not BASIC, FORTRAN or C) and had only a limited amount of space in the small ROMs, we’d frequently hand-assemble the source code modifications we were planning and figure out on paper if the total number of bytes we were adding (less those we were removing) would overflow the ROMs.  If we had too many bytes, we went on a search-and-destroy mission, looking for parts of the program that could be streamlined or eliminated.  This resulted in some very interesting, but highly convoluted and hard-to-maintain code.

The Teletype machine ran at only 10 characters per second, so a lengthy dump was very time-consuming.  The first thing we wrote was a monitor program for the 8080 that allowed us to type commands to the Teletype so we could read and write memory locations.  We called it “RAID” for Real-time Assembler and Interactive Debugger — it was supposed to kill-bugs-dead.  Later, when we modified the monitor to work with Zilog’s Z80 chip, we renamed the program “ZRAID.”  (That monitor served us until the 68000 came along — then we wrote Hbug.)

Instead of having an RS232 voltage-level interface, teletypewriters used a 20-milliampere current loop, so our early microcomputer boards had a current loop I/O circuit.  Most microcomputer manuals explained how to rewire and connect a Teletype machine, and many early CRT terminals had a current loop option.

Teletype Mechanics

If the Teletype would act up, we would have to stop our work, get out our tools, and try to fix it.  Pete Berbee and I once spent a whole day just trying to adjust a greasy camshaft in the damn machine so it wouldn’t print gobbledegook — and we never did get around to doing any useful work that day.


shopThis is an example of our development environment. The Teletype machine (right) was connected to the processor board in our main computer system (center), which was temporarily wired to the equipment we were designing (left). We used the switches and lights on the development system to enter the initial programs, loaded a paper tape program through the Teletype machine, and then typed commands on the Teletype to test portions of the program.  When the program was finished, we programmed ROMs and installed them in the customer’s equipment.

Through the surplus market, we came across an old seven-track magnetic tape machine.  Using trial and error on a I/O connector, we figured out how to start and stop the tape motion.  We wrote a short bootstrap program to control the tape machine.  (The bootstrap had to be read into memory from paper tape).  This allowed us to save large programs and quickly reload them a day or two later.  The tape machine roared like an industrial vacuum cleaner when it was running.

By the end of the 1970s, Digital Research had produced the CP/M operating system, which we quickly ported to our MLZ-80 board.  CP/M gave us our first in-house capability to edit and assemble programs for our hardware.  The glory days of the Teletype were ending, and we cautiously invested in our first CRT terminal.  Our MLZ-80 had 4,096 bytes of RAM, which was just enough to load the operating system, and was the first Multibus I card in our market to include a floppy disk controller.  A separate 32-kilobyte RAM card was needed, however, to run any programs!

NEXT MONTH:  Toaster-master General.

Cue-Nique Micro-Logic Manufacturing, Ltd.

banner.jpg


Original publication date: January 1992

Heurikon Historical Highlights

A series of articles for The Horizon
by Jeffrey Mattox

Cue-Nique Micro-Logic Manufacturing, Ltd.

For a few years, we were in the point-of-sale business.  Our customer was Jerry Briesath, the owner-operator of Cue-Nique Billiards, “Home of The Pool-School,” right here in Madison.

Jerry wanted to build and resell computer systems that would keep track of information about parlor patrons and show the status of each table at a glance.  When a billiard-player customer comes to the checkout counter to pay his or her bill, the table usage time and bar tabs have to be tallied.  Sometimes players have changed tables or are leaving before the other people at their table are done playing.  Rates vary by time-of-day, and there are lower rates for groups or special occasions.  Check-out can be complicated, so it is easy for employees to make mistakes and ring up incorrect charges.

When he came to us, Jerry was desperate to get his idea to market, but he was a bit apprehensive because he had already spent some of his money and had received nothing useful in return.  Jerry showed us the previous attempt somebody had made to build his system.  It was an unfinished “Box-o-Parts & Wires” — it didn’t come close to working correctly.  Could microcomputers really do the job?

Heurikon Comes To The Rescue!

Yes.  We designed a sleek point-of-sale terminal for Jerry — the prototype used our MLP-8080 microcomputer board (what a workhorse!).  We built a front panel circuit board that included table status LEDs, a small keyboard, and numerous seven-segment data displays so the operator and customer could see table usage times and the dollar amounts owed.

cueNique.jpg This is our original Cue-Nique microcomputer system.  The display panel has an “in-use” LED for each of 48 tables, and the operator could call up billiard table (or bowling lane) data by punching in the table (or alley) number.  The keylocks enabled “management” functions, such as the ability to change rates or access the daily and weekly usage totals.



Although the MLP-8080 board added cost to the prototype systems (because we also needed the keyboard/display board and a bus card), using it allowed us to save time on the design.  The MLP-8080 was attached piggyback-style behind the display board using threaded standoffs (instead of card extractor levers) and a two-slot bus card that plugged onto both boards at the other edge (so, instead of the bus card supporting the main circuit boards, the two main boards held up the bus card).  It was a weird-looking sandwich of circuit boards.

The system also controlled an external relay box that was connected to the lights above each billiard table — whenever a table was “in use” the appropriate table lights automatically came on.  Later, we added bowling alley capabilities that kept track of shoe rental charges and counted frame pulses from the pin-setters.

After building 15 prototypes, we redesigned the system to reduce costs and to eliminate the need for a fan (which usually sucked in more street dirt than cool air).  We put all of the electronics on a single PCB and incorporated a high-tech, new-tech switching power supply.  We learned a lot more than we had anticipated about the high levels of electrical noise that switching power supplies could produce; sometimes the 8080 processor would go berserk for no apparent reason and send gobbledegook to the display instead of table data.

Lessons In Conceptualization

Working with Jerry was a lot of fun.  He knew what he needed, but he was usually vague on the details.  He came to us with general concepts of how the machine should operate, then we made a few specific implementation suggestions, to which Jerry would say: “Yeah, that sounds pretty good — make it work something like that.”  After a few days, Jerry would often call back and ask if we could add another feature or two, “but only if it wasn’t too much work.”  It was a very loose style, but it suited us, too.

Dennis Paton joined us as we began production of the Cue-Nique units, and we kept him very busy testing and debugging the assemblies.  Then, as now, Dennis always kept a beautifully neat work area — in a pinch, we could always find a needle-nose pliers and wire cutters neatly stored in his top drawer.  When we moved out of the West Badger Road basement, I recall seeing Dennis’s heel dents and footprints on the wall where his bench had been located — the dents are probably still there.

queNique1.jpg Jerry Briesath was such an eager customer that he would often come over and pack his own order.  The reception desk at our West Badger Road office doubled as our shipping and receiving department.



Jerry spent much of his time going around the country peddling his computers.  Since he operated his own billiards parlor, he already knew many potential customers, and he certainly understood their needs.  Jerry wasn’t alone in the market, however, and his competition was tough.  When it came time to build the next batch of machines, we were unable to quote low enough to suit Jerry, so he took his business to another (lower-cost) manufacturer.  The fundamental design and style remained the same, however.

We later found out one reason why the other guys were able to quote so much lower than we for an identical product.  Many of the components they used were low quality.  Some of the capacitors, for example, had a shelf-life of only a few years.  Later, the computers started to fail and Jerry had to replace those parts.

Despite those setbacks, Jerry’s computers have been a big hit — he currently has hundreds of them out in the field.  Some of them might even be part of the 65 we built (Jerry isn’t sure).

Jerry’s Dream Lives On

Today, Jerry is developing a modern version of his system, one that runs on an IBM-PC with an attached cash drawer.  Using this new approach, Jerry can sell software packages world-wide.  The fellow doing his programming, Chris Madsen, worked for us back when we were building the first Cue-Nique systems.

By the way, Jerry is a world-renowned billiard player and instructor.  It’s a real treat to see him run the balls and perform trick shots.  He worked as a technical advisor on Whoopi Goldberg’s made-for-TV movie, Kiss Shot.

Next time you’re in town near State and Gorham streets, stop in at Cue-Nique Billiards and ask for Jerry.  Say “ ‘Hello’ from Heurikon” — maybe you can hustle a free coke.

MARCH:  We sing the Teletype blues.

loc_basement4.jpg We all wore many hats in the early years.  For example, Chris was a mechanical draftsman, layout artist, sales and marketing manager, purchasing agent, or corporate president, depending on which way he turned his chair.

loc_basement5.jpg Office space and phones were in limited supply at our West Badger Road location.  Programmer Chris Madsen, shown here, has temporarily taken over my desk.  The interior windows overlooked the drafting area.

 

Sonic Boom Lines

banner


Original publication date: February 1992 (But it should have been done in April. :-)
Heurikon Technical Hallucinations

Sonic Boom Lines
by Jeffrey Mattox (Copyright 1992, 2009)

On maps and globes of the Earth, the locations of the equator, the Arctic and Antarctic circles, and the tropics of Cancer and Capricorn are clearly shown.  These circles indicate certain characteristics of the apparent journey that the sun makes over the Earth’s surface each year.

There are two other conjured circles on the Earth’s surface that few people know about.  They are called “sonic boom lines,” and they indicate the latitudes where the Earth’s surface velocity is equal to the speed of sound.

Breaking the Barriers of Credulity

You know that an aircraft produces a boom whenever it accelerates above the speed of sound (approximately 760 miles per hour at 57°F).  The window-shattering sonic boom that occurs when the aircraft “breaks the sound barrier” is caused by an atmospheric shock wave that extends from the aircraft to the ground.  We rarely hear sonic booms today because FAA regulations prohibit all aircraft from flying at supersonic speeds over inhabited areas.

However, despite FAA and public desires, the rotation of the Earth causes many parts of the surface to spin at velocities that exceed the speed of sound.  Since the circumference of the Earth is roughly 24,000 miles, the surface speed at the equator due to the rotation of the Earth is about 1,000 miles per hour (well above the speed of sound).

mathUsing simple trigonometry, it is easy to compute the latitude where the Earth’s surface is moving at precisely the speed of sound (see figure).  At sea level and zero degrees Celsius, that latitude is 44 degrees, 21 minutes, and a circle drawn around the Earth at that latitude is a sonic boom line.  Of course, there are two such lines; one in the Northern Hemisphere, the other in the Southern Hemisphere.

Unlike the equator and tropics, the exact locations of the sonic boom lines vary according to local altitude and air temperature.  For example, using Heurikon’s altitude (978 feet above sea level) and average atmospheric conditions (11.83°C), the sonic boom line moves to 43° 04' 55" north latitude.  Although these effects are very small, they are enough to make the exact locations of the boom lines laborious to determine and in continuous flux.  That is why cartographers refuse to put these lines on their maps.

Cone Heads in Our Nether Regions

Technically, the sonic boom lines are the intersections of an imaginary cone with the Earth’s surface.  That cone (the surface of which represents all points that are rotating at the speed of sound) extends parallel to the Earth’s poles and pierces the Earth at the two sonic boom latitudes.  The supersonic atmospheric regions that are directly above locations on the Earth’s surface that are themselves outside (but near to) a sonic boom line are called, curiously, the “nether regions.”  Those small areas dissipate the sonic boom shock waves into outer space, thus preventing the shock waves from causing a continuous, annoying boom to listeners on the surface.

The Earth’s motion around the sun and the sun’s motion through the cosmos do not affect the sonic boom phenomenon nor produce one of their own.  This is because sound waves cannot travel through the vacuum of outer space.

lobby Heurikon Hyperbole

If you examine a map of Wisconsin, you will see that the northern sonic boom line comes near to the Madison area.  In fact, the altitude- and temperature-adjusted line (at 43° 04' 55") goes right though the center of our building, piercing the flagpoles, front doors, central corridor, rear doors — even the picnic table.  The wide maroon stripe in the middle of our lobby carpet lies directly over the boom line!

Is it merely a coincidence that our building straddles the northern sonic boom line, and should we be concerned?  Dunno.  Go figure.
 

From the Desk of Chris Karle: Friday, 27 March 2009

From the Desk.jpg


 

It is time for a few more of us to detach from our moorings here at Emerson and begin our drift apart.  I would like to sincerely thank all my friends that I have worked with here.  I truly believe the people here is what kept many of us from looking for new careers sooner. 

I have decided leave engineering and pursue a career in <drum roll>… DEATH DEFIANCE!  I have already performed a few shows.  In order to increase interest, I am including a few photos from these past events.

 

Bear Wrestling.jpg


In a Barrel.jpg


Cannon.jpg


 

Thank you.

This has been a: Chris Karle present a Joyce-Karle Production.

 


Joyce Karle.jpg


Oscar Mayer & Company

banner


Original publication date: December 1991

Heurikon Historical Highlights

A series of articles for The Horizon
by Jeffrey Mattox

Oscar Mayer & Company

Going to visit a customer’s site to install a computer?  You just haven’t lived until you’ve had to slug your way through an endless moving line of 400-pound hog carcasses that are hanging by their toes in various states of, ah, “disassembly,” while you simultaneously fight the urge to look around out of fear you might actually see something — the other times you did that (look around) your eyes found a room full of organic swine horrors, like dangling pig heads, piles of steamy-fresh stomach parts, and vats of other mysterious entrails.

Oh, sorry — were you eating lunch?  Let’s back up and start again.

hogs This was an assembly line in reverse.  Each hour, hundreds of hogs lumbered along a winding overhead track while the Oscar Mayer meat cutters took them apart.  The carcasses spent the night in a refrigerated room and were converted to sausages (or whatever) the next day.

Bringing Home The Bacon

Our second major project was with Oscar Mayer & Company.  In the late 1970s, Oscar Mayer was still slaughtering hogs here in Madison.  After the hogs were dispatched, the eviscerated carcasses moved past a workstation where two people (called “graders”) keyed in quality values for each carcass.  An electronic scales provided the hog’s weight, which was recorded on paper tape along with the grade information.

Twice each day, the paper tape was gathered up (sometimes off the floor) and fed into their IBM mainframe computer.  Oscar Mayer used the hog data as feedback for their buyers and to compute the payments for the farmer-producers.  The hog data was also passed through a selection matrix that would turn on certain indicator lights, thus telling the graders how to mark the carcass.  The marks indicated how the meat should be most profitably cut — as in bacon, baloney, or ham.

The Hot Carcass Data Acquisition System

Mike Werlein, the project engineer at Oscar Mayer, originally just wanted to replace their old mechanical stepper switches with an electronic version.  But, when we saw their existing system (a hideous mass of switches, relays, and noisy paper tape punches), it was apparent they needed much more than just a simple stepper replacement.  So, we proposed an electronic replacement with a modern eight-inch floppy disk drive (to temporarily store the hog data) and a modem interface (so the data could be sent directly to the mainframe).

The first electronic system used our MLP-8080 microcomputer board (as usual) and was installed at the Oscar Mayer plant in Davenport, Iowa.  The box was about the size of a large microwave oven, mainly because it included a huge Shugart floppy disk controller board that was as big as the cabinet’s cover!  Today, that functionality is on a single chip.

ott Dan Ott brought his modem over from Oscar Mayer’s information services department and we spent a few days deciphering the IBM communication logic.  Our original wire-wrapped microcomputer development system is on the table at left.  You can see the rows of toggle switches and lights we used to control and monitor the address and data signals.


After the Davenport system was operating, they asked us to build three more, but they wanted a backup disk drive, the ability to manually input and modify the grading matrix, and a few other bells and whistles.  This time, we proposed a full rack of equipment and a custom software package.  The most unusual aspect of the new design was that the stainless steel data entry keyboards and displays had to withstand attack by greasy hog fat and direct hits during the daily steam cleaning.

rack Our “fancy” hog scale system included an ASCII keyboard and CRT so the operator could configure the system and view hog data statistics.  The system had two data entry keyboards, each with a small keypad and a set of armored toggle switches.


Our First Taste of Crow

We had planned to write the application code for the hog scales in BASIC, but first we needed to write a BASIC interpreter for our MLP-8080.  That, however, turned out to be a horrendous task.  We spent all of our development schedule working on the interpreter, never quite getting it right, and had no time left over to write the hog program itself.  After a few months, we convened a meeting at Oscar Mayer, and Chris and I told their project team that we made a big mistake in our planning, wanted to start over on the software, and would they please wait for us and not cancel the order, thank-you, OK?

The Oscar Mayer people had a brief private meeting, after which one of them asked: “So, how much more will this cost us?”

Whew!  That was a relief.  We feared they would just kick us out and cancel the project.

“Nothing more, same price,” we said, wondering if our original quotation might have been a bit too low.  “This was our mistake and we’ll stand by our quote.”

“OK, fellows, go do it.  And, please get it right this time!”

Good Recommendations

A few months later, we were pursuing other customers who asked us for some references.  Figuring one happy customer would beget another, I called Mike and said, “Mike, we’re wondering if you would be willing to be a business reference for us.  May we give your name to our prospects?”

We were still behind schedule on the Oscar Mayer project, but they were happy with the work we had done to that point (one of the units had been installed was working fine), and they would certainly want to help us stay in business.

“Sure,” Mike said, “I’d be happy to talk with them.  Let me get your file.”  There was a pause as Mike rolled his chair over to his file cabinet.  “Let’s see,” he continued, “where did I put your file?  Oh yes, here it is — under ‘d’.”

I asked Mike why in the world would he put his Heurikon file under ‘d’.

“‘D’ — for disaster, of course!”

Well, he must have given us a good reference because we got the other business — and eventually more from Mike, too.

More of our fancy hog scale systems were installed at the Oscar Mayer plants in Perry, Iowa, and Beardstown and Momence, Illinois.  (Madison never got one.)  The Momence unit is still in operation, which might make it the oldest Heurikon system still in use.  But, alas, Mike says they plan to retire the hog line there at the end of this year, just as they have already done at the others.

NEXT MONTH:  O-P-Cue-R-S-T, or how we learned to cue up.

[SIDEBAR]  Pranksters at Oscar Mayer   One day, while installing our equipment at their Beardstown, Illinois, plant, I returned from lunch and found a few dozen hog eyeballs stuck to our keyboard enclosure.  They were round, white, and (apparently) sticky — I think they were still warm.  I did my best to pretend that nothing unusual was going on — as if I had to work my way around eyeballs like that all the time back at the office.  Out of the corner of my eye, however, I could see the burly meat cutters (swinging knives with one hand and wearing steel-mesh gloves on the other) glancing over at me and enjoying a good snicker at the expense of the city dude.
 

Our NORAD Computer

This is one of my all-time favotire newspaper stories.  It's all true.  This appeared on the FRONT PAGE of The Capital Times -- September 29, 1983.

norad1 norad1

In The Spotlight - Dennis Paton

From the Heurikon Horizon, February 1992

Dennis Paton

Arrow Sign Company Inc.

banner


Original publication date: November 1991

Heurikon Historical Highlights

A series of articles for The Horizon
by Jeffrey Mattox

Arrow Sign Company Inc.

Our first product development contract came from the Arrow Sign Company Inc., a Chicago advertising firm.  Arrow’s Bob Scadron heard about us from a Madison-area relative who knew we were one of the few companies venturing into the new world of micro-computers.  Bob drove up from his office one day and asked us to quote on building the computer controls for outdoor advertising message boards, very much like the one American TV has in front of their store today.

Bob agreed to provide the lamps, sockets, and sign panels, but we had to figure out how to wire and control over a thousand light bulbs, and make the display show words using special visual effects.  We were a low-overhead three-person operation back then, so our quote (only $3,500 for the engineering and $5,782 for the hardware) was attractive.  We signed the contract in early 1975, just a few days after moving from Chris’s basement to a “real” office at 700 West Badger Road (another basement).

check


Our premier product development contract is made official as Bob Scadron hands Chris a check for $1,500 — our first advance payment for a system design project



Arrow ordered five signs; each was to have two faces (one for each traffic direction) consisting of two giant dot-matrices of lamps (7 rows by 72 columns).  Bob also made us promise not to build signs for anybody else for 15 years.  Let’s see ...

Do-It-Yourself Purchasing

For the control unit, Chris designed an elegant CRT/keyboard terminal, complete with dark walnut side panels.  Chris usually handled our purchasing, but when it came time to get a CRT for our terminal, John Burdick simply drove down the road to American TV and bought the cheapest portable black-and-white television set he could find.  We removed the case, unhooked the tuner, and mounted the guts in our own enclosure.  (In hindsight, maybe we should have left the tuner connected — we would have had the industry’s first combination data terminal and TV set!)

The microprocessor was an Intel 8080 running on our MLP-8080 board (described last month).  We designed a special 16-line by 32-character video display controller that could also display a duplicate image of what the outdoor sign was showing in a dot matrix area at the top of the CRT screen.  As usual in those days, we wire-wrapped our prototype designs (in this case, the display controller and memory expansion boards), so we could easily make changes.  Today, we still use the same green wire for our ECOs, but back then most changes were just put onto our boards with the rest of the wires.

The electronics at the sign itself consisted of timing and control circuits, latches for the lamp data, and a triac (an electronic switch) for each lamp.  We designed a high-speed communication interface so one coaxial cable could transmit data to the sign in real-time, and we figured out how to transmit nine-bit data using an eight-bit serial chip.  John came up with a shrewd way of isolating our electronics from the high voltage lamp circuits; we wound our own small pulse transformers.

Pete


Pete Berbee came on board as we were building the lamp control circuits for the second or third sign.  Pete’s first job was to assemble and test a batch of sign control boards.  Here we see Pete getting acclimated to Heurikon’s highly organized WYSIWYG (“what you see is what you get”) inventory system.



I wrote the application program in assembly language, one line per CPU instruction.  It had a real-time portion that was in charge of computing the lamp states for each new image and serially transmitting the data to the sign at the right instant.  A background task allowed the operator to type in and edit the message text and specify transition effects (e.g., travel, wipe, scroll), transition speeds, lamp brightness, and so on.

One unique application problem we solved was keeping the messages readable when they were traveling across the sign.  As the lamps were turned off, the long-life filaments faded out slowly, so moving letters appeared to smear unless we temporarily reduced the brightness of the lamps.  The sign at American TV works that way, too.

Pete


The sign panels took up the entire length of our shop and nearly half of our benches.  Two-thirds of the panels are shown here (at “10:26:59” one morning).  The control terminal is on the table at right.


During testing, we would often turn on the sign in our shop to check the operation of the lamp drivers.  However, if we tried to activate all of the lamps at the same time, the system would consume over 30,000 watts of power and trip the main circuit breaker.  As we approached the power limit, the power lines in the wall would hum, and the room temperature would rapidly shoot up past 100 degrees.  That was fine during the winter months since we didn’t have any heat in the office (the heat we did get came through the ceiling from the apartments above), but it wasn’t much fun in the summer.

When “ROM” Means Remember-Only-Momentarily

One of our most nasty technical problems was with the ROMs.  Unknowingly, we had been shipped a batch of defective parts from National Semiconductor.  The read-only-memory chips either wouldn’t program completely or they’d get a bad case of amnesia and lose their contents after only a few days — and National denied it was their fault.  After weeks of frustration, National finally admitted that other customers had complained, too.  They checked their records and found they had shipped us parts from the reject pile.  We learned that big companies could make big mistakes.

picker

In the early years, sometimes we engineers had to perform hazardous duty.  Arrow used this cherry picker (inset) to service the sign and deliver me to the outdoor panels.


The prototype sign was installed at Jerry’s Fruit Market, not far from Chicago’s O’Hare airport.  When we tried the sign at the site, the lamps would randomly flicker or not come on at all — it looked awful.  While Bob paced, we huddled.  Soon, we figured out what was wrong.  We had used the single-phase power circuits in our Badger Road office to test the sign.  In Chicago, however, the power was three-phase and parts of the sign were connected to different power feeds.  As a result, the brightness control logic had the wrong timing reference.  To fix it, we had to rework our timing logic and rewire part of the sign.

 

Made to order


Fruit baskets (and signs) were “made to order.”   This was our first electronic sign installation, at 7901 North Milwaukee Avenue, in Niles, Illinois.  A Heurikon terminal located inside the store at the customer service counter controlled the sign.


Satisfaction and Success

It was exciting to watch the sign operate, knowing that Heurikon was responsible for the entire system from keyboard to lamp.  The sign was highly visible, and it performed an obvious and valuable service.  One otherwise ordinary airplane trip was made memorable when we flew within easy sight of the glowing sign while approaching O’Hare.

Although its original design life was five years, the fruit market sign helped sell apricots and strawberries for almost 13 years.  As I look back, this was our “premier” systems project.  It came early in our history, and it embodied all of the interesting and good things we’ve ever done.  We solved many electronic, mechanical, manufacturing, and business problems while designing and building the signs.  I visited the fruit market sign occasionally during the ’80s; each time it was like seeing an old friend.
Our first big project was a success, and that gave us the momentum to go on to others.

NEXT MONTH:  Heurikon goes hog wild.
 

Syndicate content