In between calculations and doing development work
on the engine itself, I have been looking at what will be required for the
power and telemetry set up on the test bed.
I've built a few data acquisition and control
systems, mostly centred on either the Basic Stamp or PIC type microcontrollers.
Over the years I have formulated a set of guidelines to assist rapid system
prototyping. These are as follows:-
Accretion
Each part of the design problem is broken down into
manageable portions. The sub-assemblies produced are then combined to form a
coherent whole.
Recycling
In 2002 the DEER report stated that due to rapid
advances in component design, leading to rapid obsolescence, component
recycling will be necessary in the future for repair of in service equipment.
Indeed, nowadays most electronic equipment is simply
thrown away when it reaches the end of its useful life, containing hundreds of
perfectly serviceable, usable components. These components can and should be
re-used when possible.
Heterogeneous
Architecture
This approach to control system design was first
enunciated by Whitcomb and Yoerger, of Woods Hole Oceanographic Institute, in
their 1993 paper on the Jason MK2 ROV. They argue that most control systems can
be split into at least two computational subsystems, namely user interface and
control.
The heterogeneous approach attempts to speed up
system development by using standard, off the shelf hardware and software for
generic system functions: -
“A better alternative for medium and large-scale
fast-track development is to embrace heterogeneous architecture at the outset.
Use general purpose machines for commonplace tasks such as user-interface and
logging, use dedicated real-time machines for control.”
The case is made for the use of commercially
available machines and software wherever possible. Whitcomb and Yoerger
conclude that: -
“The metric of success in fast-track development is
not the uniformity of design, but its rapid and successful implementation.”
Dr.
AM Turing
Dr. Turing’s paper "Intelligent Machines"
(King's College, Cambridge, 1947) is now widely regarded to have been the first
introduction of the software control concept. Turing argued that software based
control could produce an extremely flexible system in which very few hardware
alterations would be required. Rewriting software would accommodate any problem
that arose, or changes in operating parameters.
The basic design of the test bed control and data
acquisition system will be guided by these principles. Use will be made of as
many standard, readily available components, communication protocols and
sub-systems as possible.
With the above in mind I decided to go with a laptop
running a GUI that would then interface with a microcontroller based I/O card
at the test bed end. Rather than build my own microcontroller board, I went for
a kit solution in the form of the Velleman K8061 USB I/O card. The specification
of this card is as follows:-
8 analogue 10 bit resolution inputs: 0…5 or 10VDC /
20kohm
8 analogue 8 bit resolution outputs: 0…5V or 10VDC /
47ohm
8 digital inputs: open collector compatible
(connection to GND=0) with on board LED indication
8 digital open collector outputs (max. 50V/100mA)
with on board LED indication
One 10 bit PWM output: 0 to 100% open collector output
(max 100mA / 40V) with on board LED indication.
General response time: 4ms per command
USB Port: 2.0 and 1.1 compatible (USB cable
included)
Further details may be found at www.velleman.eu
As can be seen the K8061 card has a fairly
impressive analogue and digital I/O capacity. It took me an afternoon to build
and test, using Velleman's own free diagnostic software. This was significantly
quicker than had I programmed and debugged my own PIC based board. Here is a
photograph of the completed board:-
The long narrow IC to the left of centre at the top
of the board is the pre-programmed PIC that handles the USB communication to
the laptop. The long wide IC below this is the second pre-programmed PIC that
deals with all of the analogue and digital I/O.
The communication routines for the K8061 are
contained in a DLL which the user is given access to. This enables custom
control applications to be written in a variety of languages. That said, one of
my chief reasons for wanting to use the K8061 was my choice of Profilab to
develop the GUI on the laptop.
Profilab is a graphical programming language for the
development of control systems. It is somewhat similar to NI LabVIEW. In the
Profilab hardware library there is a module for communicating with and
controlling the K8061. You can read more about this software at www.abacom-online.de/uk
My first step was to attempt to interface one of my
K type thermocouples to the K8061 and obtain a temperature readout in Profilab.
Initially I was going to design and build my own thermocouple pre-amplifier,
based on the AD8495 IC. Whilst researching this I found another excellent kit
designed and produced by Dr. Matthew Little of re-innovation, here in the
United Kingdom. More can be found at www.re-innovation.co.uk
The construction was straightforward, although I had to solder the tiny SMD
AD8495's to the PCB by hand, something I'd never attempted before. Fortunately
I quickly got the hang of "drag soldering".
I got four of these boards, here is a photograph of
a completed one:-
You can see where this is going; any electronics
design and construction I would do myself would be restricted to signal
conditioning and driver circuitry. This is where the recycling aspect would
come in as I have literally thousands of components in my workshop to use up!
I had to connect the thermocouple and AD8495 board
to the K8061 via an op-amp buffer due to the relatively low input impedance of
the K8061. I used an LM324. It has the great advantage of not requiring a split
supply.
Here is a photograph of the test set up. The K type
thermocouple is connected to the AD8495 board and thence through the LM324
buffer on the breadboard to the K8061:-
And here is a screenshot of Profilab displaying the
temperature in my electronics lab (which my wife continues to refer to as the
dining room):-
Now, you are all probably thinking, quite rightly,
that a safe distance ought to be maintained between an untested homebuilt
rocket motor and it's tester. And you'd be right. Of course, USB only has a
range of 3-5 metres....but as Baldrick used to say "I have a cunning
plan...." All will be revealed. That is, if I can do it...
No comments:
Post a Comment