Progress update for week 14 05.04.20

GUI design. The sybols comes from E-draw Max.

This week was packed with things to do. First of all, I would like to mention that Hong Wu, I and my supervisor Manuel Avila has agreed that I should try to write a scientific article. The article should preferably be published in one of the journals approved by our university. This sounds like a great challenge and I hope that I can do a good job and deliver what is expected of me.

Second, I have been very occupied with programming and reading the QT-documentation. I now have many different versions of the same program with different ways of tackling the various problems that showed up. An image has been uploaded to show the visual progress of the GUI. To better tackle these problems that occurred and to structure the program in a good way, a flowchart was made for reference. You can see the chapter about the flowchart from the report below.

 

Program flow/planning

Before doing anything, it is important to have a clear idea of what you are trying to accomplish. An idea of how the GUI should look and what functions it needed to perform was formed. First the GUI needed buttons to open and close the valve. It needed a way to input and adjust the volume of the tank and the flow, so that this could be set by the user. Also, it must contain the tank illustration. Preferably with animation that shows the water flowing through the valve, into the tank and out of the tank. When the valve is closed, the animation will show that there is no water flowing into the tank and when the tank is empty the animation will show that there is no water flowing out of the tank. Using these criteria, 4 states were derived which could be used to structure the program a state machine.

State0 represents the empty tank. No water is flowing in and no water is flowing out. When the valve is opened it will change to the next state. The next state will depend on the flow. If the flow from the valve is higher than the drain flow, it will enter state1. If the flow from the valve is less than the drain flow, it will enter state2. This is because the tank level will not increase if the flow is less than the drain and the tank remain empty, but if it is greater the level will increase. Upon transitioning an animation showing the water flowing from the valve will show. Filling up the inlet and outlet pipe with water.

State1 represents the tank being filled/emptied with water. The animation shows that there is flow both into and out of the tank as well. If the water reaches the top of the tank, the tank will shut the valve, activate and alarm and transition to state3. if the valve is shut by the controller/user, it also goes to state3. Upon transitioning the valve animation should show that the valve is closed. If the tank contains water and the valve is switched to half the drain flow, it will empty and then transition to state2.

In state2 the tank has a flow into the tank less than the flow out. Meaning that the valve illustrations will show that the tank is being filled, but the level never increases. This state should be prevented by the PLC controller, but if it is not successful then this state will show. If the valve flow is changed to twice the drain, it will transition to state1. If the valve flow is turned of it will transition back to state0 and upon transitioning the intake- and drainpipes will be emptied.

In state3 the tank is emptying because the valve is closed but the drain is open. If the valve is reopened it will transition back to state 1. Upon transitioning it will then show the animation water exiting the valve. Finally, if the volume becomes zero it will transition back to state0. Upon this transition it will show the drainpipe being emptied.

Figure 1: State machine diagram

Throughout the development period there was a lot of experimentation with different ways of structuring the program and different ways of executing its various tasks. Some solutions worked better than others and eventually lead to the final result. To implement the state machine, some of the programs developed on the way ended up using sub states to perform the animations. However, the core idea remains the same. This state machine has been summarized in the figure above.

From the state machine the following program flow can be derived:

Figure 2: Basic program flow

The basic idea the flow chart shows is that the GUI is run by a loop in the main thread and the state machine is run by a separate worker thread. The worker thread checks what the current state should be and will call that function. Each state-function will perform its task, set the next state and then signal the GUI to run the transition animation before the loop returns to start. If the user pressed the Exit button on the window, the main thread will terminate the worker thread before ending itself.

 

 

 

 

 

marcuslb