Further work on the documentation. Added new page for download instructions. Ran the markdown through a linter.

Author: sagatowski

CONTRIBUTING.md

@@ -1,4 +1,5 @@
 # Contributing to TcUnit
+
 We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
 
 - Reporting a bug
@@ -8,9 +9,11 @@ We love your input! We want to make contributing to this project as easy and tra
 - Becoming a maintainer
 
 ## We Develop with Github
+
 We use github to host code, to track issues and feature requests, as well as accept pull requests.
 
 ## We Use [Github Flow](https://docs.github.com/en/get-started/quickstart/github-flow), So All Code Changes Happen Through Pull Requests
+
 Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://docs.github.com/en/get-started/quickstart/github-flow)). We actively welcome your pull requests:
 
 1. Fork the repo and create your branch from `master`.
@@ -20,9 +23,11 @@ Pull requests are the best way to propose changes to the codebase (we use [Githu
 5. Issue that pull request!
 
 ## Any contributions you make will be under the MIT Software License
+
 In short, when you submit code changes, your submissions are understood to be under the same [MIT License](http://choosealicense.com/licenses/mit/) that covers the project. Feel free to contact the maintainers if that's a concern.
 
 ## Report bugs using Github's [issues](https://github.com/tcunit/TcUnit/issues)
+
 We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/tcunit/TcUnit/issues/new); it's that easy!
 
 ## Write bug reports with detail, background, and sample code
@@ -38,13 +43,16 @@ We use GitHub issues to track public bugs. Report a bug by [opening a new issue]
 - Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
 
 ## Use a Consistent Coding Style
-* Make sure to edit the project with the same version of Visual Studio as the master branch. All software (TcUnit and TcUnit-Verifier) has been developed using Visual Studio 2019. Note that the TwinCAT XAE Shell (provided with TwinCAT XAE installer) can't open the TcUnit-Verifier_DotNet (as it's a .NET/C# project). Instead it's recommended to use [VS2019 community edition](https://visualstudio.microsoft.com/vs/older-downloads/) which can be used both for TwinCAT and .NET/C# projects
-* Make sure to use TwinCAT XAE version 3.1.4024.44 or later
-* The prefixes of naming of function blocks/variables/etc from the [Beckhoff TwinCAT3 identifier/name conventions](https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/18014401873267083.html&id=) are ignored as a modern integrated development environment (as Visual Studio) gives all the hints/information of data types etc
-* Make sure to set your TwinCAT development environment to use Separate LineIDs. This is available in the TwinCAT XAE under **Tools→Options→TwinCAT→PLC Environment→Write options→Separate LineIDs** (set this to TRUE, more information is available [here](https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_userinterface/18014403202147467.html&id=))
+
+- Make sure to edit the project with the same version of Visual Studio as the master branch. All software (TcUnit and TcUnit-Verifier) has been developed using Visual Studio 2019. Note that the TwinCAT XAE Shell (provided with TwinCAT XAE installer) can't open the TcUnit-Verifier_DotNet (as it's a .NET/C# project). Instead it's recommended to use [VS2019 community edition](https://visualstudio.microsoft.com/vs/older-downloads/) which can be used both for TwinCAT and .NET/C# projects
+- Make sure to use TwinCAT XAE version 3.1.4024.44 or later
+- The prefixes of naming of function blocks/variables/etc from the [Beckhoff TwinCAT3 identifier/name conventions](https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/18014401873267083.html&id=) are ignored as a modern integrated development environment (as Visual Studio) gives all the hints/information of data types etc
+- Make sure to set your TwinCAT development environment to use Separate LineIDs. This is available in the TwinCAT XAE under **Tools→Options→TwinCAT→PLC Environment→Write options→Separate LineIDs** (set this to TRUE, more information is available [here](https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_userinterface/18014403202147467.html&id=))
 
 ## License
+
 By contributing, you agree that your contributions will be licensed under the MIT License.
 
 ## References
+
 This document was adapted from briandk's excellent [contribution guidelines template](https://gist.github.com/briandk/3d2e8b3ec8daf5a27a62).

README.md

@@ -2,7 +2,6 @@
 [![GitHub license](https://img.shields.io/github/license/Naereen/StrapDown.js.svg)](https://github.com/tcunit/TcUnit/blob/master/LICENSE)
 [![Open Source? Yes!](https://badgen.net/badge/Open%20Source%20%3F/Yes%21/blue?icon=github)](https://github.com/TcUnit/TcUnit)
 
-
 # TcUnit - TwinCAT unit testing framework
 
 Welcome to the documentation TcUnit - an xUnit testing framework for [Beckhoff's TwinCAT3](https://www.beckhoff.com/twincat3/).
@@ -11,7 +10,7 @@ Welcome to the documentation TcUnit - an xUnit testing framework for [Beckhoff's
 **[www.tcunit.org](https://www.tcunit.org)**
 
 **What is test driven development and unit testing?**  
-Familiarize yourself with [the basic concepts and specifics for TcUnit](https://tcunit.org/unit-testing-concepts/). 
+Familiarize yourself with [the basic concepts and specifics for TcUnit](https://tcunit.org/unit-testing-concepts/).
 
 **Want to know how to get started?**  
 Read the [user guide](https://tcunit.org/introduction-user-guide/).
@@ -32,4 +31,4 @@ That's fantastic! But please read the [CONTRIBUTING](CONTRIBUTING.md) first.
 Check the [F.A.Q](https://tcunit.org/frequently-asked-questions/).
 Check the [open](https://github.com/tcunit/TcUnit/issues) and [closed](https://github.com/tcunit/TcUnit/issues?q=is%3Aissue+is%3Aclosed) issues.
 If your issue does not already exist, create a [new](https://github.com/tcunit/TcUnit/issues/new).
-For general ideas/discussions, use the [discussions](https://github.com/tcunit/TcUnit/discussions).
+For general ideas/discussions, use the [discussions](https://github.com/tcunit/TcUnit/discussions).

docs/_config.yml

@@ -37,6 +37,7 @@ header_pages:
   - unit-testing-concepts.md
   - programming-example.md
   - faq.md
+  - download.md
 
 # Exclude from processing.
 # The following items will not be processed, by default.

docs/download.md

@@ -0,0 +1,11 @@
+---
+layout: page
+title: Download
+---
+
+TcUnit can be downloaded as either a [pre-compiled library](https://github.com/tcunit/TcUnit/releases) or [as source code](https://github.com/tcunit/TcUnit).
+For a tutorial on how you install TcUnit from either a downloaded library or from source read the [introduction user guide](introduction-user-guide.md).
+The libraries are compatible with TwinCAT **3.1.4020.0** or newer.
+
+Release history
+All releases can be downloaded from the official [TcUnit release site](https://github.com/tcunit/TcUnit/releases).

docs/img/DiagnosticMessageDiagnosticCodeParser-1.png

@@ -6,11 +6,9 @@ layout: home
 list_title: ' '
 ---
 
-# TcUnit
-
 ![TcUnit logo](img/tcunit-logo.png)
 
-TcUnit is an [xUnit](https://en.wikipedia.org/wiki/XUnit) type of framework specifically done for [Beckhoff’s TwinCAT 3](https://www.beckhoff.com/en-en/products/automation/twincat/) development environment.
+TcUnit is an [xUnit](https://en.wikipedia.org/wiki/XUnit) type of framework specifically done for [Beckhoff's TwinCAT 3](https://www.beckhoff.com/en-en/products/automation/twincat/) development environment.
 It consists of a single library that is easily integrated into any existing TwinCAT 3 project.
 
 **Want to get started?**
@@ -36,5 +34,5 @@ The software is completely free and you can use the software in any way you want
 
 ## Automated test runs
 
-With the additional TcUnit-Runner software, it’s possible to do integrate all your TcUnit tests into a CI/CD software toolchain.
+With the additional TcUnit-Runner software, it's possible to do integrate all your TcUnit tests into a CI/CD software toolchain.
 With the aid of automation software such as [Jenkins](https://www.jenkins.io/) or [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/), you can have your tests being run automatically and collect test statistics every time something is changed in your software version control (such as Git or Subversion).

docs/img/TcUnitFiveSuccessful_2.png

@@ -3,7 +3,7 @@ layout: page
 title: Introduction user guide
 ---
 
-Before reading this guide, it’s highly recommended to read [unit testing concepts](unit-testing-concepts.md), in order to have a basic understanding of the concepts of unit testing and TcUnit.
+Before reading this guide, it's highly recommended to read [unit testing concepts](unit-testing-concepts.md), in order to have a basic understanding of the concepts of unit testing and TcUnit.
 
 The TcUnit framework gives you the possibility to easily write unit tests for your TwinCAT 3 software, and having the results reported in a human-readable format for review.
 All unit test code is written in the same program/library as the rest of your code, but because it is only used in a separate test-program, it does not affect the production code/executables.
@@ -22,7 +22,7 @@ The framework can either be downloaded as a [precompiled library](https://github
 
 ### Install from library file
 
-If you’ve downloaded the library, you should have a file called **TcUnit.library** in your computer.
+If you've downloaded the library, you should have a file called **TcUnit.library** in your computer.
 Start your TwinCAT XAE (Visual Studio).
 In the menu of Visual Studio select **PLC** and then **Library Repository...**
 This will display the following window:
@@ -62,26 +62,26 @@ For every function block (or free function) that you have defined we want to cre
 - Define the inputs
 - Define the expected outputs (result)
 - Call the TcUnit-assert methods to compare the expected output to the actual output for every test
-It’s entirely up to the user how to to organize the different tests, so what follows is a best practice/suggestion.
+It's entirely up to the user how to to organize the different tests, so what follows is a best practice/suggestion.
 On the same level as the `POUs` folder, create a folder called `Test`.
-It’s in this folder that we will create all our test FBs as well as the program that will run the TcUnit framework.
+It's in this folder that we will create all our test FBs as well as the program that will run the TcUnit framework.
 
 ![Test FBs](img/test-fbs.png)
 
 In this example we have a total of five FBs.
 For every FB we have created a test-FB, i.e. for `FB_DiagnosticMessageDiagnosticCodeParser` we have `FB_DiagnosticMessageDiagnosticCodeParser_Test`.
 Note that the framework in no way enforces to use any standard for the naming, this is entirely up to the user.
-For various reasons you might find it’s not even possible to add the test-FBs in the same solution (for instance, if this is your main executable), and in this case just put the tests in a separate solution and include the main solution in the test solution as a library.
-Generally it’s better to structure the code in various library projects each responsible for a certain set of requirements/functionality.
-It’s important to see the tests as an important part of your code.
+For various reasons you might find it's not even possible to add the test-FBs in the same solution (for instance, if this is your main executable), and in this case just put the tests in a separate solution and include the main solution in the test solution as a library.
+Generally it's better to structure the code in various library projects each responsible for a certain set of requirements/functionality.
+It's important to see the tests as an important part of your code.
 
 ![TcUnit architecture](img/tcunit-arch.png)
 
 The general structure here is that `PRG_TEST` is the program in where the test-FBs (test suites) are instantiated.
 Each test suite is responsible of testing one FB or function, and can have one or more tests to do so.
 
-Let’s assume we want to create the simplest possible FB that takes two unsigned integers and sums them.
-We can create the header for the FB, but the actual implementation can (and should) wait after we’ve done the unit tests.
+Let's assume we want to create the simplest possible FB that takes two unsigned integers and sums them.
+We can create the header for the FB, but the actual implementation can (and should) wait after we've done the unit tests.
 
 ```StructuredText
 FUNCTION_BLOCK FB_Sum
@@ -94,7 +94,7 @@ VAR_OUTPUT
 END_VAR
 ```
 
-Now let’s create the test suite for this.
+Now let's create the test suite for this.
 This FB needs to extend `TcUnit.FB_TestSuite`.
 
 ```StructuredText
@@ -105,12 +105,12 @@ END_VAR
 
 By always adding this code, your test suite gets access to TcUnit and TcUnit will have a handle to your test suites.
 
-Now it’s time to create our tests.
+Now it's time to create our tests.
 There are many ways to structure your tests, and there are several guidelines for this as well.
-What we’ll be doing is to create a method for every test, and name it in such a way that it’s clear what the test does.
+What we'll be doing is to create a method for every test, and name it in such a way that it's clear what the test does.
 Remember that the unit tests are part of the documentation of your code, and although you might find the code trivial at this moment, there might be other developers reading your code now (or many years in the future).
 For them well-named tests are invaluable.
-We’ll be creating two tests called `TwoPlusTwoEqualsFour` and `ZeroPlusZeroEqualsZero`.
+We'll be creating two tests called `TwoPlusTwoEqualsFour` and `ZeroPlusZeroEqualsZero`.
 The `TwoPlusTwoEqualsFour` will look like this:
 
 ```StructuredText
@@ -139,7 +139,7 @@ The Message parameter is optional and is used in case the assertion fails, the t
 We finish the method by calling `TEST_FINISHED()`.
 This gives the flexibility to have tests that span over more than one PLC-cycle.
 
-For `ZeroPlusZeroEqualsZero` it’s more or less the same code.
+For `ZeroPlusZeroEqualsZero` it's more or less the same code.
 
 ```StructuredText
 METHOD ZeroPlusZeroEqualsZero
@@ -194,8 +194,8 @@ Activating this solution and running it results in the following result in the v
 There is one test that has failed, and the reason for this is that we have not written the implementation code yet, only the header of the function block FB_Sum.
 But how come that we have one test succeeding?
 As we can see, the test `TwoPlusTwoEqualsFour` failed, which means that the one that succeeded was the other test `ZeroPlusZeroEqualsZero`.
-The reason this succeeds is that the default return value for an output-parameter is zero, and thus it means that even if we haven’t written the body of `FB_Sum` the test will succeed.
-Let’s finish by implementing the body of `FB_Sum`.
+The reason this succeeds is that the default return value for an output-parameter is zero, and thus it means that even if we haven't written the body of `FB_Sum` the test will succeed.
+Let's finish by implementing the body of `FB_Sum`.
 
 ```StructuredText
 FUNCTION_BLOCK FB_Sum