Final application

The overall operation of the application is defined in this section. First, the user generates a request by clicking any button of the control panel. Then, a web server receives this request. Once the request is received, the web server interacts when the devices depending on one the action requested by the user. Next, the web server receives the response of the sensors, and it generates and sends a response to the GUI, where the data is updated.

The process of data acquisition starts whenever the user clicks the Start Measurements button; the GUI captures the click and generates a periodic request to the server. This request must be asynchronous, so the GUI is not constantly refreshing. In order to do that, the JavaScript’s Fetch API is used. This request is handled by the webserver, which asks for a measure to the force and length sensors. Both return their latest measure to the web server, which sends them back to the GUI into the response’s body. If the user has activated the Record Data switch, the server would receive it as a parameter in the URL’s request. In this case, the process would be the same, but the data would be also stored into a csv file. Finally, the data is received in the user interface and the plots are updated.

The remaining functionalities such as the devices tare or the opening/closing the connection follow the same process that has just been described. An asynchronous request is generated in the client, received in the web server which calls the corresponding methods of the Python Wrappers. Each sensor is represented in Python as an instance of the wrapper’s classes. So that, any functionality related to the sensors that is needed to be executed can be performed from these objects. Then the server returns a response with the result, or an error message is something went wrong.

Figure 8 shows the GUI where the graph in the upper left corner contains the data of the force (in newtons) being applied in the vertical axis. At its right, the graph displays the length (in millimetres) in each of the three axles. Finally, figure 7 displays all the measures together. Between the graphs, the measures are displayed numerically, but they also can be seen by passing the cursor over the desired plot.

Figure 7. Force and positions plot GUI

Figure 8. Force (left plot) and positions (right plot) measures GUI

5.2. Finite state machine unit testing 5.2.1. The finite state machine

The FSM is a common software design pattern. It is mainly defined by states and transitions.

Every state has its behaviour, a set of instructions that would be executed only if the machine is in this particular state. The transitions define the conditions that must occur to change from one state to another.

In this case, the FSM is used to control the mirror’s cell state. It is a very suitable solution because the code loaded into the PLC is executed in an infinite loop at 1 kHz. That means, that the same program is repeated over and over, and its execution in each iteration would depend on the current state of the machine. The design of the cell’s FSM is shown in figure 10.

Figure 9. Mirror's cell FSM

The nominal execution of the FSM (Figure 19) is booting the PLC, then load the code to be executed and the initial configuration. Once the configuration is correctly loaded, start the Built In Test, several tests to ensure the proper functioning of the mirror’s cell (they would be further explained later in this document). If every test pass, start the operational mode, that means that the cell is ready to be moved. The operational mode has two sub-modes:

Warping Harness (to reshape the mirror) and Positioning State (to allocate the mirror within the telescope). Then, whenever the movement is finished it would end in Operational Stop.

Therefore, the objective of the Unit Tests is to check that every possible transition between states is performed correctly. That means, only changing the state when the pertinent transition flags are activated. Moreover, the cases in which an unexpected transition flag is active in a particular state have also to be tested.

5.2.2. Unit testing in TwinCAT 3

For the purpose of developing robust and clean code, unit tests are written. The main idea behind unit testing is ensure the proper functioning of each piece of code. This way, the code developed is more modular and bugs are less likely to appear. In addition, writing unit tests allows to test the code under every single possible situation and not only in the best or expected case scenario.

TwinCAT stands for The Windows Control and Automation Technology, and it is developed by the company Beckhoff. It provides a development environment for PLCs software. For the purpose of Unit Testing inside the TwinCAT environment, a library named TcUnit was developed. This library provides all the essential tools and components to run unit tests over the code developed in TwinCAT.

In order to develop unit tests in a structured and clean way, the several components provided by TcUnit must be used. First, all related tests are grouped under one Test Suite, which is a class containing various tests. Every individual test is a Test Case, which must clearly define the purpose of the test. Inside each test, multiple Assertions can be carried out. One assertion is a comparison between an expected value and the real one, they are the smallest piece of code that check the proper operation of a method. Moreover, there are Test Fixtures, groups of variables that allow to define initial conditions for a Test Case or even a whole Test Suite. Finally, the TcUnit library also provides a Test Result Formatter that displays the result of all the tests performed and the Test Runner, which ensures the proper execution of all the tests and collect the results of all of them.

5.2.3. FSM unit tests

The unit tests developed for the FSM using the TcUnit components has the following structure: First, the test suite is the FSM itself, which would have all the possible tests as the class methods. The test fixture for this test suite is the initial state of the machine, that means, all the transition flags displayed in “Figure 9.- Mirror’s cell FSM” set to false (or inactive). Then, the test cases are all the possible transitions from one state to another.

