How To Write a Technical Lab Report with Practical Examples

Transcription

1 University College of Southeast Norway How To Write a Technical Lab Report with Practical Examples Hans-Petter Halvorsen

2 2/25 Tips and Tricks This document describes tips and tricks for creating a well-written technical Lab Work Report. Such a report should at least include: Title page (Title, Name, Student Number), Table of Contents, Introduction, Problem Description, Results, Discussions and a Conclusion (+ Appendices if necessary). When you are working with lab work, you have all resources available, books, tutorials, other students, example code, the teacher, etc. So be able to do all the tasks and get the correct answers is to be expected. Then you cannot expect to get a grade better than C. But C is actually a good grade, so many should be satisfied with that. The grade C is the average grade that most students get. To make the little extra to stand out is important. So how do you do that? You must make an extra effort when you are working with the report. In addition your application/source code (if that s part of the lab work) should have a good structure and do the little extra that makes it outstanding. The User Interface/HMI should of course be clear and intuitive. A bad written program is like a report with lots of spelling mistakes, i.e., it does not look good! Neither does it take longer time to structure your code properly, probably you will save time because it will lead to fewer errors, easier to maintain, find bugs, etc. is like writing a job application! It should be interesting and appeal to the reader. In addition the technical contents in the report should be of high quality of course. It is the same here, even if you have the technical qualities to get the job, it does not help if you don t get to the job interview because of a bad job application. Grades Here is a short description of the different grades used. Symbol Description General, qualitative description of valuation criteria A Excellent An excellent performance, clearly outstanding. The candidate demonstrates excellent judgment and a high degree of independent thinking. A very good performance. The candidate demonstrates sound judgment and a very good

3 3/25 B Very good degree of independent thinking. C Good A good performance in most areas. The candidate demonstrates a reasonable degree of judgment and independent thinking in the most important areas. D Satisfactory A satisfactory performance, but with significant shortcomings. The candidate demonstrates a limited degree of judgment and independent thinking. E Sufficient A performance that meets the minimum criteria, but no more. The candidate demonstrates a very limited degree of judgment and independent thinking. F Fail A performance that does not meet the minimum academic criteria. The candidate demonstrates an absence of both judgment and independent thinking. The whole scale is used (A-F). The grade C is given for an average student performance. This means C is a good grade! This will be the guideline for using the scale. The grade A should be an excellent performance that is clearly outstanding. The grade A is used to separate the performances that stands out, and it will we used relatively seldom. Checklist Here is a short checklist you can use when writing a Technical Lab Report: The report is clearly and logically structured and organized Introduction describes the aims of the work together with limitations and assumptions. Results - The Results are discussed Conclusion - The Conclusions are well grounded Literature References are citied in the report + correct syntax (2 different standards; Harvard or Vancouver, select one and stick to it!) + Reference List Few spelling mistakes All Figures and Tables are numbered and have descriptive captions. It s also looks nicer if you center the Figures You need to refer to sources when taking figures/pictures from other sources (Referencing) Use Units when dealing with numbers and calculations. Units should also be shown in plots, etc. Figure numbering: Below Figure, Table numbering: Above Table! Equation Numbering. All equations need an equation number. Equation numbers shall be right aligned. All Figures and Tables are referenced in the text

4 All curves (lines) of plots (diagrams) are labeled and axis and scaling are shown Screenshots should be good. To take a screenshot of a specific region is often better that a large image with lots of unnecessary information. Using a good tool for screen capture is important (e.g. SnagIt, etc.)! 4/25 Source Code: Just showing small parts of the code (which you explain in the text) are often better than a long code list. Cut-out what is important you don t always need to show the whole program with a small code part inside Figures/Plots should be clear and easy Software/Source Code is well documented, well-structured and look nice. Use straight lines, etc. Hardware and Equipment that are used in the Lab Work is well documented Print-out The report should also be readable in black and white printout, i.e., don t refer to yellow, purple, etc. in the report. Make sure you read through the report after you print it! Generated text like Reference is missing does not look good! The report is delivered within the deadline

5 5/25 Literature References Why should you name your sources? Give credit to the original author Allow others to read what you have read Follow up the reader can get more information Quality control have you used the information correctly? Place your work in a wider context Plagiarism - Publishing other people s work as your own is illegal/cheating and you don t learn anything! Quotations Quotations are done as follows: Short quotes (up to 3 lines): use quotation marks Longer quotes (more than 3 lines): new paragraph, indented How to Cite Sources Here are some Examples: Refer to them in the text Create a Reference list (literature list) at the end of your document Examples: According to Murray (2002) Other studies have found similar results (Smith and Jones,2000, Lie et al., 2003) 2 different standards; Harvard or Vancouver, select one and stick to it! Harvard Author and year of publication in the text Example:

