Taylor Valves Ltd: Compressed-Gas-Valve Test-Rig

A local valve firm approached my school looking for students to take on an engineering challenge.  Greenhead College suggested we (a team of three students in engineering-related disciplines) do this as an extracurricular activity (whilst I was also studying for five A-Levels at Greenhead College and a C+G III course at Huddersfield Technical College.)  A normal workload (considered fairly hard) is about three A-Levels.  (i.e. I was already carrying double the normal work-load before I took on this project as well, at the encouragement of Greenhead College.)

They wanted a machine to test their products to destruction, so they would be able to give less conservative (more accurate and more commercially appealing) estimates of how long their products would last.
The project was initially slated for completion March/April 2005, after a 1-week residential stay in Loughborough University the previous December.
Taylor Valves brief to Greenhead College student team.

Delegation of Team Roles

In the initial discussions (as the team member with the broadest oversight in control systems engineering and physics, and the necessary experience in project leadership) I emerged as the natural leader under our client-company coordinator Brian Sanderson.  Within the team I continued to fulfil the leadership/engineering-direction/motivation role for the remainder of the project.

Specifying the Project

Our first job was to evaluate the task ahead of us.  We agreed on a specification for the project with Mr. Sanderson, to fulfil the company's needs, that we all considered feasible.

Mechanical Design Options & Feasibility

We measured the moment-of-force required to open and close the sample valve supplied by Taylor Valves Ltd., and chose an actuator unit that would convert an appropriate electronic signal into the necessary motion with
  • sufficient force;
  • sufficient clearance to the valve portals.
Only one company provided a product meeting our specifications; Kinetrol.
Valve actuator unit: Kinetrol I/P controller.

The mechanical side of the project was therefore well-specified from the beginning.  It would be the control panel that would provide the main challenge.

Control Unit Design Options & Feasibility

As the only team member with any electronics / computer programming / soldering experience, or the confidence to try his hand at any of these things, all the technical works for production of the control unit fell upon me.

Our initial research yielded two potential design paths:
  • Computer-software-controlled, with an electronic interface
    Pros:
    • Can easily repair design faults and implement upgrades
    • Design and implementation cycles are merged into one, cutting some of the rigorous testing one must do with hard-wired electronics
    • Comments & pointers for other engineers can be built into the design
    • Few components from external suppliers - less to go wrong
    Cons:
    • Expensive initial financial cost implications - would have fallen outside the prescribed budget
    • Untested route for us (with potential for negotiating a maze of unpublished standards, where building an electronic interface could have been a project in itself)
  • Custom electronics
    Pros:
    • Relatively cheap in financial cost
    • Tried and tested development road-map (from my High School electronics projects)
    • Pre-designed, pre-tested circuits (listed in books in our possession) could be adapted for this project
    Cons:
    • Corrections are hard to do once the circuit is built
    • Upgrades are difficult, or impossible, to implement
    • Supply-chain delays in the delivery of one of many components could postpone testing and completion
Given that fitting out a computer for this would have put us over-budget (bear in mind this was 1994), and given my prior experience in electronics, we chose to design custom electronics.

Functional Division of the Project

We divided the project functionally into the following segments:
  1. (Mech.) Valve
  2. (Electr./Mech.) Actuator
  3. (Electr.) Timer circuit & Electronic control for actuator
  4. (Electr.) Counter & Control circuit
Responsibility for the carpentry & fitting work (i.e. the mechanical side of the project) was given to my two student colleagues, while it fell upon me to produce the most complex part - the electronic control unit.
System Interconnections & Information Transmission. A later version of one of our initial sketches, schematically illustrating an exploded view of the finished works.
Counter circuit. Several units were daisy-chained together.The synthesis into several component subsystems (including counter, comparator, and 7-segment-decoder ICs) into a hardware engineering solution.
Timer circuit.An adaptation of a timer circuit found in an electronics textbook.

The Design Process