These could be from one initial state to the immediate next state, or a more complex transition, for example, from “Boot” to “Operational Stop”. So that, every test case can contain multiple assertions, where the expected state and the state returned by the FSM given the state (active/inactive) of all the flags.

5.3. Main Software Development

The main software is focused on the Built in Test and the Warping Harness Moving states.

For the Built in Test stage, several tests have to be designed and implemented. These tests are not for the software but for the cell structure. Their main objective is to ensure that the mechanical components are working as expected. The built-in tests would run before any of the operational states. Then, in the Warping Harness Moving state, various checks are carried out for every actuator individually with the objective of controlling the movement.

Figure 10 shows a UML diagram of the software architecture for the Warping Harness state.

The Warping Harness Main Task is a PLC task that would run all the related methods related to this stage. The FB_Warping_Harness is a class that contains the instances of every bipod and tripod actuator.

The FB_BIPOD_ACT class is the one representing the bipod actuators. It contains an instance of the classes FORCE_SENSOR and BIPOD_DRIVE. The force sensor object represents the load cell attached to the actuator, which measures the force being applied by the actuator. The BIPOD_DRIVE class represents the motor that moves the actuator.

The TRIPOD classes inherit from the BIPOD ones, and they follow the same structure. All these classes are used to implement the software described next.

5.3.1. Built-in tests software

5.3.1.1. Finding load cells dead zones

The first one is finding the load cell’s dead zone. The actuators are connected to a load cell, so the force applied is known, the measures obtained by the load cells are directly mapped into a PLC variable. However, the load cells have a dead zone, which means that the measures do not oscillate and remain the same. To avoid reading false values, whenever the load cell is inside the dead zone it must be tared.

The program developed for this test must find the dead zone of each load cell and tare it automatically. In the PLC program, every actuator is represented as an object, and they are all instances of the same class. These objects have the current measure of the corresponding load cell as an attribute, so the force being applied by each one of them can be known any time inside the program.

The first step is to know the actuator’s force. If it is below 0N, it would be ordered to apply 150N, but if it is over 0N, it would be ordered to apply -150N. Those values are the maximum and minimum force that any actuator must apply, so the movement range is compressed between -150N and 150N. Whenever the actuator has reached one of the limits, it would be sent to the opposite one. By doing this it is ensured that all the way would be travelled.

While the actuator is moving from one limit to the opposite one, the search of the dead zone is carried out. To do that, the variance of the force measures is calculated within a rolling window of thirty samples length (or 30ms, because the measures are taken at 1 kHz). Whenever the calculated variance is under a defined threshold, the dead zone has been found. The threshold was estimated recording and plotting multiple movements using the TwinCAT3 Scope View tool, software that enables to record and plot any variable being used in the PLC execution loop.

Finally, after the dead zone has been found, the tare must be done. To do that, a command is written in the load cell CoE with the central value of the window where the zone was found. When the command is executed, the dead zone is set to zero. Moreover, another command is written in the CoE to make the tare permanent, so that if the PLC is rebooted the calculated value would still be available because it its written in the PLC’s EPROM.

5.3.1.2. Movement signal injection

One of the requirements is being able to move all the actuators following a predefined signal. This signal is stored in a .csv file, where in each row the force to be applied for every actuator is written and also the time to wait between movements. There can be up to sixty-thousand rows and the whole movement must being able to be repeated in a loop.

A built-in test is developed for this purpose. First it would try to open the corresponding file, notice that working with external files with PLCs is not trivial, because the execution loop is executed at a fixed frequency, and all operations related to an external file must be handled as a state machine.

First, all the fields from one row are read, this action can take various iterations of the execution loop. Then, when all the positions are known, the movement of each actuator is starter and a timer is triggered. This timer would prevent that any new movement is started before the indicated time has elapsed. Once the timer has finished, the process starts again, until the end of the file is reached. If all the movements are executed successfully, the test

is passed. If not, an error is reported (the possible errors would be discussed later in this chapter).

This procedure would be highly useful to implement other built-in tests, because the functionality of reading a csv and moving the actuators as indicated in the file is all encapsulated in one base class so others can inherit from it. Moreover, the file to be followed can be selected for the user or be set by default.

To ascertain the proper behaviour of this class, also the TwinCAT Scope View is used, as it has the plot measures over time functionality, it is perfect to check that the movements are the ones defined in the file and also that the time elapsed between them is the required one.

5.3.1.3. Actuators homing and actuators full stroke

The actuators homing built-in test consists of sending all the actuators to its origin (0 Newton). To carry out this task, the previous class from the Movement Signal Injection was used as the parent class, and a trajectory file with just one row with all the positions set to zero.

This method allows to reuse code and save time developing extra methods. Moreover, the proper functioning had already been tested. As the position measured of the actuators is absolute, using this method all of them are send to the origin independently of their positions.

