Updated documentation was bound at the end of 2000. This page was written in 2011—six years after original invoices and records were discarded.
A snapshot of Altera’s Simulation output.
Towards the end of 1999, I
quoted (218kB) on an imaging system to
measure tread width of up to two rubber strips from an extruder.
The maximum tread width was 720mm on a 780mm conveyor belt
with an accuracy of under a millimeter.
The price quoted was competitive as I was interested in image processing and industrial inspection. This would compliment motion control and automation nicely. The date of the quote was 7th April, 2000, and would have been awarded by early May 2000. The final invoice for modifications and upgrades to the subcontractor was 7th May, 2001.
The block diagram shows a side view of the tread from
the extruder moving over the glass sheet above the
width sensor. High-bright LEDs illuminate from above
to operate similar to a fax scanner.
The tread moves from left to right. There are several other items not shown before the sensor—weigh scale and some distance so that the tread had cooled down a little before reaching the sensor.
The small rollers shown to make a gap in the conveyor for the sensor might have had a steel plate similar to the previous “cut-to-length” modification; I can’t recall.
The view from above shows up to two treads (in grey so you don’t empty an ink cartridge if you print it out). The image sensors were staggered as their packages were not “end stackable”. The sensors were actually below the tread, but they are shown here for positioning. The tread was fairly close to the sensors (separated by glass for dust and heat protection). The illumination from above was directional due to the nature of the LEDs used, the drilled casing for directing the beams, and the distance from the tread. The edge would be detected in software with four different thresholds. There were 15,7 pixels per millimeter over the full width of the conveyor (780mm).
After discussing options like cameras, DSP imagers, oblique laser scanners for extracting the shape of the tread profile, required resolution and effort involved, the design quickly converged on the easiest to deliver, at the lowest price that could be replicated for spares or other plants. Industrial imagers (cameras) with a resolution of 512×512 pixels would offer less than a millimeter per pixel over 720 mm of tread, requiring multiple cameras. Each camera (excluding software development) was more than my total quote. For those who have never been through a tyre factory; they are extremely dusty places (carbon black) where cleaning optics will always be a challenge. A design similar to a fax scanner was suggested where the tread moves and the sensor remains stationery.
At the time, I tried to resurrect the MIPS VME board, but the deadlines were too short. Some time had passed between the initial proposal and receiving the order. I pre-ordered a few image sensors as these might become long lead-time components from the USA—TAOS, a spin-off from Texas Instruments with new devices. They were easy to deal with and the devices were reasonably priced in small quantities.
As a subcontractor, the official order and deposit was received long after the initial quote, leaving little time for experimentation. The effort was pretty much around the clock; schematic capture, FPGA design, simulation, board layout, manufacture, assembly, test, port of my 68000 kernel, software for the new imager board, then factory acceptance tested in under four months!
The dual tread width imager was delivered to the main contractor who was responsible for packaging the boards into the PLC panels. Initial trials used strips of tread. A terminal emulator was used to test sending the tread widths out of the serial port, as the Allen Bradley SLC503 PLC Basic card was unavailable.
The main contractor packaged the boards, which I wired up later, and then also commissioned on site when the whole extruder line was assembled on-site. The initial trials at the tyre plant involved pieces of tread as the extruder was not operational yet. The imager sent the tread width values over a serial port to a PLC to control the extruder.
The order was placed for a single set of boards, but at the
bottom of the African continent with long lead-times, I knew
better than ordering a single set from the circuit board
manufacturer. A spare set would also allow future
demonstrations that could be used in many extruder
applications (plastic coating of copper wire, etc.)
Several boards were developed:
The date on the main FPGA board was 21stMay, 2000. The simulation had been done some time back (before designing the board), but the Altera software did not print out dates.
The layout showing top and bottom layers. The power planes where internal in case I needed to cut tracks during debugging.
The above 234 x 160mm (double Euro card size) VME board featured:
Up-counters in the FPGA generated addresses for the dual-port memories. The 64-bits of imager buffers (16 quad RS-422 receivers) were multiplexed as two 32-bit values. The FPGA design used schematic capture (not VHDL) and simulation in Altera’s tools. The FPGA booted off a serial configuration ROM, which was sensitive to power supply rise time. A reset circuit modification was added from the processor board to reset the FPGA, as the VME interface was configured via the FPGA. If the FPGA did not boot correctly, then the VME bus would hang with a DTACK from the board on a processor read or write.
The date on the imager sensor board schematic was 27thJuly, 2000. The imager design was similar to a high resolution “light curtain”, using strips of high bright LEDs to shine light from the top through fittings above a perspex sheet onto TAOS sensors (768 x 1 pixel). There were no optics as we relied on similar technology to a fax scanner with the tread close to the image sensors. There were approximately 15,7 pixels per millimeter with the sensors staggered to cover the full area (could not be stacked "end-to-end"). An accuracy of 1mm was sufficient to be able to control an extruder.
The analog pixels were clocked out and then converted to a digital value using several threshold comparators. The TAOS TSL1406 sensors had a 63,5 micron "center to center" spacing. I cannot recall what the pixel clock rate was, but the maximum allowed into the chip was 2 MHz. The 16 MHz VME bus clock was divided down and probably driven at 500 kHz. The board on the left hand side (top side of the board), shows four sensors staggered to align the pixels perpendicular to the board's long axis. Four boards were placed “end-to-end” giving a total of 12288 pixel resolution across 780mm. The photo on the right is the bottom of the same board, showing the comparators and RS-422 transmitters. The wires were a conscious decision to get the project out as quickly as possible on four layers (two signal layers, one power- and one ground layer). The RS-422 transmitters were necessary as the clock signals were between 500kHz and 1MHz with a ribbon cable of about two meters long. Checks with a 100MHz four channel scope confirmed clean signals, however, industrial plants are packed with variable speed drives, making differential connections necessary.
The 7-segment display boards were dated 11thJuly. Two
boards with four 100mm high 7-segment displays were driven
from the 64 latched outputs on the
board, each capable of sinking 24mA. Tyre plants are pretty
dark places, and I was not sure how much dimmer the displays
would be if multiplexed. There were 100mA transistors on the
back of the display board, connected open collector so that
the displays could run off standard 24VDC power in automation
These display boards were surprisingly expensive (ignoring the number of discrete outputs needed to drive them). The layout was done for a double sided through-hole plated board, which could have been much smaller to only connect to the plastic 7-segment displays at their top and bottom sides.
The illumination boards were dated 11thJuly. Each illumination board had 30 high-bright LEDs. The board was 240mm long and “end stackable”. The output was far too bright to look directly into, but they were placed above white perspex to diffuse the light. The output was red and pretty directional, but to make sure that the sensors (without optics) were not affected unnecessarily, holes were CNC drilled into a shielding housing to collimate the LED output. The illumination boards were placed some distance off to minimise edge distortion as we were not using optics.
The bottom of the illumination board had a current limiting resister per LED across a 5V supply. The resistors were placed on the back to allow the high bright LEDs to be spaced as close as possible. The decision to have parallel rather than a serial connection was in case one LED blew, then the whole board would be lost for illumination purposes. Resistors were not expensive, so I obliged. Their output was 14mcd (from memory but pretty expensive Hewlett-Packard devices to maintain uniform intensity with similar batched and graded devices). There was no time for experimentation, so I used the brightest devices available locally.
The processor board was a spare from past projects; a 3U VME card from "Oettle & Reichler" with an 8 MHz 68000 CPU. Previous software written for the board had been debugged over several projects, so the additional software for the imager was minimised. Remember that the way to program this combination was programming Flash chips, using a ZIF socket to reduce socket damage, pull the card out and swap out the program. Replace the board, set some debug switches and observe the monitor output. There were no JTAG or BDM ports! I had written software to split the S records into odd- and even bytes some time back. On the PC, you were not guaranteed to get all the binary data if there was an embedded carriage return or new line in the data, so that caused some pain a few years before. On Unix, you got the data you asked for.
The software was written in C on a PC, cross compiled with a MicroTec compiler, and executed from Flash. The real-time kernel as a small "tick-based kernel" which ran tasks to completion and basically assigned the highest priority to the shortest running tasks. The monitor was written several years before at Conlog, upgraded over the years, but ran on bare hardware. Device drivers were written along the Unix model so that some of the software could be tested on a workstation.
The imager looked for edges when thresholding the values clocked out of the pixel arrays (segmented to 25%, 50% and 75% divisions). The widths were continuously averaged to minimise flickering on the least significant digit of the display board. The response time was under a second for over 12,000 pixels. The dual-port RAM arrangement and FPGA worked well.
1 MIPS was about as much as you could get from an 8MHz 68000. Looking back at some of the dates on the updated MIPS design, there was definitely a desire to move beyond 20 MIPS at 33 MHz.
The listings were printed out in August, 2000. The threshold trials were dated 28th July. 2000. After the system was installed and the Basic card was available in the PLC, final commissioning was completed in September. Any changes after that were done on weekends as I was commuting between Pretoria and Port Elizabeth for the next nine months.
Initial documentation usually covered circuit diagrams, PCB layouts, FPGA schematics (plus simulation results), plus all source code. For prototypes, source code was always supplied to minimise risk in the event of the “dreaded bus riding over the embedded knowledge”. After the spares were blown and the main line cancelled, the documentation was bound—one copy for my collection and one for the customer. Detailed write ups, operational manuals, etc., were not done.
Prototype design is highly risky, more so if the final product does not become part of a standard offering. As a subcontractor the orders are delayed when everyone is juggling orders, payment, hedging their bets by not ordering spares, or having no control over the markups being passed on. Warranty claims need a special investigating department when uninformed people can weld near expensive control equipment without proper earthing or disconnecting computer equipment. Trying to identify the reason for electronics failing is similar to looking at a train line to see which way the train went.
After a lightning strike or electrical problems, the main contractor's Allen-Bradley PLC and a Panel View were destroyed together with another contractor’s industrial weigh scale. I was asked to swap out the spare set, which I did, although the imager appeared to be working. A few weeks later, on a Sunday driving to Pretoria, I received a call that someone at the tyre plant had welded on the conveyor without disconnecting the electronics, sending most of it to electronics heaven. I had been paid for the original boards, but not for the spares when the extruder line was cancelled by the tyre plant.
The main contractor’s trials would involve controlling the extruder, which was non-trivial, as there is often at least a massive mixer motor in front of it, plus the pressure is a bit high to control with a motion controller. Rubber is not the easiest to work with. Next, they would have to install a tread “cut-to-length” machine (similar to one I assisted with the motion controller while at Rockwell Automation). After the tread "cut to length" section, there was also automated "booking" of the tread.
This was possibly the most complex part of the project as it would require robotic programming and handling of flexible tread. The robot would cost several times a worker’s annual salary for a job a human could easily do. The tread weight was not the issue, but handling any flexible material is a problem for robots, hence harness assembly is still done by people in motor assembly plants. The tread would still be warm at the booking station.
I never did find out why the extruder was scraped. Unfortunately, with prototyping, we all shared the risk. My total price was roughly US$8,200 which would have been the same for the second set of spares to be purchased on completion of the overall extruder line. My costs were barely covered—the story with product development. Fortunately, everything worked first time, particularly the imager side and thresholding algorithms, as there would be no visibility into the FPGA internals without a logic analyzer.
Future 7-segment display systems would use a single-chip micro with a serial port to simplify the wiring. In this case, there was no logic on the board, so multiplexing would not have been susceptable to noise and long cables.
The benefit of the imager project was that the next two contracts were also in imaging (over the next 24 months). The difference was almost 100× more processing power using a Texas Instruments TMS320C6701 DSP, then a 64-bit MIPS RM7000 processor on the third project.
© 2016 — Second Valley Software Pty Ltd. All Rights Reserved