CONTENTS
Section one : (Introduction)
Acknoledgements
Summary
Introduction
Section 2: (Main body)
Design Brief
Specification
Research
Initial Ideas
Final solutions
Description of commercial solution
Production of prototype
Evaluation /Recomendations
Initial and actual time plans
Section 3: Appendices
A- Program listings + Explanations
B- Trumpet curve diagrams explained
C- Corespondance
ACKNOLEDGEMENTS
Thanks are in order for a great many people who helped us to get the project organized, and who helped by giving information, materials or advice. The people to be thanked are:
Mr B Carter, the Technology teacher at Beaumont School St. Albans. Mr Carter helped by Getting us interested in the project, and by setting us up with the link company. Also later on into the project, Mr Carter helped by giving us information on materials to use in the construction of the scale model of the sensor, and of how to go about producing.
Mr Raph Weyman, the Chief Software engineer at Graseby Medical. He helped by collecting us from watford station, when we went to visit the company and by showing us around after we had arrived there. He also helped us by looking over our ideas for the sensing device and by giving us information regarding the complexity and possiblity of certain ideas. He was also our link person in Graseby, and all faxes were sent to him. Later on, he helped by explaining in detail how a mouse or similar pointing device worked, and by helping us to choose an appropriate programming language for our control program.
Mark Bennett, the electronics engineer at Graseby. He was a past student at Beaumont, and also one who had benefitted from doing the Young Project Engineers course. He was helpful because he told us about the deadlines, and how to deal with them, and he also showed us around the Graseby building on the first day. It was useful for us to draw information from him at times when Raph was busy, and he was able to soothe our nerves about the up and coming project.
Mr T Pearson, the Physics teacher at Beaumont School. He was Kind enough to let us miss the odd one or two lessons when we were working in the Technology Block Designing and making the scale model.
Mr D Graves, The Father of Simon Graves, for providing some help while selecting ideas, and for providing the resources used whilst compiling the report.
Thanks to all who helped with the project, especially;
Mr Carter for all the advice he gave.
Raph Weyman and Mark Bennet at Graseby for putting up with us.
Mr Fernandez for finally not being able to help us, when we wanted it!
Mr Graves for the computer printer ink and paper!
SUMMARY
This section is missing
INTRODUCTION
First of all, the members of our team are:
John Finney
Stephen Penney
Simon Graves
David Edgar
John has been elected as team leader.
Our project has been set by Graseby medical, based in Watford. Graseby Medical is a reasonably small company, which has several departments. The department that set our project, manufactures infusion pumps, which are special pumps designed to deliver quantities of dissolved drugs into patients.
Our project, therefore, is based around these pumps.
There are two engineers in the company who are working with us. These are Raph Weyman, a Software Engineer, and Mark Bennett, an Electronics Engineer.
DESIGN BRIEF
This section is missing
SPECIFICATION
After we were given the design brief, we decided that the project should be divided into three main sections, which we would work on. These were:
1: The Flow rate sensor mechanism
2: The Computer interface
3: The Computer software
1: THE FLOW RATE SENSOR MECHANISM
The design brief gave us an idea as to how the sensor should operate. However, this needed some clarification. After looking at the brief in detail, and after discussions with Raph Weyman, the Graseby engineer who set the problem, a list of specification for the sensor was formed...
The sensor must, to an accuracy of +/-1%, measure the flow of a liquid (any liquid which is free flowing) flowing along a small (about 1mm diameter) pipe.
It is purely coincidental that this pipe will be attached to an infusion pump, i.e. the sensor can't be based on some movement of the pump, just on the liquid output flow.
The sensor (and the rest of the system) should be able to measure flow rates between 1.0ml/hr and 1500ml/h (which are really quite slow).
The system should interface with the liquid low using standard leur fittings.
The sampling period of the liquid flow should not be greater than that which would allow 0.25ml of fluid to flow without a sample being taken in that time.
Ideally, the measuring hardware should not enter into the path of the liquid, so that the liquid could be a sterile liquid, which would not be contaminated.
Although these seem like very strict guidelines, we were told that this specification would be the totally ideal situation, and that it was not totally necessary to fully fulfil all the specifications.
2: THE COMPUTER INTERFACE
This did not need to be described in such a detailed way as the sensor. However, to guide us in the production of an interface, we decided on a few of our own specifications:
The interface should convert information from the sensor into a format which could be used by an IBM PC or compatible.
This was because all except one of us has an IBM PC, and since it is the industry standard these days, it would make sense to go with this.(Not to mention the fact that the offices of Graseby Medical are littered with IBM PC's all over over the place!).What we didn't want was having to interface to, say, a Sinclair ZX81 because we couldn't find any ways to interface to a more modern computer.
The only other criteria was that it had to work, really, and produce an output which could be read by the software. This was a major part of the system, since without it the sensor would be useless, and the software wouldn't have anything to do.
3: THE SOFTWARE
The specifications for the software in the Design Brief were:
The software should be able to process the readings from the flow rate measuremnt system.
The Software should be able to produce a graph of flow rate against time, and also produce a trumpet curve graph (What is a trumpet curve? - See appendix B) for display and further analysis on the computer program.
As with the interface, the only other specification is that it should work, by whatever means, and produce the desired results; it does not matter, for example, what programming language it is writen in, as long as it works.
RESEARCH
This section is missing
INITIAL IDEAS
On the next few pages are some of the initial ideas we had, along with details of each design. Some of these could be seen to be instantly useless, but others were a little more promising and were looked at further.
All the initial ideas were faxed to our Graseby Engineer, Raph Weyman, to see what his comments on them were, and to obtain some constructive criticism, which helped highlight the better ideas from the really not-good-at-all.
+===========================================+
+To Simon: +
+FORMAT OF INITIAL IDEAS PAGES: +
+ First page = what is below this message. +
+ Up to fifth page = hand written ideas +
+ sixth page = Electromagnetic thing sheet +
+ Last page = what you find in INITI3.txt +
+===========================================+
THE SENSOR:
On the next few pages are some of the initial ideas we had, along with details of each design. Some of these could be seen to be instantly
useless, but others were a little more promising and were looked at further. The ideas are (mostly) all based on some sort of sensor in the
tube, which is connected at one end with the infusion pump under test.
INFUSION PUMP->-->-->-->--SENSOR->-->-->----- - -
(liquid flow)
The details given are details of the sensor involved in each idea, and also some indication of how this could be transfered into an electical reading which can be read by the computer is given.
All the initial ideas were faxed to our Graseby Engineer, Raph Weyman, to see what his comments on them were, and to obtain some constructive criticism, which helped highlight the better ideas from the really won't-work-ever ideas.
THE INTERFACE AND SOFTWARE
After looking at what to do about the interface and software in terms of
finding a design for them, we decided that it would work best if we could
look at these when the sensor design is finalised, since then we would
know what sort of information will be recieved by the interface and the
program.
[Several Handwritten Pages ommited]
initial ideas continued..
After having some input back from our engineer, we could decide which
ideas would be worth thiking about further. Some of the ideas would
work, but would be inaccurate due to the very small scale measurements
which would need to be taken. For example, in idea number 7, using a
flexible optical fibre in the flow, would require a large array of
very small light sensors to pick up the minute movements of the fibre
(remembering that the pipe diameter which would be involved would be
about 1mm, the optical fibre would sway, probably, at maximum 0.3mm
when under a very fast current).
Looking back, then, the ideas which were marked as useless (or good)
were:
X 1: This idea almost cheated, because it measured something in the
actual infusion pump. This was 'not allowed' because the flow
meter should be able to work with any type of infusion pump
(some, which we were shown, do not have syringe feeds). Also,
the defect in the pump that we were trying to detect could be
to do with the syringe used, as so it would not show up when
testing the pump.
2: This was a hopefull idea, which could work, although because
the resulting pressure differences would be small when working
at low liquid velocities, the distance 'd' would be hard to
measure. This could wor well if combined with another
system, though.
3: This was also a hopefull idea, although the friction from the
wheel may be a problem. It is certainly the simplest.
X 4: We were not sure if this would work or not, but even if it did
then the movement of the membrane would have been hard to detect.
X 5: No, this wouldn't work; so that's that.
X 6: This may work, but friction could be a big problem, and the
sensor would have to remain perfectly horizontal to work. So,
er, maybe not such a good idea.
X 7: Same sort of problems as with idea 6, and, as mentioned earlier,
the range of movements of the fibre would be very small, and hard
to detect.
X 8: With this idea, there would be the same problems with measuring
the distance the light would move as in 7. Also, there is no
evidence that the refractive index of the liquid would change if
it was travelling faster.
Electromagnetic Flow Rate Measurer:
Our engineer hadn't heard of this idea, and consequently couldn't give
us any clues as to if this could be implemented, or even how it worked.
Our physics teachers couldn't tell us anything either, so this idea was
marked with a 'we couldn't use it' flag.
With the feedback from the engineer, he also sugested that we could use
some sort of thermal marking of the liquid, to find the its velocity.
However, we could see nothing but problems with this idea, and so it
was abandoned.
FINAL SOLUTIONS
After selecting the good initial ideas for the sensor, we had to elaborate on
these, to produce several good designs which could then be thought about as
proper solutions to the problem.
From the initial ideas, two ideas were feasible:
Using a Venturi, to produce a movement in a pipe which is proportional
to the velocity of the liquid in the tube.
or..
Using a water-wheel type arrangement, which would spin at a speed which
is proportional to the velocity of the liquid in the tube.
The first idea, unfortunately, has several down-sides to it. One, as
mentioned in the Initial Ideas, is that it will not give accuarate
readings when the liquid is travelling at low velocities (if any reading
at all). The lower limit, as set in the design brief, should be 1ml/hour,
which is very slow. Using the Venturi based idea, this will produce as
good as absolutely no output reading at all (even when at 1l/hour, not
much of a reading will be able to be obtained since this is really quite
slow too). Another problem is that when the liquid rises up the second tube,
this liquid is removed from the flow, of water, until the speed of the
liquid drops again, and the liquid flows back into the main flow. This
creates a fluctuation is the very flow that is being measured for
fluctuations, which would be a problem if the sensor was being used while
connected up to a patient.
The second idea, though, using the water wheel, should be able to cope with
all the velocities of liquid that can be given to it, since when the liquid
moves, so does the wheel, so there is always some reading being taken. This
is a good advantage over other methods.
Another advantage is the relative ease with which an electronic signal
could be produced from the rotation of the wheel. From the axle of the wheel
(which would extend to outside the tube) a disc could be attached to it,
which could then be used to measure the speed of rotation optically. The disc
would have to have slits or holes at regular intervals around the
circumference, and an LED and LDR (Light Emitting Diode and Light Dependent
Resistor) pair could be used to detect whether if, at a certain place or a
certain time, a hole is there. Using the result pattern of holes and non-holes
at certain times, the speed of the disc, and consequently the speed of the
liquid, can be worked out.
The only, and major, problem with this method is the friction of the wheel.
If the wheel does not spin totally freely, then the liquid will need to
overcome this resitance before it starts to tuen the wheel, and the reading
for the velocity will be slower than it actually is.
So, the second idea will be used. On the next page is a diagram to show
how it will work.
+++++++++++++++++++++++++++++++++++++
SIMON SIMON SIMON SIMON SIMON SIMON
On the facing page to this,
put the page of the file
SENSOR.SCR,
and a new page after this.
SIMON SIMON SIMON SIMON SIMON SIMON
+++++++++++++++++++++++++++++++++++++
Production of the Sensor.
Having thought about how we were going to produce the sensor, we have to
think about the interface, and the software (more urgently the interface).
Since the interface should connect the sensor circuitry to an IBM PC
(from the specification), we looked at the back of one.
There are several connections that we could use...
1: The Parallel Printer port
2: The RS232 communications port (two of them)
3: The Mouse port
and that is it. Most interfaces which are used with computers are conncted
to the RS232 port, since this has the scope to send and recieve
information from the outside world. The parallel printer port can only send
information from the computer, and so wouldn't be useful for this
application, where we require information to be taken fomr the sensor.
The mouse port also has the ability to take information, but it only deals
with mice.
So, the choice for the interface would be a RS232 connection, together with
the appropriate circuitry. This circuitry would have to perform the
following:
+ Convert the signals from the LED/LDR pair into a stream of pulses
+ Convert these pulses into a byte of information which can be quickly
sent to the computer for real-time analysis of the results.
This is what would be the ideal Situation.
However, after looking to finding circuitry (and failing), we decided that
for the prototype we produced, we would have to find a simpler method.
We thought about using a different computer, but finally
DESCRIPTION OF COMMERCIAL SOLUTION
This section is missing
PRODUCTION OF PROTOTYPE
This section is missing
EVALUATION / RECOMENDATIONS
This section is missing
INITIAL AND ACTUAL TIME PLANS
This section is missing
APPENDIX A: PROGRAM LISTINGS
1: THE DATA ACQUISITION SOFTWARE
This piece of software, written in Zortech C++,
reads movement in the adapted mouse, and sends
the readings to a file call DATA.DAT. The
software works by detecting the position of the
mouse, writing this to a file, adn then detecting
the new position of the mouse. However, since the
mouse position is only allowed to have values
from 0 to 640 (one full screen sweep, if you are
using the mouse normally), the values need to be
manipulated each time the mouse reaches a value
of 640, to still get an output result.
The software has a sample rate of one reading
per second. This needs to be known to calculate
the actual angular velocity of the wheel.
When the STOP button has been pressed, all the
values are flushed to the file, and the program
finishes.
2: THE ANALYTICAL SOFTWARE
This software, written in QBASIC, uses the values
produced in the first program to work out the
velocities of the wheel, drawing a graph, and it
also uses these to produce a trumpet curve error
graph (see display board). This software has not
been calibrated yet, so it does not give actual
velocities, since first it needs to be given a
known, steady velocity to compare against the
readings it gets.
As we were designing how we were going to produce the computer programs to recieve and analyse the information sent to it from the sensor, we were planning to write the entire program in Zortech C++, but soon discovered thatthis would be rather hard to do, and would take a long time, as we only had a basic knowledge of the language. However, we did all know Microsoft Qbasic inside out, and so decided to program in that. We had problems in that, as Qbasic has no mouse support, and so the receiving part of ther program would be impossible.
We then decided that it would be best if we did half the program in Zortech C++ (The half that receives information from the sensor), and the other (Analysing) half in Qbasic.
To run the program you need to run the first part first by typing:
FLOW [ENTER]
You can then follow on screen insructions to receive information.
When you want to stop sensing, press the "STOP" button, which will terminate the program.
To analyse this data, you need to run the Qbasic program, you need to type:
QBASIC /RUN FLOW.BAS
You can follow the instruction on the screen toanalyse the data.
You can download some of the source code for this project here:
flow2.cpp
flowmenu.bas
APPENDIX B: TRUMPET CURVE DIAGRAMS EXPLAINED
This section is missing
APPENDIX C: CORESPONDENCE
This section is missing
This report compiled 6th April 2005, by S W Penney