This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
This report covers the development and implementation of a system that increases the understanding of energy transfer characteristics within solar simulations -Photo Voltaic test rigs.
Solar Simulators are apparatus used in the research and development of Photo-Voltaic production. They mimic the relative power experienced from the sun onto the earth's surface, with the ability to vary the environmental conditions.
Understanding the behaviour is vital to the classification and rating of any manufactured device but to confidently comment on a products performance, firstly the test and verification apparatus needs to be analysed, confirming the rating accuracy.
This is the motive behind developing this control and monitoring system. It is to produce the characterisation of a functional Solar Simulator based at the Loughborough University's 'Centre of Renewable Energies and Sustainable Technologies' (CREST).
Analysing the homogeneity of the light source(s), produces true measurements of how much energy is transferred /available for conversion by a Photo-Voltaic panel. Taking regular measurement increases the accuracy and also produces a lifetime characteristic of the light source as they degrade.
Table of Contents
DAQ - Data Acquisition
HMI - Human Machine Interface
PV - Photo Voltaic
USB - Universal Serial Bus
VI - Virtual Instrument - LabVIEW programme code
CREST - Centre of Renewable Energy and Sustainable Technology
In the modern environment, there is an emphasis on pushing every device to the absolute limit. This is ever present in the design, construction and development of renewable energy systems.
This control and monitoring of renewable energy test rigs report looks at how a system is designed and developed to assist manufacturers and researchers to achieve this target of a near perfect renewable energy generation product.
The rapid growth of the Photo-Voltaic (PV) sector of the renewable industry has increased the requirement to maximise the productivity of every panel. Manufacturers create a PV panel by connecting a series of PV cells (single units) in a configuration that produce a design specific voltage and/or current, along with a desired efficiency and power rating. The manufacturers rating can vary subject to the method of testing they choose to use, either testing of a single cell from the batch used to create a panel, or the testing of the complete panel itself.
Discrepancies within the production and testing processes can cause the true rating of a panel to differ from the designed model rating. This requires panels to be sent for external certification of their efficiency, durability and their true power rating. To calculate this there are apparatus available that mimics the sun's energy under the conditions that are experienced on the earth's surface. Known as Solar Simulators they are capable of producing a similar energy yield to that of a bright, clear summer's day. Assuming an ideal solar simulator, where each simulation provides 100% power transfer across the test area and with zero degradation on the light source and a perfect power supply, the PV panels are tested to check their specification ratings.
Unless the light source used can be truly characterised and the test area energy distribution analysed, any results found are still only an estimate subject to the apparatus accuracy. This is where a control and monitoring system is needed to give the detailed description and accurate energy transfer pattern analysis of the test area.
PV panels (also known as Solar panels) are constructed of semi-conductor materials and are designed to convert solar radiation energy into usable clean electrical energy. There is not yet a perfect PV panel and the efficiency of the current range of PV panels on the market varies from 12% - 35% efficient . The reasons for the efficiencies varying so much are down to the construction methods and the selection of materials used in producing the semi-conductor substrate.
The cost of a PV system reflects how efficiently they can convert the solar energy into electrical energy and this is what makes the certification of a PV panel so vital.
Each panel is made of an array of individual PV cells connected in series and/or parallel configurations, with each cell contributing to the total power output of the panel. In operation the total area of the constructed panel is often subject to a variety of energy levels, thus resulting in the limitation of the output power available at any given time. The characteristics of the semi-conductor material and the inter-connection of the cells are the reason for these limitations, due to the way the electrons move within each layer of Semi-conductor material. The movement is somewhat proportional to the instantaneous solar energy that the surface of a cell is exposed to.
If a set of PV cells are connected in a series arrangement and exposed to a large variation of energy at the same time (simulation testing), the resulting power is restricted by the least active cells. This appears as an inefficiency at the point of testing, however when used in an application, a higher than anticipated power maybe produced. This unexpected level of power may potentially damage the system of which the PV panel is part of. Unexpected occurrences like this is, in part, due to the environment which a PV panel is activate in and is caused by the physical way in which energy radiates from its source.
For any point source emitter the energy radiates in a uniform spherical field, with the total energy staying constant but the area it's dissipated over is the growing spherical field's surface area. This means at any distance away from a point source emitter the energy density can be calculated, as the energy is distributed homogeneously over the surface area which increases at a rate of 4 x R² (See figure 1 - below).
A PV panel in operation, whether that be in test conditions or in a real world application, its flat surface is exposed to a spherical energy field. Using this principal the understanding of the homogeneity of energy transfer becomes clearer. For this reason, simulation results will always display a slight discrepancy to results obtained from the same PV panel in the natural environment.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\energy propogation.bmp
Figure 1 -
As shown the energy available across a flat surface will vary due to the spherical nature of the distribution of energy
The Sun is assumed to be a point source of energy producing a constant spherical energy field. Solar radiation travels approximately 149598 million metres before it reaches earth, using the principal pictured above, the sun's energy has become distributed across a spherical surface area of approximately 281233204000 billion square metres (See figure 2). With a PV panel only requiring the exposure to approximately 1-2 square metres, this allows us to believe that the energy available will have very little variation over this relatively small area.
C:\Documents and Settings\Jordan Power\My Documents\My Pictures\Sun on Earth energy transfer.bmp
Figure 2 - The earth experiencing only a fraction of the total solar radiation
Therefore using the sun would be the best way to test each PV panel, but this is not possible due to weather conditions constantly varying and it would not be cost effective for the manufacturers.
Simulation test rigs are used to provide this cost effective and reliable environment, and are becoming standardised equipment used for testing all PV panels.
These test rigs are known as Solar Simulators. Solar simulators are chambers used to mimic the sun, they achieve this with the use of multiple bulbs powered by a high power charging system (charges up and discharge rapidly through each bulb simultaneously). These systems are fully controllable enabling them to simulate the wide variety of light intensities.
The combined output of the flash tubes can produce approximately the same relative power to that of the sun, but they are situated closer to the PV panel (Unit under test). Using the same theory that enabled the assumption to be made that the suns energy is homogeneous upon the earth's surface, it can be calculated that the energy from a solar simulator source will fall inhomogeneous across the surface of the PV panel test area.
If the solar simulator had a point source of energy, the surface area of the spherical energy field at the close range distance of 7.6 metres would be approximately 726.6 square metres. With a PV panel requiring the same exposure area of approximately 1-2 square metres allows us to believe the energy will have more variation due to the relative increase in area and the interaction of the spherical field and the flat surface.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\energy propogation.bmp
Figure 3 - The interaction between an energy field and a flat panel surface
The system to control and monitor renewable energy test rigs
The solar simulator used to develop the system for analysing homogeneity, belongs to the Loughborough University's research centre - 'CREST'.
The energy source within the simulator is a four tubular bulb system powered by high charging supply, both purchased from PARSAN.
The tubular bulbs are Xenon filled flash tubes, which form a square formation inside the housing. The set of flash tubes mount onto a reflector back panel. The whole housing is designed to emit all of the energy towards the test area. This housing and mounting configuration introduces more variables into the calculations for determining the total energy field strength at the multiple contact points on the test area. With each of the four flash tubes radiating its own energy field, which propagate differently and overlap with the energy fields produced by the other flash tubes. The addition of any reflected energy from the housing that also contributes to the overall energy field.
The system to monitor the homogeneity is therefore required to measure the exact distribution of this energy from it's multiple point light source. In addition this system also allows the monitoring of bulb degradation, as each of these components may wear at different rates and ultimately cause the energy levels to differ. These results lead to verifying the accuracy of 'CREST's solar simulating test rig and help explain the behaviour of each PV panel.
The system is predominantly software controlling hardware devices used to automate, trigger and capture data. The software used is National Instruments LabVIEW, it used widely in the engineering industry for test and measurements. For this system it provides the blank canvas for the control and monitoring programme to be developed. LabVIEW is a graphical programming environment that works on the principal of data flow. With its dual programming environment, the front panel display and a block diagram programming environment create an easily understood and informative display, whilst hiding the technical control and measurement programming of the system in the background.
Using multiple sensors fixed to a bar to produce analogue signals that represents the variation of energy over the test area. The sensor bar mounts onto a movable rack which allows the sensors to move vertically. The output from the sensors is transmitted to the host computer via shielded cables and a cable terminal box. The cable terminal box acts as the input to the data acquisition (DAQ) card in the host computer; it also supplies an output triggering signal that controls the flash of the light source. The programme uses the data gathered by the DAQ card to create a numerical interoperation of the energy over the test area; these values are converted into an onscreen visual display for easy interpretation. The programme then creates and archives a structured text file, containing test data ready for future reference.
A single computer plays host to all the data logging, data file storage, motion and triggering control and HMI programmes.
Before this project started the solar simulator chamber had a PASAN light source with a PASAN supplied computer for controlling the high charging power supply and acquiring PV test measurements. A static frame used for mounting the PV panels on at the opposite end of the chamber and safety screening to separate the operators and the high intensity light.
Development of the system required the addition of a motion system with measurement sensors and a host computer.
The software of the system was developed in four distinctive sections:
Motion and triggering control
Storage of data
The Human Machine Interface (HMI)
Alongside the software all related hardware required implemented:
Motor mounting (See figure 4)
Construction of sensors
Machining of the sensor mounting bar (See Figure 6)
Total assembly including wiring (See figure 5)
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\PB240194.JPG
Figure 4 - Stepper motor and reduction gearbox mounted in place.
C:\Documents and Settings\Jordan Power\Desktop\camera Photos\project photos\P4150668.JPGC:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\pics for final report\P4150666.JPG
Figure 5 Figure 6
Figure 5 - Test area frame with the PV homogeneity monitoring frame in place.
Figure 6 - The sensor bar sitting at rest on the bottom of the frame.
Motion and Triggering control
The motion control element of the system is required in order for the sensor bar to be accurately positioned for each measurement during a monitoring session, each movement needs to be equal for the measurements to correlate. Utilising the fixed frames integrated belt pulley with the addition of a stepper motor and reduction gearbox provided the system its vertical motion.
With the sensor bar mounted onto the moving rack of the belt pulley assembly reading can be obtained from any point over on the frame. The stepper motor driving through a reduction gearbox provides the torque necessary to raise the weight of the rack with the sensor bar, sensors and all cabling (See figure 4 and 6).
The frame assembled in the test area (See figure 5) is mounted on a set of pivot, which enable the monitoring system to swing into position and be used with little time wasted with constructing and setup.
The stepped motor is required to raise the bar in stages of equal intervals from its point of rest (at the bottom of the rack) to a specified height. The distance of each interval is configured in the software on the host computer, at the beginning of the each monitoring session. The choice to use a stepper drive to provide motion to the system comes from the accuracy of movement and the positional information provided by this type of drive. Knowing the exact position the rack is on the frame allows the controlling programme to prevent the motor from driving the rack too far and potentially damaging the gearbox and pulleys. In addition if the system needs to be manually setup before a session, the motor can be told to drive a distance with millimetre accuracy.
To configure the stepper drive for each monitoring session, a series of commands were transmitted via a universal serial bus (USB) link between the computer and stepper driver. A series of LabVIEW programmes were used to establishing the serial communications needed to transmit and receive each command. LabVIEW uses the National Instruments serial communication protocol called VISA to write and read data transmitted over the USB communication port.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\vias write.bmp
Figure 7 - Block diagram code that transmits each command via the VISA protocol.
Using VISA (Figure 7) gives the programmer control over any of the computers serial communication ports, in as much detail as setting up communication line, the baud rates and the waiting times for each device. The USB port used in this system is configured as COMM 3 at a baud rate of 115200. The time out was set to 1 second which was twice as much time needed for the confirmation reply from the stepper drive at the other end of the USB link. Setting the communications configuration creates a 'Session Com' channel reference which means once it is created, the commands can be transmitted at any point within the programme, simply by referencing the channel and setting the necessary command for the movement. Once the systems requirement to communication is finished the 'Session Com' needs to be terminated.
These 'Session Coms' are designed to ensure that once a communication channel has been activated by a device on a specific port, that no other device or system can gain access to the port to transmit or receive data until the session is terminated properly. This stops any miss communication or even the termination of commands being sent to the wrong device. This also means that if a successful session com set up is incorrectly terminated, the serial port used will be inaccessible until the port is reset.
The LabVIEW programme code (VI) also uses this protocol, in another sub programme, to transmit the command for the stepper drive is to move and then waits to receive the confirmation that the stepper motor has reached its destination before continuing the programme. This function runs as part of a series of functions, but only when it receives a data input along a virtual wires that connect each function (See figure 8).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Visa movement.bmp
Figure 8 - The command that instructs the stepper driver to move the motorised rack.
As sections of the motion and triggering programme are required to function more than once in any monitoring session, each functioning section of code (VI) is created as a sub function (Sub VI). This helps to minimise the overall software size of the system and makes duplicating functions more accurate, as each function is identical. The series of serial communication functions are all coloured green within the programme (See appendix for VI's).
For each time the sensor bar moves to a new position during a monitoring session, the controller for the light source requires triggering. Supplying a digital trigger comes from the host computers on-board DAQ card. This signal operates a relay which closes a set of contacts to initiate the power supply discharge through the light sources (See figure 9).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\pics for final report\P4150669.JPG
Figure 9 - Digitally controlled relay used to control discharge.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\digital trigger.bmp
Figure 10 - Block Diagram code for outputting the digital triggering signal.
The digital trigger is output from the digital output line on the DAQ card with the use of National Instruments hardware driver DAQmx. The driver configures the port that the signal is sent from, the type of signal to be sent and the rate at which it is sent.
As, the signal required is a continuous digital high for a period 150 milliseconds, an outputting channel was configured. Using sequential programming methods (a sequence structure), a digital high is written to the specified output line. Followed by a programmed pause to ensure the system has sufficient time to recognise the signal, before a digital low is written to the output line (See figure 10).
Once the relay is activated, the system waits for the standalone charging system to reach an optimum level. This charge is then automatically discharge to produce a pulse of energy. The pulse of energy is measured using the sensors mounted on the bar and rack. The data is then stored before the process repeats itself (moving the sensor bar, triggering an energy pulse, measuring the energy) until the whole test area has been measured as specified at the beginning of the monitoring session.
The triggered energy pulse is measured using photo sensors mounted at equal intervals across a bar. The bar moves vertically on a motorised rack located at the test area of the solar simulator.
A total of 22 photo sensor were constructed and now mounted across the width of the test area. This in conjunction with the ability to move vertically, provided a complete surface area measurement or even a half area measurement. The sensors record data from one flash for each vertical movement of the bar. This system uses the multiple flashes to create one full area measurement; the number of flashes is configured in the human machine interface (HMI) at the beginning of the session.
C:\Documents and Settings\Jordan Power\My Documents\My Pictures\hohgenity data graph.bmp
Figure 11 - Digital image of energy distribution in simulator environment
Each sensor circuit outputs an analogue signal that represents the level of energy that as radiated on it over the energy pulse period (See figure 12). These 22 sensors are individually wired to analogue input lines of the DAQ card via a terminal box (See figure 13 - Overleaf).
The DAQ card then multiplexes through all the input lines, measuring a number of data samples from each sensor before looking at the next line. The DAQ card then passes the information gathered through the analogue to digital converter and into the program running on the host computer via the DAQmx drivers. The programme then takes an average of the values from each sensor per stage of the session to guarantee a true representation of the energy distribution over the area (See figure 11).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\pics for final report\P4150664.JPGC:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\pics for final report\P4150665.JPG
Figure 12 Figure 13
Figure 12 - Two photo sensors mounted and wired prior to a monitoring session
Figure 13 - The terminal boxes used to wire each sensor into the DAQ card
The controlling programme uses the DAQmx hardware driver to configure the number of channels it is to read from, the type of data it will receive and the rate in which data is to read. The configuration of the DAQmx channel is performed prior to the 'Sub VI' being called, in a similar way in which VISA is configured, before it is actually used. The set up function is then followed by the function to read the data, and import it into the programme for analysis and manipulation before it is displayed and stored (See figure 14).
With the reference wired in, the sensor signals are collated into an array of values. A one dimensional array is produced for each of the stage of the monitoring session. These one dimensional arrays are gathered into a two dimensional array after all the whole test area has been measured. The two dimension array is then passed into a graphical indicator, visually displaying the values.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\DAQmx read.bmp
Figure 14 - DAQmx read. Using a channel reference to acquiring an array of data
The DAQmx channel setup and the DAQmx read is separated to avoid repeating the configuration step, and causing conflicts in the communication, as the DAQmx read is used multiple times over the course of a monitoring session.
All that is required is a reference to the channel, as this provides all of the relative data, to allow this function to run and acquire the further data (See figure 15 - over leaf).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\DAQmx read set up.bmp
Figure 15 - The channel configuration sub VI's
Once the data has been displayed onscreen, the values are all converted into a text format. This enables the data to be included in a system log file, which is created to archive all monitoring sessions.
Storage of data
A log file is created for every monitoring session performed. The file contains information about the session, such as the name of the session, the name of the operator, the size of the test area, the number of measurements taken, as well as the values recorded and any additional information that is considered important by the operator.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\log file.bmp
Figure 16 - An example of a log file.
The file is created from information provided by the operator via a series of HMI prompts and automatic population of measurement values. Within LabVIEW the data type for writing to a text file is the string data type. To save anything data produced by the system first requires conversion into the correct format and then manipulation using the 'string' functions to arrange the text into an understandable structure.
For creating the physical file in memory, the 'file' functions are used. They can create new files or re-open old ones, then read and perform searching or replacing function as well as writing data to producing a structured file containing just text.
The system creates a new file each session, it then writes two pre-formatted strings of information and measurement data into the file, before closing the file (See figure 17).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\write to file.bmp
Figure 17 - A series of functions to: 'create a file', 'write to file' and 'close a file'
The system writes to the file twice during the monitoring session. The first string written includes the configuration information such as test area to measure, the number of measurements to record, along with the test and operator names. The second string written contains the additional information about the monitoring session and the measured data in an array format, before closing the file and saving it on the computer's hard drive.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\header file.bmpC:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\add array.bmp
Figure 18 Figure 19
Figure 18 - Building the first text string to write to the file
Figure 19 - Building the second test string to write to the file
Preparing each string into a readable format ready for writing to the file are sections of code that carry out string manipulation (See figure 18 and 19). Any text typed into the HMIs of the programme is automatically in the correct data type for writing to the file. Any numbers have to be converted in to a 'decimal string' (a string of number values); this includes the 2 dimensional arrays of sensor values. The array of measurement values required string manipulation to realign the numbers in a tabulated layout, this is uses the method of nested 'for loops' pictured in figure 19. The whole array is firstly converted into string format using the 'number to decimal sting' function; this produces a string of number values separated by a single space. With all the values differing in length, the layout of the array becomes distorted. The nested 'for loops' are used to perform a 'search and replace' function, looking for the spaces and replacing them with tabs in order to realign the values into the tabulated layout of an array.
With all the nessesary information correctly converted into the 'string' data type, further string manipulation is required to create the log file in the presentable layout pictured in figure 16. Using the 'concatinate strings' function all the smaller strings of information and characters are combined, title captions are added to explain the information; allong with the spaces, tabs and return characters which create the structure in which the infromation is displayed. The completed strings are wired into the 'write to file' functions (See figure 17) where the data is save at a location prompted for by the HMI at the beginning of the monitoring session. The files open in any notepad application as they are in the universal .TXT format.
Human Machine Interface (HMI)
The human machine interface is the virtual display on the computer monitor. This display allows for the control and observation of a systems performance and purpose. In the LabVIEW programming environment the visual displays comprises of the front panel of the programme code (VI). Every VI (Virtual Instrument) created has two views, the front panel acting as a portal for inputting information and providing a visual output from the programme and the block diagram containing the data flow programme. The block diagram is where the data is passed from one function to another to produce the desired outcomes (See figure 20).
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\FP+BD io.bmp
Figure 20 - Illustrating front panel (right) as the portal to the block diagram (left) programme
Using the graphical indicators and controls, HMI front panels can be designed to provide as much or as little information and control of the programme. These front panels can play host to multiple screens with their visibility controlled by the background programme; this enables multiple end user bespoke access to the functionality of the programmes or systems.
On the LabVIEW HMI for the control and monitoring system, there are two string outputs, a graphical indicator, one string input and three controlling buttons. The string outputs display the title given to the test and the location in which the file can be found, the sting input allows for text to be added into the archived log file. The graphical indicator displays a three dimensional surface plot of the values obtained over the monitoring session.
C:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\HMI.bmpC:\Documents and Settings\Jordan Power\My Documents\LabVIEW code\final year Project\Project Photos\HMI 2.bmp
Figure 21 - HMI before and after a monitoring session
The interactive control button allows operators to change some of the configurations if they are incorrect, start the monitoring session or even abort the test all together. With the programme opened and running, the operator is presented with a series of secondary HMI prompts that ask for specific information for the configuration of; the log file location, the test information and the test area dimensions (See appendix figure 21b). This is followed by the HMI that confirms the distance the motor is required to move to, from, and the size of each movement interval.
The use of multiple displays allows the main HMI to remain simple with no unnecessary controls showing, yet still having the same amount of configuration control. Having prompting HMI force predetermined controls to be checked, minimising the risk of error.
Further simplicity comes in the format of showing the data of the surface homogeneity data as a three dimension surface plot, so that what is happening during each energy transfer can be easily understood by all that observe the monitoring session.
The functioning system
With the system activated and the sensor bar moved into position, across the test area and opposite the light source. The operator is confronted with a dialogue box prompting for a name and location to save the log file produced at the end of the session. Once a location is selected another dialogue box appears prompting for the test name and operators name, resolution of the test (number of measurements) and the test area dimensions. With all the information entered, the main control display of the system waits for the operator to either select the motor configuration button, which displays the start position, distance to move and the finish position for the monitoring session. If these do not require editing, the next step is for the operator to start taking measurements or abort the session.
By pressing the 'start test cycle' button, the operator begins the measurement and movement process. The data acquisition card produces a triggering signal used to trigger the light source to flash, whilst it reads the signals produced by the photo sensors. Once the flash has passed, the sensor bar is then moved to the next location on the test area and the system triggers the flash again. Once all the measurements have been recorded, the system produces a visual representation of the energy distribution.
The final dialogue box to appear is the controls for the motorised sensor bar to return to the bottom of the Rack.
With no further operator input, a log file is created and saved providing a future reference to the performance of the solar simulator. This file contains information about the test; the data, the operators name, the test name, the area monitored, additional information regarding this session and the values measured during the session.
With the file saved, the system automatically terminates and is ready to be powered down and stored away, not obstructing the test area and allowing the PV measurement to continue with the understanding of the energy being transfer.
The system was found to work as intended, producing a series of measurement that confirm the distribution of energy tapers off, from a centralised high. The graph shows the central area experiencing slightly more variation in the energy compared with the corners, where it appears to be a smoother, more gradual decay in energy.
When analysing two of the log files, it is apparent that as the source of energy moves away from the test area, the variation in the energy levels decreases. These results now give evidence that the theoretical suspicions are to be true, and that the homogeneity over a PV panel's area improves as the contact area, relative to the energy fields surface area, decreases. Looking at the graphs and the figures there are slight suspicions identifying, that reflection from within the light source housing maybe responsible for more energy distribution than first anticipated. Only further intrusive testing and physical changes to the light source housing are to provide the evidence to verify this suspicion.
With this system in place and the level of energy visible, CREST now have the ability to tailor tests to use just a small centralised high energy portion of the test area, or calibrate results when using the whole test area, thus ensure a higher accuracy in the PV panel reading.
Through the development of this system, and in conjunction with a related course module my knowledge of the PV industry has increased, also my understanding of the need for the current research and development into PV technology. Understanding the full purpose of this system I feel there is scope for improving the overall functionality. Including a sub system of identifying the different frequencies in the light spectrum in the search for greater energy yields, which is a becoming a growing area in the industry.
During the development of the system, a repetitive issue began to present itself. The issue was within the DAQmx task and the . Completing this project has furthered my knowledge of LabVIEW, the application of systems into the real world and also shown me that there are always unexpected problems no matter how
Given the opportunity to redevelop the system, I would specify using different hardware components; choosing a stepper motor which can be controlled more locally on the host computer compared to the serial commands required of this stepper driver. Using controlling commands to set up and operate a remote device is a viably method for distributing a system, but the requirement for handshaking of data was an unnecessary function that had to be incorporated in the programme. I feel that a more direct, pulse driven control would have suited this application. Other changes that could be made within the layout of the main programme, ensuring the same function but with more efficiently and also a revise programming layout would offer the opportunity to expand the overall functionality of the system. Thank you for reading about my project.
 Ralph Gottschalg, Simon Watson, 'ELC003: Renewable Energy Source - Course Notes'. (Solar Power)
 European Commission: 'Photovoltaic solar energy - development and current research'
 Peter Gevorkian: 'Solar power in building design - the engineer's complete design resource'
Problems faced and resolutions
It was found to work but problem i had to over come
How i would do it differently how