Buying (and learning to use) expensive software for a one-shot project was out of the question - many of our workings had to be done by hand.
TTL microchip pin-outs, from early research. Some early scribblings from an electronics catalogue.  Even though I understood the importance of accurate research quite well, the headaches caused later by one or two (seemingly small) false assumptions (made against a pressing schedule), only served to reinforce the principle.
Switching / Interfacing circuitsThe Schmitt trigger IC is a marvellous device for processing (and taming) input sensor signals.  It takes an erratic signal and converts it into a steady “on” or “off”.  Using a high voltage threshold for switching on when the signal is rising, and a low voltage threshold for switching off when the signal is falling, the signal is converted into a form that permits counting (of large physical movements, rather than noise on the sensor contacts).  For further smoothing/stability, capacitors can be used on the input to the Schmitt triggers.
PCB Track lay-out. Figuring out how to lay out the tracks on the printed circuit board can be a real puzzle.  Here is one of many jottings...  In fact, optimising circuit layout could be considered one of the most difficult problems in Computer Science.
Counter/Comparator circuit printed circuit board ( The printed circuit board mask, designed in the standard vector-based drawing program "Draw" on the Acorn Archimedes computer.

With hindsight, smaller, rounder solder pads would have been better than the elliptical ones shown (which took some power to solder properly).

The circuit-board was designed in the mirror-image so that the printed side of the transparent acetate PCB-mask would be closest to the photosensitive layer on the PCB, giving the best possible resolution on the finished circuit (and therefore allowing more tracks to fit between the legs of the microchips, simplifying the design and minimising the need for soldered jump wires).

The Huddersfield Technical College kindly allowed me to print the circuit board free of charge at their facilities.
Work flow / dependency chart for Control Panel subsystem General work-flow / dependency chart for the control-unit subsystem.

Challenges / Obstacles to success

Challenge:How we overcame it:
The scale of the project Worked hard
Keeping the whole team motivated to the end (especially considering that none of us was paid for this work) Kept team meetings & direction reviews brief and to-the-point, monitored dependencies and laid down shared specifications as soon as practical so nobody was held up waiting for anyone else
Different sizes of square spindles on valve and actuator Brian, Graham and Dan made a connector with different sizes of square holes, as part of their mounting bracket design.
Valve actuator required a very clean air supply (no grease etc.) Company bought an air filter and mounted it.  (With hindsight, a Kinetrol vane actuator with solenoid control unit would have been sufficient for our needs, and would have eliminated the need for a clean air-line.)
Rotary BCD switches delivered according to wrong specification (displayed in UK catalogue in a US-standards 3rd-angle-projection drawing, meaning chip pin-outs were in mirror image) Broke 20 tracks on counter-circuit PCB, soldered jump-wires to complete the circuit according to the correct pin-outs
Circuits consumed much more power than originally anticipated.  (A simple calculation at the design stage would have warned us of this problem, but at that stage we considered the power requirements near-negligible and not worth calculating!) Calculated the requirements, added extra voltage-regulator chips, and installed sockets for mains-powered transformers.  Resolved to use CMOS technology next time instead of power-hungry TTL, and to cover all corners on the design following the old mantra “if it can go wrong, it will”.
Heat dissipation issue caused by excessive power consumption Put the voltage regulators on the biggest heat-sink we could get into the vacuum-formed box with lots of heat transfer grease.  Installed a fan above the heat-sink.
Taylor Valves' test rig, made by Matthew, Graham and Dan
The finished control panel The finished control panel.

Design Features:

  • Key-switch for power on/off
  • Potentiometer for adjusting the rate of valve open/shut cycling (between 2 seconds and 20 seconds)
  • Buzzer (indicates when the valve has been opened and closed the pre-set number of times)
  • Pause button
  • Valve leak signal port (via internal wire terminal-block plus additional circuitry to be supplied by valve manufacturer according to substance controlled by the valve) so that as soon as any loss of pressure via the valve seals is detected, the valve will remain in the closed position.
  • Numeric control dials (0 - 99,999) - allowing testing of valve seals up to a hundred thousand cycles with minimal human supervision
  • Counter display indicating the number of cycles endured by the current set of valve seals
Taylor Valves' test rig, made by Matthew, Graham and Dan The finished test rig, presented to Taylor Valves Ltd.

Lessons Learned:

  • The initial financial and time constraints were too tough, and impossible to meet.  Trying to meet these overambitious targets made us spend more money and time than necessary, partly by cutting testing phases out of the development cycle to accommodate delivery of electronic components just days before our residential stay in Loughborough.  After the initial project deadline, other scheduled works took precedence, until the project was finally delivered in the first few days of October 1996, before heading off to study Computer Science in Cambridge.  A realistic initial resource allocation, with more rigorous testing phases in the design cycle, would have been more than worthwhile.
  • Given all the hassle we had with electronic components & the inherent difficulties arising from numerous supplier dependencies, and given the fact that we were only producing a single unit; it would have been better to spend money on a computer system (or programmable logic controller, or such like) and take the time to research the existing standards for electronic interfaces, rather than designing a fully customised circuit (which would have given far greater flexibility for troubleshooting our design and potentially reusing components of our design for other projects.)  Having chosen what was to us the more familiar option, to develop a fully customised circuit; we ought to have counted the total power consumption of our circuits at the design stage (if we had done so, we would have selected CMOS logic rather than TTL as the difference would have been significant and this would have greatly reduced issues with our power supply, heatsink and ventilation.)
  • We really needed another electronics technician on the team, or at the very least, someone confident in working with vacuum-formed plastics according to my specifications.  Willing and able as I am, and as good as my team-mates were; my workload was too full, and became a bottleneck that affected final delivery date for the project.  It is partly through this experience that I have learned to balance the benefits of any given project against its costs, and that I learned to say “No!

Related links:


Back to Projects
Link back to Projects

You can count the number of seeds in an apple, but you can never count the number of apples in a seed.
© 2004-2017 Matthew Slyman