Skip to main content

main_8659d9485bb7fad589ad8d2ed61de7f8b701642f.jpg

Redesigning the drive electronics of a paper tape punch for Chip Hack EDSAC Challenge.

In a previous post we described reverse-engineering a tape reader for the EDSAC Challenge. While a nice addition, a tape reader alone is of little use: where do we get the punched tape to read from?

Introducing the GNT 3601 8-bit tape punch. Just like the reader, the punch has been recovered from service as a PCB drill storage medium. Sadly, this device had a rough life and when we turned it on, nothing — no light buttons or whirring…. Time to breakout the screwdrivers!

gnt361_1c05ce9a6ac7b9049c9565d601930ac93939c7c4.jpg

Mains powered — keep your fingers out

With the punch taking 240V mains it’s a good time to point out some safety considerations. There will be live connections within this chassis, and careless prodding will have consequences ranging from a mild but painful shock to death. This would be true of any device that would plug into the wall (or even some modern battery devices, e.g. your hybrid car) so without sufficient know-how or training when it comes to safety, it’s best to leave this kind of service to the experts.

There are techniques to mitigate the risk and one of which we used was an isolation transformer (260-4238) . These remove the earth reference of the live and neutral connections, meaning that if you touch either of them the shock is significantly reduced (touching both simultaneously will still be very dangerous). This is a similar technique to a bathroom isolated supply and while “safer” it is far from safe, so it shouldn’t need saying: don’t go sticking anything into the socket to test the theory!

Safety message over and being “grizzled old engineers”, we powered the device to find there was no power out of the toroidal transformer. Stripping the unit down we found the transformer was burnt out and the markings indicated it was a single 12V(ish) output. This would be 12V AC, so we found a step down transformer and connected this up, only to find there was a lot more wrong than just the transformer. Several transistors were getting excessively warm, as was the main core IC.

thermal_7ba0838c322ba6a59ccc22f5627004fafeaa5f72.jpg

Using a multi-meter we could see the motor drive IC was broken, as were a few other bits.

Replacing the obviously broken components seemed to bring some of the device to life, and at least the motor span. Sadly, the core IC, an NEC D8048HC162, was still hot and not doing very much (our FLIR came in usefull here). Replacing this was just not possible, even if we can find one, how would we program it since we don’t have the source code.

To compound the issues, just like with work on the reader, there was no documentation and made worse this time, as the manufacturer didn’t have a service manual for the device. After much trawling the internet we finally found a manual for the electromechanical part of the punch, a GNT-36. Looking through the manual we could see there was little in the way of sensitive electronics within the punching mechanism. Maybe it’s salvageable?

Solenoids galore

solonoids_d2fa8505c014799637e6671cba36b130a41190ac.jpg

The manual clearly explained the punch mechanism: CH1-CH8 and FH were all individual solenoids connected to VM(12VDC). Additionally there was a special solenoid called FMAG (feed magnet), the purpose of which is to engage the feed wheel and pull the tape though.

The CH1-8 coils are described as 12VDC and 75 ohms, which means that each coil will need 160mA while engaged. The FMAG coil needs 270mA.

Using a multimeter we quickly confirmed this manual seems to match our device and all of the coils were of the correct resistance – this may just work.

Not forgetting the motor would also need powering and since the punch is a maximum of 75 revolutions per second, probably wants PWM controlling. We have no information on this so a little trial and error was going to be required to attain the correct speed.

As you may be aware, modern microcontrollers don’t like 12V and definitely don’t have 270mA drive, so we will need some external circuitry. Luckily, we had some devices on hand that would do nicely: introducing the marvellous ULN2003A (686-8209) . This is a 7 channel Darlington pair array, complete with clamp diodes and everything required to switch inductive loads. For the motor we have the new transistors we had bought to replace the motor driver, which also happen to be Darlington transistors (just large TO-220 8A continuous rated ones this time).

What darling?