6 6/25 According to Murray (2002) Alphabetical reference list Alphabetical by author (or by title if no author) Example: Murray, R. (2002) How to Write a Thesis. Maidenhead: Open University Press. Vancouver References numbered in the text Example: Not every thesis has a literature review [1] Numerical reference list in the same order as in the text Example: [1] Murray R. How to write a thesis. Maidenhead: Open University Press, 2002; p. 101.

7 7/25 Screen Shots Screen shots should be good. To take a screenshot of a specific region is often better that a large image with lots of unnecessary information. Using a good tool for screen capture is also very important (e.g. SnagIt, etc.)! Don t use the built in Print Screen functionality in windows. There are lots of freeware/shareware/open source tools available for this purpose. Examples: In this example you shall explain where you find a certain tool: Probably this is a better way:

8 8/25 Or this way? If you use a Screen Shoot tool they have functionality for creating circles, etc. on your screen shots. Bade Example:

9 9/25 Better: Even better?

10 10/25 Sometimes it is best to cut-off just your code - or part of your code. Source Code Just showing small parts of the code (which you explain in the text) are often better than a long code listing. Cut out what is important you don t always need to show the whole program with a small code part inside. You can put source code in your report, but not too much. Software/Source Code should be well documented, well structured and look nice. Use straight lines, indents, etc. Examples: This example is probably not so good if the purpose is to show your code:

11 11/25 This Example is probably better if you want to show your code: This example keeps the focus on the code and not all the other information. In this case it is easy to explain and refer the code in the text using the line numbers. The text also has color codes which make it easier to read. Another (good) example:

12 12/25 % This is my code K = 1, T = 3; H = sys_order(k,t) Figure(1) bode(h) The code is written inside a box with a different background color and Font. Courier New is a good font to use in code listing. Remember what s may look good on a computer screen, may not look good on a piece of paper. Clean-up your Code Make sure you clean-up and structure your code. Make straight lines, indents, etc. Bad Example: Better: It does not take much time to clean-up and structure your code and it looks much better, it is easier to read and understand. In LabVIEW the code should flow from left to right.

13 13/25 Spelling Make sure your report has few spelling mistakes. Use the built-in capabilities in your Word Processor. Make sure you spell right when writing company names, Software names, etc. Example: The LabVIEW software is spelled LabVIEW not labview, Lab view, LABview, LabView, etc. Submission If you hand-in the report electronically, you should always create a PDF file! If you hand-in a PDF file you can be sure everybody can open and read it. The formatting, layout, etc. in the document will also be exactly the same. There are lots of free tools that can create PDF files and MS Word have built-in functionality for creating PDF files. Pitfalls Some tasks are more important than others in the assignment. The tasks in the beginning are usually introduction task to make you getting started. Normally you will indirectly use the results from these tasks in later tasks. The most important tasks are usually in the end. Use the advantage that you work in a group in a good way, one coding and two watching on each side is not a good learning process. Everybody should do some coding to get it into your fingertips! You all need more practice in programming. Everybody needs to install the necessary software on their own personal computers! Below I will use different examples from previous student reports as examples in order to explain what you should do or not.

14 14/25 Report Here is a list with pitfalls an average student does when writing a standard technical lab report. The report should be appealing to the reader! Good structure and layout. Correct use of fonts, No spelling mistakes, etc. Make your report special and interesting to read remember the teacher shall perhaps read through reports! (It is the same when you are going to apply for jobs!) Make sure to add your student number on the Front page/title page (together with your name of course) Make sure you read through the report after you print it! Generated text like Reference is missing or Error! Bookmark not defined does not look good! Spelling! How do we type LabVIEW? LabView, LABVIEW, Lab VIEW,..? At least type it in the same way in the entire report! You cannot just show a figure or an equation without some text explaining it! It is not normal to use a dot at the end of a sentence in headers

