University

College of Southeast Norway

How To Write a Technical Lab Report

with Practical Examples
2016.02.29 Hans-Petter Halvorsen

http://home.hit.no/~hansha
 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 thats 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.

Writing a Technical Lab Report 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 dont 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
An excellent performance, clearly outstanding. The candidate demonstrates excellent
A Excellent judgment and a high degree of independent thinking.
A very good performance. The candidate demonstrates sound judgment and a very good

Writing a Technical Lab Report

 3/25
B Very good degree of independent thinking.
A good performance in most areas. The candidate demonstrates a reasonable degree of
C Good judgment and independent thinking in the most important areas.
A satisfactory performance, but with significant shortcomings. The candidate
D Satisfactory demonstrates a limited degree of judgment and independent thinking.
A performance that meets the minimum criteria, but no more. The candidate
E Sufficient demonstrates a very limited degree of judgment and independent thinking.
A performance that does not meet the minimum academic criteria. The candidate
F Fail 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. Its
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

Writing a Technical Lab Report

 4/25

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.)!
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 dont 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 print-
out, i.e., dont 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

Writing a Technical Lab Report

 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 peoples work as your own is
illegal/cheating and you dont 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:

Writing a Technical Lab Report

 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.

Writing a Technical Lab Report

 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.)!
Dont 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:

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 9/25

Better:

Even better?

Writing a Technical Lab Report

 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 dont 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:

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 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 whats 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.

Writing a Technical Lab Report

 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.

Writing a Technical Lab Report

 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 20-30
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

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 16/25

This doesnt 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

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 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 whats 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 whats important.

Show figures of whats important

Writing a Technical Lab Report

 20/25

Bad Example:

Is this figure important to have in the report? It gives me nothing! In addition
you cant see the text, etc.

Make sure to use a proper Screen Capture tool!! The figures/plots should be
clear and readable!! Focus on whats 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 dont 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):

Writing a Technical Lab Report

 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):

Writing a Technical Lab Report

 22/25

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!

A SubVI has been made. Thats 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!

Writing a Technical Lab Report

 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:

Writing a Technical Lab Report

 24/25

Writing a Technical Lab Report



Hans-Petter Halvorsen, M.Sc.

E-mail: hans.p.halvorsen@hit.no
Blog: http://home.hit.no/~hansha/

University College of Southeast Norway

www.usn.no