Time for a little science lesson. “Darlington pair” is a description of a specific transistor configuration that has an extremely high gain. The first transistor is there to provided gain for the second. For example, a bipolar NPN with a current gain of 300 would require 1mA base current to allow 300mA to flow collector to emitter. By connecting two of the same NPNs as a pair in Darlington configuration, the gain would now be a little over 300 x 300 = 90,000. Quite an improvement!

Darlington_pair_diagram_622bff9ff01743f1dc1b963210afd675077572c9.jpg

The ULN2003A devices “only” have gain in the thousands, but this still means with less than 1mA we can fully saturate the transistor for any rated current the IC can manage. This makes them almost perfect for the design. 300mA is well within specifications and the ULN2003A are internally biased and, most importantly, protected from back-EMF, meaning we that need no additional circuitry. One drawback of this method is ULN2003As are not fast and switching times will be slower than with a MOSFET, but at 75char/s (the max rate of the punch) speed is not an issue.

PSoC is not just any micro

Given we didn’t have long to get the punch working with the event looming, we needed a simple but quick solution.

PSOC_e45c7d801729a61852c96925afeebe4fbc9415d8.jpg

Having used PSoCs for everything from garage door openers to BLDC drivers, we were familiar with the capabilities and features. We previously used the PSOC4 in this post on BLDC motors, which gives an overview of the power of PSoC.

For those who have missed the previous articles, PSoCs are a powerful mix of an ARM microcontroller, CPLD and analogue peripherals. The development kits are also relatively low cost and come with an integrated programmer/debugger. For this project we used the more powerful PSoC 5 CY8CKIT-59 (124-4192) . The PSoC 5 used within the CY8CKIT-59 is more than capable of the requirements we have. In fact, it’s so over-matched to the job at hand we almost felt guilty for setting it to such a mundane task.

As time was short we quickly connected a temporary design together. While not good practice to skywire together mixed 5V / 12V circuits, as a mistake could be costly, it did allow rapid prototyping and within the space of an hour we had the circuit connected up. With the addition of a linear regulator to run the PSoC from 12V we were done.

One advantage of using a device like a PSoC, is there is little in the way of getting the connections wrong when connecting it up. At programming time we can connect our IO to any of the IO on device. This is an amazing feature and allows great flexibility for design and expedience of use.

Now we have the circuity ready we can turn on the motor and finally check the output of the rotary encoder matches the documentation, This was the biggest unknown and possibly the weak link in bringing the punch to life. Luckily the encoder works great.

Software glue

With the hardware complete time to glue the design together with some liberal use of the CPLD and software. Before getting started it was essential we understand what is required and using the manual for the GNT-36 we had a phase diagram.

From this we can see we need the following:

  • A method of measuring pulse length
  • A method of synchronising to the 0 pulse
  • A method of tracking the state 0-5 and asserting the correct solenoids

Taking these problems in turn, pulse length can be measured many ways, but a simple method is an interrupt on each edge and use a free running timer in between. This also allows an easy hardware offloaded solution for timing, and a simple method for the last two items. We can set up a simple state machine that will increment on the positive edge of the timing pulse, synchronising on the pulse 0 within these ISRs. After which it’s is a case of using a single global so that we can then keep track of state.

CY_ISR(InterruptHandler)
{
  Counter_1_Start(); // start the counter to measure pulse length (pos edge to neg edge)
  // This ISR controls a state machine that tracks the rotary encoder keeping track of the punch position.
  // The value 8000 is hardcoded right now but should be calculated from the max/ min interrupt values so
  // rotational speeds other than a very limited range are accounted for.
  if (currentstate == -1)// uninitialised
    {
      if (lastpulselength > 8000) //do nothing until initialised
      {
        currentstate =1; //start the state machine
      }
  }
  else
  {
      if (lastpulselength > 8000) // resync in case of skipped step
      {
        currentstate =1;
        CTRL_TEST_Write(1u); // CTRL test is a test pin for scoping purposes   
      }
      else
      {
        if (currentstate ==5) // last state time to wrap to zero
        {
          currentstate =0;
          if(cycle==1) // keep track of cycle not used
          {
            cycle=0;
          }
          else
          {
            cycle=1;
          }
        }
        else
        {
          currentstate ++; // change state
        }
      }
  }
}
CY_ISR(InterruptHandler2) // this interrupt is entered once the rotary encoder drops this is where we can measure pulse length
{
  lastpulselength = Counter_1_ReadCounter(); // update last pulse length counter
  Counter_1_Stop(); //stop the counter
  Counter_1_RestoreConfig(); // reset the counter ready for the next event
  CTRL_TEST_Write(0u); // reset the test pin
}