The actuators full stroke built-in test is very similar to the homing test. It must send all the actuators to their lower force limit and then to the upper one. So that, it can be tested that no problems occur throughout the all the movement range. To perform this test, it is used the same procedure than for the homing, but with a different .csv file that consists of two rows, the first one with the lower limit for all the actuators and the second row with the upper limit.

5.3.1.4. Elongation versus force (coherence) test

The actuator’s dock must accomplish a defined proportion between force and elongation.

The force is measured via the load cell attached to the actuator, and the elongation is measured in motor counts. The value of the motor counts is directly mapped to a PLC global variable. The conversion factor from motor counts to elongation in millimeters is given by the manufacturer.

To perform this test, the actuator is ordered to perform a full stroke movement. When the movement begins the initial values of force and motor counts are stored, the actuator starts its movement, and a timer is started. After the timer ends, new values are read, and the proportion is calculated as:

𝑐𝑜ℎ𝑒𝑟𝑒𝑛𝑐𝑒 = |𝐹𝑖𝑛𝑎𝑙_𝐹𝑜𝑟𝑐𝑒 − 𝐼𝑛𝑖𝑡𝑖𝑎𝑙_𝐹𝑜𝑟𝑐𝑒|

|𝐹𝑖𝑛𝑎𝑙_𝐸𝑙𝑜𝑛𝑔𝑎𝑡𝑖𝑜𝑛 − 𝐼𝑛𝑖𝑡𝑖𝑎𝑙_𝐸𝑙𝑜𝑛𝑔𝑎𝑡𝑖𝑜𝑛|

Where the coherence (N/mm) is the relation between the force increment and the increment of elongation. The final force is the force measured by the load cell at the time that the timer has finished, and the initial force is the one measured just before the timer has started, in newtons. The elongation is the length measured in millimeters.

When the result is obtained, it is compared with the theoretical one. Of course, there is a small margin of error which is considered acceptable. Indeed, this test runs as a built-in

is in the Warping Harness Moving state. If the proportion measured is not inside the of the valid range, an error is notified, and the user can either stop the movement or continue with it. This test is performed for all the actuators at the same time.

5.3.1.5. Single actuator test

There could be some situations where it is needed to test one actuator individually. For this reason, another built-in test was developed, where the elongation vs force check is also performed, but in one single actuator selected by the user. For this test, the base class used in the previous ones could not be employed because except for the actuator selected the remaining ones must stay still.

Therefore, when the test is started, the actuator selected by the user is moved along the entire range. During the movement, nothing more needed to be implemented because the relation between force and elongation check is periodically carried out whenever an actuator is moving.

5.3.1.6. Built-in tests final result

Finally, all the tests described along this chapter can be carried out automatically after the PLC boots and has its configuration loaded, or also be selected by the user. All the tests are Classes that have an Execute Test method, that would perform the corresponding test and evaluate its result. If the test is successful, it would be displayed as “passed” in the HMI, however if an error occurs during its execution, the error’s description would be added to an error stack trace, and it would be also notified. Notice that the built-in tests are designed to be triggered through a GUI; however this interface is out of the scope of this project.

5.3.2. Actuators movement checks

The proper functioning of each actuator has to be continuously monitored. There are several issues that can happen while the mirror is being reshaped. In order to immediately identify and report them, various checks are developed. These checks are periodically testing every actuator individually.

5.3.2.1. Software limits errors

As mentioned before, the actuator operational range is between 150N and -150N. However, this can be restricted even more via software. If a narrower range is set, the software must ensure that it is not exceeded by any means. If an operator introduces a value over the software limit set, the movement must finish before it is reached.

To implement this test, the force being applied is checked in every PLC loop, whenever it surpasses the limit set, the check method would return an error and the movement would stop. Moreover, the method must ensure that the limits set are equal or more restrictive than the hardware limits.

5.3.2.2. Following error

Errors mounting the structure can happen, for example, allocating an actuator upside-down.

This would provoke that the movement follows the opposite direction than expected. To detect this type of error, the following error check is developed. First, when the movement is started the position is stored and the distance to the destination point. Coming up next, a 500ms timer is started. When the timer finishes, the distance to the set point is calculated

again. If the final distance is lower than the initial one, the movement direction is correct however, if it is higher the movement is going in the opposite way.

It is needed to wait a small time between measures because the load cell measures have some noise, so it the measures were calculated in two consecutive PLC loop, false errors could be found. Moreover, at the beginning of the movement, the actuator can be slightly

It is needed to wait a small time between measures because the load cell measures have some noise, so it the measures were calculated in two consecutive PLC loop, false errors could be found. Moreover, at the beginning of the movement, the actuator can be slightly