15 15/25 And why has the header 1.1 more indenting than 1.1.1? Equations. Equations should be centered. If you decide to use equation numbering, use it properly! Make also sure that the Font look nice. The formulas should be centered. If you decide to use equation numbering, it should be in the right margin (and no dots ). Formulas. Make sure they look nice! Formulas usually have a special font. Use the Equation Editor in Word, etc. Formulas/Equations should be centered Bad Example (Matrices should be in square brackets, not normal to use *, etc. in equations ): Bad Example 2 (what kind of font have been used here???): And use the same Font, font size, etc. for all of the formulas in the report! Another bad example:

16 16/25 This doesn t look nice! Different kinds of Fonts have been used. The equation should also have been on a new line (centered). And in addition, make sure the spelling is correct ( water tank not water tang ). Another example Bad example: What kinds of tools have been used to create this? If you use MS Word, it has built in tools for creating such equations. Keep good structure and a clean layout in the report. This is a bad example: Make sure headers and footers are correct according to which chapter you are in

17 17/25 A Conclusion is always needed in a Technical Report. Here you shall summarize your results and draw conclusions not how much you have learned, etc. Bad examples: I have learned much doing this assignment This was very useful, and I will need this when I get a job Another bad example: From this Lab, we understand the Kalman Filter much more and how to implement it in LabVIEW which also make us much better to use LabVIEW. We also learned how to design a feedforward controller to combine with a traditional PID controller and by comparison, we have better understanding that the usage of Kalman Filter and feedforward controller. Focus on your results, not just list up what you have done or how much you have learned by doing this, etc. - because this is not relevant!! Table Text: Figure text should be below the figure, but table text shall be above the table!! This should be known! It does not look good when doing these basic mistakes! Make also sure that the whole report is shown in the PDF version:

18 18/25 The column to the right is not shown correctly. Figures. Make sure the figures are clear. This is hard to read: Make the figure larger! Or focus only on a special part of it. To take a screenshot of a specific region is often better that a large image with lots of unnecessary information. Make also sure to use a proper tool for the job! A lots of good screen capture tools exists! List of Figures has no interest should be omitted (especially for a short report). Font size - use the same font size (for the body text) in the entirely report Referencing should be done properly. A picture says more than a thousand word they say still you can just show a picture without no text, explanations, discussion, etc.!! Create good Figures. Bad Example: This figure is supposed to show the results from some simulations:

19 19/25 It is almost impossible to get information about the simulation results in this figure. It is indistinct, and you can hardly see the text in the plots, etc. It is also in black &white. The figure also tries to give too much information in one figure. Focus on what s important, and show only that. Colors vs. Black & White in Figures, Plots, etc. Plots can look great on the screen in beautiful colors, but if you print it out in black & white, it might not look so good! It is hard to see the difference between two lines in a black & white figure if you use the same line width and same type of line (the only difference is the color). Another Bad example: This picture is only black & white (on the printed copy) it is hard to see what it is. The plot is also indistinct, you cannot read the text! The scaling should also be changed, to make it more easier to see what s important. Show figures of what s important

20 20/25 Bad Example: Is this figure important to have in the report? It gives me nothing! In addition you can t see the text, etc. Make sure to use a proper Screen Capture tool!! The figures/plots should be clear and readable!! Focus on what s important in the figure! Source Code Here is a list with pitfalls an average student does when creating the applications and hand-in the source code. You don t learn programming by watching others do it! You need to do it yourself in order to get it into the fingertips! Lots of practice is the best way to learn! Good structure of the files is important! It should be easy for me to find the proper file Good structure in the code is important. Bad example ( Spaghetti code):

21 21/25 It does not take long time to keep the code clean and neat! This makes it much easier to understand and it looks much better too! Note! In LabVIEW the flow should always be from left to right. Here is another bad example ( Spaghetti code):

22 Is it easy to understand this piece of code?? (Wires in all directions, SubVI without label or icons, not using SubVIs, variables and constants without names, etc.) Debugging this piece of code is also almost impossible! 22/25 A SubVI has been made. That s great! but what does this subvi really do?? It has no name nor any icon, etc. It is allowed to use/create Sub VIs (functions)!! This makes your code more structured, easier to maintain and reuse. It is also easier to debug the code. Always name your variables Bad Example: Use also good descriptive name for your variables, and always use English!

23 23/25 Make sure that the teacher can open the source code! Example: Here I try to open a VI that use a SubVI called Low Pass Filter but the file does not exists!! Keep good structure in the code files. Good and reasonable names of the Files are also important! Here are some Bad examples:

24 24/25

25 Hans-Petter Halvorsen, M.Sc. Blog: University College of Southeast Norway