Now that we have a state machine with reliable control we can implement a tight loop to clock punch data in. This will allow the data to come in at a lower rate than the punch rotation, with our design skipping rotations until data is ready. This will be ideal for the Chip Hack event as we have no way of synchronising to the punch rotational speed and an asynchronous event is essential.

if(Feed_Read()==0u) // wait for data to be clocked in, negative edge enacted upon on the posedge
      {
        x=0; // clear temporary store
        if(CH1_in_Read()==1u) // CH1-3 disabled
        {
          // x=x+1; //bit 0
        }
        if(CH2_in_Read()==1u) // CH1-3 disabled
        {
          // x=x+2; //bit 1
        }
        if(CH3_in_Read()==1u) // CH1-3 disabled
        {
          // x=x+4; // bit2
        }
        if(CH4_in_Read()==1u) // CH1-3 disabled 
        {
          x= x+ 8; // bit 3 binary value 8
        }
        if(CH5_in_Read()==1u)
        {
          x= x+ 16; // bit 4 binary value 16
        }
        if(CH6_in_Read()==1u)
        {
          x= x+ 32; // bit 5
        }
        if(CH7_in_Read()==1u)
        {
          x= x+ 64; // bit 6
        }
        if(CH8_in_Read()==1u)
        {
          x= x+ 128; // bit 7
        }
        while(Feed_Read()==0u) // wait for end of pulse
        {
        }
        singlechar=1; // data to be punched must be completed before the next negedge
      }

Finally, we can clock this data back out to the electromechanical punch once the data is clocked in and ready.

if(singlechar ==1u) // data waiting
{
    singlechar =0; // clear flag
    while(currentstate!=5) {}// wait for sequence start cam at punch position
    Punch_out_Write(x); // assert data this will set relevant solenoids
    x=0;        // clear data
    Feed_hole_Write(1u); // punch a feed hole        
    while(currentstate!=2) {}//wait
    Punch_out_Write(0); // de assert solenoids and feed hole
    Feed_hole_Write(0u);
    while(currentstate!=3) {}//wait
    Punch_out_Write(0);
    Feed_hole_Write(0u);
    Tape_Magnet_Write(1u); // engage clutch and feed tape
    while(currentstate!=0) {}//wait
    Tape_Magnet_Write(0); //disengage the clutch and feed tape
}

Setting up the hardware schematic with a PWM for the motor and input circuity, including a glitch filter since we have a lot of electrical noise being created, was simple enough. This allowed us to start testing, not a moment too soon and after a little trial and error (read quite a lot of work) we found the correct PWM settings for a reasonable rotation speed.

Following this we had limited success until it became clear that we were not disengaging the clutch quickly enough, so we moved the disable to state 0 from state 1 to disengage quicker (a better solution would be to actively drive the coil in HW). Finally, this left the punch working great and ready just in time for Chip Hack the very next day.

Final words

As a result we had a blast at the Chip Hack event, coding up some HDL (Verilog) to create a legible header for the event. We printed around 50 of these as souvenirs for the attendees and the solution worked without issue, which amazed us given we ran out of time to re-wire in a less chaotic manner. In an upcoming post we’ll take a look at the HDL created to do this.

While certain the original design was far more elegant, redesigning a machine from the past in a few days work is certainly possible using modern tools like PSoC and just a few transistors.

Karl Woodward

Karl is a design engineer with over a decade of experience in high speed digital design and technical project leadership in the commercial electronics sector.
DesignSpark Electrical Logolinkedin