Test bench for a Distributed Data Collector (DDC)
Master thesis, electronics
Mälardalen Univeristy
School of Inovation, Design and Engineering Author: Mikael Bohlin
Supervisor: Daniel Kling, Addiva Consulting AB Examiner: Mikael Ekström, Mälardalen University Västerås, March 2010
Abstract
A system for monitoring and analysing the state of equipment and processes in i.e. the industry will help to increase productivity and prevent unscheduled stops for maintenance. To do so certain parameters needs to be measured and analysed. The DDC (Distributed Data Collector) will collect this data and pass it on to a central server for analysis.
This thesis covers the construction of a test bench for such data acquisition to get data to send across the network and to prove that the concept works. A number of sensors have been set up to measure four important parameters: temperature, vibrations, current consumption and rotational velocity. Hardware and software for reading data from the sensors has also been constructed. All hardware is built into a box where each sensor measures a controllable object, such as a motor and a heating element.
The program for data acquisition uses an interrupt-based architecture so every time a big enough change is detected in one of the sensors the DDC-signal is updated by the program. Each signal has a unique number for identification and is passed across the network at set intervals.
Sammanfattning
Ett system som övervakar och analyserar tillståndet hos utrustning och processer i t.ex. industrin kan hjälpa till att öka produktiviteten och förhindra oväntade stopp för underhåll. För att göra detta måste ett visst antal parametrar mätas och analyseras. DDC:n (Distributed Data Collector) kommer att samla in denna data och skicka den vidare till en central server där den loggas och analyseras.
Syftet med det arbetet som täcks av den här avhandlingen är konstruktion av en testbänk för just sådan datainsamling för att sedan få data att skicka över nätverket och för att bevisa att konceptet fungerar. Ett antal sensorer har satts upp för att mäta fyra viktiga parametrar: temperatur, vibrationer, strömförbrukning och rotationshastighet. Hårdvara och mjukvara för att läsa data från dessa sensorer har också konstruerats. All hårdvara är innesluten i en låda där varje sensor har ett objekt att mäta på, så som en motor och ett värmeelement.
Programmet för datainsamling använder en interruptbaserad arkitektur så att varje gång en tillräckligt stor förändring detekteras i någon av sensorerna så uppdaterar programmet DDC-signalen. Varje signal har ett unikt id-nummer och skickas vidare över nätverket med intervall som bestäms av konfigurationen.
Nomenclature
ADC: Analogue to Digital Converter API: Application Programming Interface DAQ: Data Acquisition device
DDC: Distributed Data Collector IR: Infra Red
ISR: Interrupt Service Routine LED: Light Emitting Diode LSB: Least Significant Bit MCU: MicroController Unit
PLC: Programmable Logic Controller RPM: Revolutions Per Minute
SCADA: Supervisory Control And Data Acquisition USB: Universal Serial Bus
Table of Contents
1. Register ... 6 1.1 Figure register ... 6 1.2 Schematic register ... 6 1.3 Equation Register ... 6 1.4 Table register ... 6 2. Introduction ... 7 2.1 Background ... 7 2.2 Purpose ... 7 2.3 Project limitations ... 7 2.4. The DDC ... 8 3. Problem formulation ... 10 4. Analysis of problems ... 11 4.1 Parameters of interest ... 11 4.2 Hardware ... 12 4.3 Software ... 12 5. Method ... 135.1 Data acquisition device ... 13
5.2 Hardware for measuring ... 14
5.2 Software for sampling and calculations ... 18
6. Implementation ... 20
6.1 Test bench set up ... 20
6.2 Updating signals ... 21
6.3 Watchdogs ... 21
6.4 Resolution of analogue signals ... 21
7. Discussion ... 24
7.1 Results and analysis of results ... 24
7.2 Future work ... 25
8. Summary and conclusions ... 26
1.
Register
1.1 Figure register
Figure 1 Overview of the DDC system...8
Figure 2 Phidget Interface Kit 8/8/8...13
Figure 3 Inductive sensor...15
Figure 4 Optical pulse detection...17
Figure 5 Method for measuring current...23
Figure 6 ISR issue...25
1.2 Schematic register
Schematic 1 Temperature measurement circuitry...14Schematic 2 Vibration measurement circuitry...15
Schematic 3 Current consumption measurement circuitry...16
Schematic 4 RPM measurement circuitry...17
1.3 Equation Register
Equation 1 Temperature...18Equation 2 General resolution...21
Equation 3 Temperature resolution...22
Equation 4 Distance resolution...22
Equation 5 Current consumption resolution...23
1.4 Table register
Table 1 Ports and connectors...202.
Introduction
This chapter gives a short introduction to the background, purpose and general function of the DDC.
2.1 Background
Unscheduled stops for maintenance during production is a major issue resulting in high costs in all industries. For example a bearing or a motor suddenly breaking down can have repercussions throughout the entire production line bringing everything to a halt until a service team has been assembled and been able to locate and fix the problem. A way to predict these problems would enable far more effective planning of such maintenance work - allowing it to take place during less critical stages of production and always having the service team and spare parts ready when they are needed. Another problem is machines appearing to work fine but that in reality are putting out faulty products due to minor errors that in worst cases will not be spotted until the customer uses the product. These are errors that might be hard or even impossible to find by a human operator. The sooner these problems are attended to, the more effective the production line will be, greatly reducing costs.
2.2 Purpose
To predict breakdowns and errors, the idea is to read data from various machines and processes running in the industry and collect it in a central database where algorithms for calculating the life expectancy and state of different parts are run. This is where the Distributed Data Collector (DDC) comes in. One DDC will be placed in adjacency to every process that needs to be monitored, collecting data that can tell if a breakdown is imminent. Such parameters can for example be vibrations and current consumption. This can be done either by interfacing with the sensors and systems currently in place for controlling the process or by setting up extra sensors to fit the needs of the life length models. The data collected by the DDC is sent via a network of other DDC:s and stored in a central server where all calculations and predictions are made. The system will then be able to warn the operator that i.e. a certain part will need replacing within a week or if a machine is not performing properly.
2.3 Project limitations
The wide array of different systems and processes being used throughout the world makes it virtually impossible to construct a data acquisition system that fits everywhere. Every application will need a custom made way of interfacing with the system currently in use at site. Therefore the hardware and data acquisition module (DAQ) constructed during the work of this thesis can and will only be used for development and demonstration purposes and to prove that the concept of the DDC works. The communication between the DDC:s and the server, and the system as a whole are not covered in this thesis and will only be mentioned briefly as an introduction to understanding the system, but not described in detail.
Figure 1 Overview of the DDC system
2.4. The DDC
Figure 1 shows an overview of the DDC system, and this chapter briefly describes the functions of the various components. All text and images are taken from Addiva's internal documentation on the DDC.
2.4.1 Overview
The DDC is designed to collect data from various sources on site at various production facilities. Each of these facilities have a number of already existing systems which store and collect data. The DDC will interface with these systems and gather any relevant information, depending on configuration and commands from the IMOM (Industrial Maintenance Operations Management) server.
2.4.2 The Maintenance System
The Maintenance System holds information on all hardware present in the production unit. It contains information on motors and other equipment on site, when they were acquired, specifications, manufacturer and so on. The DDC will interface with the maintenance system via its API which may vary between sites.
2.4.3 The SCADA system
The SCADA (Supervisory Control And Data Acquisition) system automates and supervises the equipment on site. Many systems also provide logging of values and provide various interfaces for monitoring the state of the production unit.
2.4.4 PLC:s
PLC:s (Programmable Logic Controllers) are used throughout the production industry to collect data and control equipment. Interaction with the PLC from an external source (like the DDC) is done via one of the available communication protocols.
3. Problem formulation
The main objective of this thesis is to set up a test bench for a DDC to be used for development and demonstration purposes. This includes:
• Investigating which parameters that are interesting to monitor
• Finding suitable sensors and ways to measure those parameters
• Constructing the hardware necessary for getting proper signals from the sensors
• Finding a cheap and simple way of interfacing the analogue and digital signals with a
PC via USB. Either building an I/O-board from scratch or ordering an existing one.
• Programming an application (input module) to read the sensor raw data and converting it into the values they represent.
• Combining the input module with the main DDC program to create a DDC signal to
4. Analysis of problems
To reach a result and a final product the problem has been divided into several subsections where each part is handled separately. These subsections are discussed below.
4.1 Parameters of interest
Because the main purpose of the test bench is to show that data can be sampled and sent across the network it is basically irrelevant which parameters are read. An application that simulates input from an external source might as well be used. However it is favourable from a demonstration point of view for the company to prove that it has the necessary knowledge in the field where the product is supposed to be used. Based on this a short investigation was conducted to determine which parameters give away the most information on the state of the process being monitored. Interviews with engineers working in the industry showed that three of the most important parameters when checking for errors are temperature, vibration and current consumption.
4.1.1 Temperature
Temperature is one of the things most commonly measured in any process. It can be used not only to measure the actual temperature, but also factors that are directly or indirectly affected by it – or that affect the temperature themselves. Such as flow and stress on materials due to heating. Increased temperature levels are a good indicator that something is wrong with a process, i.e. heating due to increased friction.
4.1.2 Vibration
Imbalance, worn gear heads and old bearings can all result in unwanted vibrations which in turn lead to even greater stress on the running machine and poor accuracy in production. If these vibrations can be spotted at an early stage and the components causing the vibration can be found and fixed, there are a lot of problems that can be avoided and money to be saved.
4.1.3 Current consumption
A motor beginning to fail tends to draw more current from its power supply. Another reason for increased current consumption is unwanted extra external load. If the motor is working harder than it is expected to do during its current state it is a good indicator that something is wrong. These increased levels can either be constant or come as periodical spikes, all giving away clues as to where and when errors occur.
4.1.4 Rotational speed
In addition to the three parameters mentioned above the rotational speed of a shaft or motor is a relevant factor when trying to discern if something is not working properly. Since current consumption and the frequency of vibrations can be a result of the actual speed of an object it is relevant to know how fast it is revolving to get a ratio between speed and other parameters of interest.
4.2 Hardware
To read analogue data from the outside world and converting it into digital values that can be read and interpreted by a computer, specific hardware needs to be constructed. This hardware includes sensors, amplifiers and filters and a way of interfacing the sensors with a computer. The requirements for the interface depend on the accuracy and sampling frequency needed and acquired from the sensors. The only demands made by the company in charge of the project is that it uses the Universal Serial Bus (USB) of the computer and that it does not simulate a COM port like some products do. The accuracy of the data acquisition device is decided by the resolution of the analogue to digital converter (ADC) where the number of bits in the conversion limits the smallest change in the signal possible to detect. The sampling frequency is limited by several factors, but the main bottleneck is the interrupt and response time of the USB. Construction of such a device will not only require specifying and putting together the actual hardware, but also developing an Application Programming Interface (API) and drivers to interact with it. All hardware will also need to be packaged to make it portable and so that it can be presented in a way that is attractive to possible costumers.
4.3 Software
Protocols for network communication and the main program to be run on the DDC which keeps track of signal subscriptions and creates the signals are provided by other developers and are not covered in the work of this thesis. The only purpose of the module that reads the input is to convert the signals into the values they represent and update the DDC when a change in those signals has taken place. This is because the input module will need to be changed and adapted for each specific system where the DDC is to be implemented. It is therefore important to keep it as abstracted away from the main program as possible.
5. Method
This chapter describes the methods used to solve the different problems and motivates why they were solved in that particular manner.
5.1 Data acquisition device
The way chosen of how to acquire data, converting it from analogue signals to a digital representation and reading it into the computer limits the way the rest of the hardware is constructed. The specifications of the ADC affect how the signals from the sensors need to be amplified. For example some ADC:s have a maximum input voltage of 2.5 volts whereas others might go up to 5 volts. A short investigation was conducted on what components and work would be required to build an I/O-board from scratch. Apart from connectors and various passive components (such as resistors and capacitors) the major parts needed are:
• Analogue to digital converter
• Microcontroller Unit (MCU)
• USB-interface module
The MCU would need to be programmed to handle the sampling and sending of data via the USB-interface to the computer, and everything would need to be soldered and attached to a circuit board. Also drivers and an API would need to be developed for the computer to communicate with the board. All this is time consuming work that is hard to motivate at this stage when there are relatively cheap existing models available for ordering. Therefore the idea of constructing a board was soon abandoned and a comparison between existing ones was initiated. These are the specifications/guidelines set up for performance of the I/O-board, apart from the ones previously mentioned:
• 8-channel, 10-bit analogue to digital converter
• At least 4 digital inputs
• Low cost
• Easily programmable and well documented API
• Supported by Linux based systems
The choice fell on the Phidget interface kit 8/8/8 (figure 2), which connects eight analogue and eight digital inputs to the computer via USB. It also provides eight digital outputs, which are not used in this project. The ADC has a
10-bit resolution over a span of 5 volts allowing
for a minimum detected change of 5/210 ≈ 5
mV. The sampling rate is ~65 Hz for the analogue inputs, and ~125 Hz for the digital ones (www.phidgets.com, 2010-03-01). These are relatively low figures but acceptable for the requirements of this project. Note that this
One major advantage with this interface kit is that all code written with the C API is platform independent and can be moved between Windows and Linux only requiring that you include a different library. It is also powered by the USB-port, so no external power supply is needed.
5.2 Hardware for measuring
All hardware is powered by a twelve volt power supply, motivated by the minimum of ten volts requirement of the sensor for measuring vibrations and because twelve volt DC-adaptors are commonly available. This chapter describes the different circuits and methods used to measure the different parameters previously specified. All circuit diagrams are only representative for the concept of measuring the respective signals and do not describe the circuit board a whole, leaving out decoupling capacitors, LED:s and such components.
5.2.1 Measuring temperature
Schematic 1 shows the circuitry used for measuring temperature. The temperature sensor used is a LM35DZ whose output is linearly proportional to the centigrade scale with 10 mV/°C. At 0°C it puts out 0 V and for every degree the temperature changes the voltage increases or decreases with 10 mV. It has a temperature span between -55°C and +155°C, however this configuration does not allow for negative voltages, meaning that it cannot measure temperatures below zero. The supply voltage for the sensor is limited to 5 V with the use of a TS7805 voltage regulator. The outgoing signal is amplified roughly four times by
the non-inverting amplifier which gives the sensor a span from 0°C to about +120oC before
the 5 V input limitation of the ADC is reached. Temperatures above +120oC may damage the
ADC and the interface kit, so it is important not to expose the sensor to such levels. The amplification is done solely to give the readout a higher resolution, at the cost of some accuracy due to recalibration errors. Before the signal reaches the ADC it is passed through a standard, first order, passive low-pass filter with a low cut off frequency of roughly 35 Hz to filter out fast fluctuations in temperature and noise induced from other circuitry.
Schematic 2 Vibration measurement circuitry
5.2.2 Measuring vibrations
To measure vibrations an inductive sensor (figure 3) is used which reacts to objects with magnetic properties 3 to 8 mm away from it, giving off a linear response relative to the distance. Note that the sensor's sensitivity and output voltage change with the supply voltage. It is therefore important to remember that this set up is calibrated for a 12 V supply and that changing the supply voltage will require recalibration of the algorithm used to calculate the distance between the sensor and the object being monitored. A differential amplifier is used to amplify the signal approximately 3.2 times. The output from the sensor is close to 9 V when the distance to an object is 8 mm or more and it increases linearly with roughly 1.5 V until the minimum distance of 3 mm is reached. Outside the 3 to 8 mm span there are no changes in voltage so there is always an
output between approximately 9 V and 10.5 V. Therefore a potentiometer is used to get a zero reference level on the inverting input of the OP-amp to get an output from the amplifier between 0 V and 5 V to fit the span required by the ADC and to prevent saturation of the OP-amp. The high output voltage from the sensor is also the reason why an instrumentation amplifier, which has better performance (Molin, 1993, p 139-140) is not used. The OP-amps are only fed with a 12 V supply so the ones in the first stage of the instrumentation amplifier will be saturated due to the high inputs from the signals. Another reason for the differential amplifier is that it saves components and space on the circuit board. Before being passed to the ADC, the signal is low pass filtered to eliminate frequencies above roughly 30 Hz.
Figure 3 Inductive sensor
(source:
www.bernstein-ag.de, 2010-03-01)
5.2.3 Measuring current consumption
A small DC-motor is powered by a transistor with a potentiometer as throttle to allow for changes in current consumption and speed without changing the load on the motor. The principle behind measuring current is to measure the voltage drop over a small resistor connected in series with the motor and to use that value and the known value of the resistor to calculate the current with Ohm's law (I = U/R). Since almost no current is going in to the OP-amp all current can be assumed to pass through the motor, the transistor and the resistor (R4). The amplifier is set up to amplify the signal roughly 14 times to allow for measuring of currents up to around 350 mA. Any currents above that limit will result in voltages in excess of 5 V and may damage the ADC and the interface kit. No steps have been taken to limit that voltage other than using a motor that through experimentation has never exceeded a current of 100 mA. The filter has a low cut of frequency of around 10 Hz to eliminate as much noise as possible from the motor. A diode is mounted parallel to the motor to protect the transistor from energy stored in the coils of the motor when the power is switched off. Although the test bench only uses a small DC-motor driven by a maximum of 12 V to measure current through, the DDC is most likely to be used in situations with industrial sized, high power AC-motors. The choice of using a DC-motor is motivated by the need for mobility at demonstrations and because of it being easy to manage and control.
Schematic 4 RPM measurement circuitry
5.2.4 Measuring rotational velocity
To measure the rotational velocity of the outgoing shaft from the motor an optical method to register pulses is used. An infra red light emitting diode (IR-LED) is placed next to a phototransistor that responds to infra red light. The light from the LED is reflected off a piece of tape attached to the shaft, causing the phototransistor to periodically open and close. The voltage over the transistor is sent through a comparator, where the reference level is adjusted by a potentiometer, putting out a logical zero when the reflexive tape passes the LED. To protect the digital input of the interface kit from the rest of the circuit an optocoupler is used. The optocoupler also inverts the digital signal by putting out a logical one when the tape is passed. This is read by the interface kit as a logical zero due to its inverted inputs, which is favourable because the interface kit responds faster to positive flanks than negative ones and the signal stays low for a shorter period than it stays high. Another advantage that comes with the optocoupler is that it is able represent the logical ones with 5 V whereas the OP-amp used as a comparator only reaches around 3.5 V due to the 5 V power supply combined with the limitations of the OP-amp. The pulses emitted by the circuitry are then counted and timed and used by software to calculate the speed of the outgoing shaft of the motor. Because of the low sampling frequency of the interface kit only one pulse is measured per revolution. To achieve higher resolution and better accuracy more pulses should be registered, but that would also require lowering the speed of the motor with the same factor as the pulses have been increased with to avoid sampling errors. The motor used is fitted with a gearbox which limits the speed of the outgoing shaft to a maximum of roughly 200 rpm.
Equation 1 Temperature
5.2 Software for sampling and calculations
The Phidget interface kit 8/8/8 that was chosen to read the signals from the sensors uses an event-based architecture. This means that every time a change is detected on one of the inputs an interrupt is issued and an interrupt service routine (ISR) is called. It is possible to ignore these interrupts and instead use an approach where the interface kit is constantly polled for the values, however that is not recommended by the manufacturer and it would further complicate the programming of the device. Each analogue input channel has its own settings for sensitivity where the user can decide how big a change needs to be registered in order for the ISR to be called. For further information on how the interface kit is being handled refer to the documentation of the Phidget21 API (available at www.phidgets.com, 2010-03-01).
All data read from the sensors is represented by an integer value, spanning between 0 and 1023 for the analogue signals, and 0 or 1 for the digital ones. The upper limit of 1023 is due to the 10 bit conversion in the ADC that allows for 1024 different values (210 = 1024). These values only represent the output voltage of the amplifiers and need to be processed further in order to be converted into the values of actual interest, such as temperature and distance. Formulas for interpreting the sensor raw data are derived from measurements and calibration of the hardware. These formulas are then used in algorithms to calculate the different parameters of interest.
5.2.1 Calculating temperature
The method for calculating the temperature registered by the sensor is fairly straight forward. Since the sensor is calibrated to put out 10 mV/°C and 0 V at 0°C the voltage read by the ADC is divided with the amplification (A) of the amplifier and multiplied with 100 to get a value in °C. For example an input voltage of 1 V is read by the ADC and the signal has been amplified around four times meaning that the sensor puts out
1/4 V= 0.25 V
This value is then multiplied by 1000 to convert it from V to mV and divided by 10 to see how big a change in degrees from 0oC that represents:
0.25 V * 1000 = 250 mV 250/10 = 25oC [V/(V/°C) = °C]
The last two steps are simplified by just multiplying with 100 directly giving the final equation:
5.2.2 Calculating vibration amplitude and frequency
Due to the low sampling rate of ~65 Hz on its analogue inputs the Phidget Interface Kit 8/8/8 is in no way suitable for monitoring vibrations, which is a complex subject involving a lot of digital signal processing and frequency analysis. So the methods used in this thesis are extremely simplified to limit the demands on performance of the hardware and software. In the end it is not the DDC:s job to analyse the signal, only to pass on the data acquired, and different ways of acquiring the data will be implemented. The algorithms used here are only designed to calculate mean values of amplitude and frequency over a set number of periods. These values are basically only useful when measuring on objects oscillating with stable period times and amplitudes. One feasible implementation could be to watch for misalignment of rotating shafts and axles. However, the raw data from the sensor measuring distance to the object in question is also passed on from the DDC to be further analysed and processed in a later stage of the system. This is where a major issue with using interrupts comes in; since the signal is only updated when a change has been registered there is no way of setting the sampling frequency of the incoming signal, which needs to be known for proper analysis. One way of getting around it is to sample the sampled signal at a known interval, but at no higher rate than the 65 Hz limit of the interface kit to avoid aliasing and misrepresentation.
A linear equation for calculating the current distance between the sensor and an object has been derived from measuring and calibration of the hardware. The program checks for positive and negative peaks in the distance between the sensor and an object to calculate amplitude and frequency of vibrations. When a set amount of peaks have been found a mean value of the amplitude of those peaks is calculated and the value of the signal is updated. The program also measures the time between the same number of peaks and uses the average time it takes between two peaks to calculate a mean frequency.
5.2.3 Calculating current consumption
Current consumption is calculated simply with the use of Ohm's law and the known amplification of the signal. Ohm's law states that I = UR/R, where UR = Uin/A is the voltage drop over the resistor and A is the amplification of the signal. And since the resistor used to register a voltage drop over is at R = 1 Ω, the formula can be simplified to I = Uin/A. This value is also used to calculate the energy consumption in watts just by multiplying it with the 12 V level of the power supply (P = I*U).
5.2.4 Calculating rotational velocity
Each time a pulse is issued by the IR-LED/phototransistor-pair a counter is incremented and when that counter reaches a specified value the time between the first and and last pulse is registered. This timer is used to average a value in revolutions per minute of the outgoing shaft of the motor. The number of pulses that needs to be registered before calculating the speed is configurable by just changing one variable in the software. If the motor rotates too fast the interface kit will not be able to register and handle the pulses resulting in sampling errors and incorrect values. The highest frequency of ingoing pulses possible to handle varies with the rate the other inputs issue interrupts. That is why a motor with relatively low speed
6. Implementation
This chapter describes the general functionality of the test bench, its performance and how it is used.
6.1 Test bench set up
When the Phidget interface kit is attached to an USB-port of the computer being used to run the DDC-program on the program will automatically recognize the interface kit and start waiting for interrupts. If the interface kit is not attached when the program starts running or is detached during runtime the program will go into a state where it waits for the kit to be reattached. It is currently programmed to wait indefinitely, but can be set to time-out if an attachment is not registered within a specified time frame. Note that the power supply for the sensors and other peripheral hardware does not need to be turned on in order for the interface kit to be recognized as it is powered via the USB.
6.1.1 Analogue and digital connectors
Each signal has to be connected to a specific port of the interface kit, as specified in the software. This is because there is no way for the program to know what kind of sensor is currently connected and what it's output represents – all it reads is a voltage. Connecting the wrong wire to the wrong input will result in the wrong algorithm being run on the wrong signal leading to corrupt values. The inputs are currently specified as shown in table 1, but can be changed and more can be added by editing a header in the software.
Sensor/function Port Colour of wire
Vibrations A0 green/yellow
Current A1 grey/white
Temperature A2 blue/purple
Rev counter D7 brown/red
Table 1 Ports and connectors
It is important that the ground pin of the interface kit is connected to ground on the circuit board. Reversing polarity may result in damages to the computer.
Equation 2 General resolution LSB U X RESX * ∆ ∆ =
mounted with a slight offset and at an angle to cause imbalance.
A light bulb, which can be turned on and of with a switch, is mounted next to the temperature sensor. When it is turned on it generates heat and the sensor will register the increase in temperature. This is a simple way of showing that the sensor works and responds to changes.
6.2 Updating signals
Each signal coming from the input module is provided a unique identification number by the DDC and this id then used and recognized by the DDC and the server logging and subscribing to the signal. Whenever the input module registers a change in one of the values it is monitoring it sends an update to the DDC with the new value and its corresponding id. The DDC however does not immediately pass this update on across the network since it uses timed updates instead of interrupts. Each signal in the DDC has an update frequency configured by the central server and is only passed on at a certain interval. This is done to limit unnecessary data flow across the network. Also there is a difference in what update frequency is interesting and necessary for the different signals, i.e. the current amplitude of vibrations changes fast and needs to be constantly sampled whereas temperature may vary at a lower rate. It is important to remember, while using this set up for acquiring analogue data, not to update signals faster than 65 times per second, since that is the maximum rate of which they are sampled. Signals measured which contain frequencies higher than ~30 Hz cannot be trusted according to the sampling theorem because they exceed the Nyquist frequency (Harnefors et al., 2004, p 30).
6.3 Watchdogs
Because the interface kit only notifies of registered changes, and updates only are made when those changes issue a call to an ISR, some algorithms using a count of how many times that particular ISR have been called will sometimes not be able to be fully run. Say i.e. that the motor stops with a last known speed of 200 rpm. This means that no more pulses will be registered and the value of 200 will not be recalculated and updated until the motor starts running again. A similar issue is found with the function calculating vibrations. This is solved with the use of watchdog timers which, if a change has not been registered within a specified time frame, resets the values of the affected variables to zero.
6.4 Resolution of analogue signals
Each analogue signal is represented by a 10-bit digital value over a span of 5 V meaning that the LSB (Least Significant Bit) of the ADC represents ~5 mV, which is the smallest change that can be detected and the main limitation of the resolution. The different sensors also have different built in limitations to their maximum values and in which span they work, also restricting the resolution. This chapter describes a theoretical estimation of the resolution for each sensor. The equation used for calculating the smallest change possible to detect is:
Equation 3 Temperature resolution C LSB U T REST = = ° ∆ ∆ = *5*10− 0.12 5 120 * 3
representing the smallest change possible to detect by the ADC.
6.4.1 Temperature resolution
Using equation 2 from above and substituting X → T, where T is temperature, the resolution of the temperature sensor can be calculated. As mentioned in chapter 4.2.1 the sensor has a span of 0-120°C over 5 V giving
|ΔT| = 120 – 0 = 120°C And
|ΔU| = 5 – 0 = 5 V
Insertion into equation 2 gives:
This is the smallest change in temperature that is possible to detect with this set up of sensor, amplifier and ADC.
6.4.2 Vibration amplitude resolution
The resolution in the current distance between the inductive sensor used for measuring vibrations and an object is calculated in the same manner but by substituting X → d, where d is distance. The sensor reacts to objects between 8 and 3 mm away giving
|Δd| = 8 – 3 = 5 mm.
At 3 mm it gives out ~4.7 V and at 8 mm ~0.4 V resulting in |ΔU| = 4.7 – 0.4 = 4.3 V
And
Equation 4 Distance resolution
6 10 * 6 10 * 5 * 3 . 4 5 * = 3 ≈ 3 = ∆ ∆ = LSB − − mm U d RESd μm
6.4.3 Current consumption resolution
By substituting X → I, where I is the current passing through the resistor, a resolution when measuring current consumption can be derived. Since there is no limit to how much current can be passed through the resistor and the motor (apart from the physical one where i.e. the resistor overheats) ΔI needs to be calculated from the 5 V span of the ADC (ΔU = 5 V) and the 14 time amplification (A) of the signal. The maximum value I is allowed to have is one resulting in a 5 V signal out from the amplifier. According to Ohm's law
I = Uin/R
Where in this case R = 1 Ω
And
ΔUin = ΔUout/A = 5/14 = 0.35 V
See figure 5 for details. These values of Uin and R give |ΔI| = 0.35/1 – 0 = 0.35 A = 350 mA
And
Equation 5 Current consumption resolution
mA LSB U I RESI *5*10 0.35 5 350 * = 3 = ∆ ∆ = − A ADC R I Uin Uout
7.
Discussion
The results of the thesis, the test bench that has been deigned and its features are explained, analysed and discussed in this chapter. Also some points on what could be improved in future work and what problems have been encountered and solved are presented.
7.1 Results and analysis of results
The test bench constructed has relatively low performance compared to systems being used in the industry which the DDC is supposed to interface with. The interface kit has a low resolution in the analogue to digital conversion, and a really low sampling frequency. But since the test bench is only designed for presentation and development purposes and not to implemented in a live process it does not really matter. The only important thing is that signals are being read and passed on across the network. Based on this the the sensors and the algorithms used to analyse the values read are allowed to be poorly calibrated. Another reason for the poor accuracy is a lack of access to equipment needed for proper calibration. These limitations are not built into the hardware of the sensor-circuitry, so if one wishes to improve performance one would only need to recalibrate the sensors and possibly upgrade the interface kit. This will naturally result in having to reprogram the input module to be compatible with the new DAQ, but this is something that will need to be done in every unique application where the DDC is to be implemented.
7.1.1 Analysis of hardware
All hardware for the sensors, such as amplifiers and filters are soldered onto an experimental board, which is not an ideal solution. To further increase performance and reduce noise it should be mounted on a proper circuit board with ground planes and properly drawn wires. The biggest issue encountered while constructing the hardware is the noise induced into the circuitry when running the motor. Because of the need to limit the speed of the outgoing shaft, a motor with a gearbox is being used. This is an old and worn out gear box which does not run smoothly resulting in large spikes of current when the gears connect and apply load to the motor. These spikes affect the power supply of the entire circuit and the stability of the other sensors. To limit this problem large decoupling capacitors are used, but they do not fully eliminate the noise. The biggest problem with these spikes is apparent when measuring the actual current being drawn by the motor. Because the current is constantly fluctuating with relatively high amplitude and the interface kit is not able to handle too high data rates the signal is passed through a filter with a really low cut-off frequency of 0.33 Hz before reaching the amplifier. If this filter is not used the signal will greatly affect the performance of the OP-amp circuit which starts to oscillate and corrupts the signals coming from the other sensors. Another step taken to limit the effect of these spikes in current is that the circuitry
ISR1 --- <start timer> <command> <command> <stop timer> <calculate> <rerturn> ISR2 --- <start timer> <command> <command> <stop timer> <calculate> <rerturn>
Figure 6 ISR issue
7.1.2 Analysis of software and interface kit
The API and design of the Phidget interface kit 8/8/8 has been the biggest factor when deciding on how to design the software for acquiring data. Because it uses interrupts to let the user know when a change has taken place there is no need for setting timers and sampling frequencies which can be quite complex. This has simplified programming but also has some apparent drawbacks - the biggest one being that there is no way of setting the priority for the interrupts. One issue encountered
during development was that when several sensors changed too rapidly, the program started to put out corrupt values. It was discovered that this is due to one ISR being interrupted by a change in another signal, delaying the timers used in that particular ISR. Figure 6 shows a representation of such an error where the timer in ISR1 is not stopped when it should. To avoid these errors the hardware has been given certain limitations, such as a slower motor, and also the sensitivity of each analogue input is configured not to issue interrupts from too small changes in the signal.
The configuration of sensitivity of each signal in the software also has certain effects on the values calculated. Especially on the function calculating average frequency and amplitude of vibrations because increasing sensitivity will result in the detection of lower peaks, which will otherwise be filtered out. These lower peaks occur more often than the large ones and will naturally affect the average amplitude and frequency if they are detected. The algorithms are still somewhat useful, but they only calculate values representing an average of frequencies and amplitudes larger than the minimum change in distance possible to detect. To get reliable values from the algorithms calculating amplitude and frequency the incoming signal will need to be as clean and stable as possible. Signals with high frequency content will result in larger errors, and more misleading values. The proper analysis of vibration is not meant to be handled by the DDC, which is why the algorithms used in this thesis are allowed to be less accurate, as long as they result in a value of some interest. Since the raw data of the current amplitude is constantly logged and passed on by the DDC, there is still a possibility to implement more advanced analysis of the signal at a later stage of the system.
7.2 Future work
There is still a lot of work to be done with the DDC-system – mainly with the server where all data is to be collected and analysed. However a method for collecting and sending data has been developed and the concept has been proven to work, and that is the only purpose of this thesis. Future work based on the thesis could consist of developing a product for acquiring data from scratch to be used with a specific set of sensors that can be mounted and used by the DDC for general data acquisition to eliminate the need to interface with existing systems. Another thing that should be done is to properly calibrate the sensors in a more controlled environment to get more accurate values.
8. Summary and conclusions
The problem consisted of investigating which parameters are of interest when trying to decide the state of a machine or process and finding sensors suitable for measuring these parameters. Hardware and software for getting these signals amplified and read into a computer had to be designed to be able to pass the values on across the network. Four different parameters were found to be of most interest:
• Temperature
• Vibrations
• Current consumption
• Rotational speed
A test bench consisting of a box containing various sensors and objects to be measured against, such as a motor and a heating element, was constructed. Temperature is measured with a simple sensor that responds linearly to changes in temperature. To measure vibrations an inductive sensor is used which reacts to objects between 3 and 8 mm away and puts out a different voltage depending on the current distance to the object. This distance is used by the software to calculate average values of amplitude and frequency of the vibrations. The current consumption of the motor is calculated by measuring the voltage drop over a small resistor connected in series with the motor. To measure the rotational speed of the motor an IR-LED (Infra Red Light Emitting Diode) and a phototransistor that reacts to infra red light is used. The LED emits light which is reflected off of a reflexive tape attached to the outgoing shaft of the motor. This is registered by the phototransistor which periodically opens and closes giving off one pulse per revolution of the shaft. These pulses are timed by the software to calculate a value in revolutions per minute.
To get the analogue signals read into a computer a Phidget Inteface Kit 8/8/8 is used. This interface kit is attached to a USB-port of a computer and supports 8 analogue and 8 digital inputs. All analogue signals are amplified to fit within the 0-5 V span of the ADC built in to the interface kit, and filtered to limit too high frequencies and fluctuations. Once the signals have been sampled and their corresponding values have been calculated the module that reads the data updates the DDC where each signal has been given a unique id number. This signal is then passed on by the DDC at set intervals depending on configuration and the subscriptions made by the server where the data is to be logged and analysed.
9.
References
• Harnefors, L, Holmberg, J and Lundqvist, J, (2004), Signaler och system, Liber AB,
Stockholm.
