drmwve / capstone-project Goto Github PK

The Main Window and Execution Handler are the two top-level interfaces between the UI and the execution code respectively. In the Main Window, define the signals which are emitted by the UI to send commands to the execution code.

There currently isn't a way to add a name for a new brew recipe without a physical keyboard. Using PySide if possible, or another way if it's not, we need to bring up a virtual keyboard (when on the Raspberry Pi, so add a check for that flag when done testing) when the user clicks the add new recipe button so they can type the name and enter it. This may involve changing the code to do something besides popping up the dialog box that's currently implemented, because on a small screen it's likely the keyboard will hide the popup anyways.

Create a branch for this because it may end up being an extensive change. We'll also need to update the tests for the Brew Config screen to cover whatever changes happen.

A typical mash is between 146 and 156 degrees F. If the user attempts to go out of this range, a dialog should pop up informing them that this is beyond the ideal temperature. There should be a flag to ensure this only happens once, which is reset when they go back into the acceptable range. These numbers should be added as constants along with the other ones at the top of the Brew Config class.

There's already code to prevent the user from going below or above the absolute maximum range, which I've now set to 130-168 after some research. Reaching the limits of this range should disable the relevant mash temperature button.

When you enter the progress screen, the progress bar is full until the bar updates for the first time. I'm guessing something isn't initialized properly.

When you abort a brew on the brew progress screen and try to start another brew, it still says "aborting brew" and the pause and abort buttons are grayed out.

The intended function is that decreasing the number of hop cartridges doesn't cause the buttons along the bottom of the screen to move, keeping the hop dispenser labels in place is currently a workaround to prevent that from happening. Now that the Brew Config screen has been reworked as a widget and we can dig into it with Designer, let's try to get it working as intended when we have time.

When a step is skipped, completes early, or runs longer than expected, this isn't reflected in the UI. When a step starts, a process should calculate the remaining time and emit it in a signal, possibly in the stepstarted signal along with the step label, as a tuple.

1. Updating the screen needs to catch the hardware state signal emitted every quarter second from the Device Handler (connect them in the autobrewer file) and update the UI elements using the supplied Hardware State variable instead of defining its own internal state variables for everything.
2. All functions which call component control functions must catch any ComponentControlError with a try-catch and display a popup notifying the user why their action was unsuccessful if it generates an error. When you catch the error, there should be a way to read the message it sends and I used pretty descriptive messages which can be output directly to the popup.
3. We're now using PID loops to control the temperatures. This is mostly for the HLT and MT, but works for all 3 (boiling liquid can't use a PID since boiling water always has a temperature of 212, but it's possible to set any temp on the BK at the moment). We should think about how to allow the user to get and set the target temperatures and see if the PID is currently controlling a kettle.

1 and 2 are definitely the priority, we can get to this part later, but 3 related to the other two so I'm putting it in this issue.

I turned the brew progress screen into a generic process progress screen. We need to do the following:

1. Pressing the abort button has weird behavior, look into that.
2. The GUI file needs to be updated with generic names for the buttons.
3. The cleaning process needs to utilize the new generic progress screen. As it is, it should be as simple as starting a cleaning process and moving to the process status screen.
4. The "flush system" process needs to be implemented in the UI, it can probably use the same menu as the start cleaning button.
5. The "abort" code in the process status screen needs to be changed to "stop process"

When a process is started, a process emits a signal with the estimated total completion time of the process, which can be used to increment a UI progress bar. Each step of a process emits a signal with a string describing what the step is doing. A process emits a signal when it is completed. These signals are passed up through the execution code hierarchy to the execution handler, where it can be connected in main.py to relevant slots in the UI.

Backing up a little bit, I think it should just be very clear from the main menu when a process is in progress and easy for the user to get to the process status screen. Either that, or it should be impossible for the user to go back to the main menu from the process status screen without stopping the process, and there should instead be a button to take you to the Device Status but the main menu button is replaced with a button that takes you back to the process status screen.

I'm leaning more towards the second option, since that would prevent a whole range of possible unintended user interactions, since after all, you shouldn't really be able to do anything but monitor the process and device status when a process is running until you kill it. However, MainMenu/ProcessStatus button on the device status screen would have to be changed based on which menu the user got to that screen from, which would take a little thinking.

What do you think?

I created a new branch called styler which has my implementation on styling the GUI windows and widgets, it adds styler.py to the GUI folder which handles all the palette color assignments. Please review commit: b6772ef and if the code, style, and feature look good the branch can me merged back to development and deleted.

I think the following changes would make the UI look cleaner:

1. On the Brew Config Screen, the UI elements for quick brews should be above the "Start Brewing" and "Main Menu" buttons. The dropdown menu for the recipes would also look better if it was much wider and taller, and I think there should be a label over all the quick brew stuff that says "Quick Brew" or "Load Quick Brew".
2. The cleaning button needs to say something else now that it does multiple things. The buttons on that screen are also all over the place.
3. The two buttons at the bottom of the device status screens would be easier to click if they were horizontally spaced instead of vertically.

We should spend some time looking at it and trying to think of more ways to make it look nicer, if we can.

Certain steps create persistent hardware states, such as the HLT heat leaving the heaters on. If a step after that depends on the steps before it creating those states, without checking it's still true or enforcing it, there's an issue. The problem is, the user can pause the process and change the hardware state at any time. It's okay if a step creates a persistent hardware state, but a step should always enforce the hardware state it needs. The following needs to happen:

1. All steps which implicitly depend on a component being on need to turn it on themselves to ensure it's on. I think this is really just the HLTtoMT needs to turn the heating element on, same with the MTRecirc.
2. All steps during which the heating elements or pumps don't need to be on should explicitly turn them off. Any pumps or heating elements not explicitly in use by the step need to be turned off at the beginning of the run function.

1. A pump can be turned on, and then the ball valve path that allowed it to be turned off can be closed without disabling the pump. A check should either disable the pump when this happens or prevent the ball valve from being changed.
2. The hardware state is saved as a runtime variable, which is reset when the program is reset. A reset in the program could cause an inaccurate depiction of the hardware state. The hardware state should be saved to disk whenever it's changed and then read at runtime, or the program should set all hardware components to a default state at initialization.

This should be pretty simple. The save button could be disabled by default, and disabled when you change selected recipes or save the current recipe. Pressing any button that changes the recipe should re-enable the button. When the user presses the start brew button, or attempts to change the selected recipe, the UI should pop up a dialog box asking if they'd like to save their unsaved changes first.

Importantly, this function would have to be connected to the combo box change signal before the changeSelectedRecipe function so the UI elements don't change over first. I don't think the dialog box would block execution either, so this function would have to copy the recipe from the UI to a local variable, pop the yes/no dialog box, and if the user saves, put the recipe in the savedBrewRecipes variable and call the pickler save function itself instead of just calling the existing saveRecipe function in the Brew Config class.

Alternatively, going back to #7 , we could save any change as soon as it's made. This would be as simple as connecting the saveRecipe function to all of the buttons that change a recipe. Then there wouldn't even need to be a save recipe button. I feel like this is unclear and could be inflexible if a user wants to significantly change a recipe once without saving it.