D1. Specifications

USER STORIES

As a researcher, I want to be control all 30 motors at once and specify parameters to control the flow of fluid in the tank.

As a researcher, I want to be able to control subsets of motors at a time and have unique configurations for different subsets of motors at the same time.

As a researcher, I want to be able to save configurations of the motors as presets for ease of access later.

As a researcher, I want the motors to be optimized to run simultaneously with lag minimized.

As a researcher, I want the GUI to have an option to utilize predefined motor patterns, such as implementing a wave-like function for motor use.

As a researcher, I want the ability to specify individual configurations for all 30 motors and run them simultaneously.

As a researcher, I want to be able to troubleshoot to determine whether and why pistons may be out of sync.

REQUIREMENTS 

  1. Definite
    1. Individual Manipulation – System must be able to regulate each individual piston out of the array of 30 pistons. Must allow user to easily access and adjust velocity and curve of movement of each of the pistons
    2. Ease of Assertion – Application will show a comprehensive list of each piston’s parameters, with the ability to set these user-inputted parameters to multiple at a time, to prevent user from needing to manually insert these instructions individually.
    3. Default Presets – Application must define a list of default parameters to ensure ease of repetitive use
    4. Accurate Logging – All runs should have data logged
  2. Probable
    1. Data Analysis and Feedback – System should be able to track movement of the pistons to accurately gather data for ML analysis purposes (not a hard and fast requirement at this point)
  3. Improbable
    1. Self Regulation – System must prevent pistons from “drifting” by collecting real-time data from their position
    2. Error Tracking – During testing, should be able to identify why drifting is occurring

NON-FUNCTIONAL REQUIREMENTS 

  1. Definite
    1. No damage – Application GUI must not crash in a way that could damage the physical machinery 
    2. No loss of performance – Additions to GUI should not be memory-intensive enough to acutely slow down the PC running the script. (PC is a bit older)
    3. Documentation – Application should have clear and available documentation for the setup, startup, and usage of the GUI.
    4. Updatability – Application should be maintainable with the current system and possible updates to software in the future
    5. Integrations – Application must interface with Studio5000 to start-up necessary functions for pylogix to interface with
  2. Probable
    1. Application GUI should prevent the user from running the machine before prepping the pistons in order to prevent issues 
    2. Application should have error logging and user instructions to debug issues
    3. Application GUI should have an immediate abort button in case issues seem to arise that could harm the machine that works in all situations
    4. Application must have understandable parameter descriptions in order to simplify use for a new user 
  3. Improbable
    1. Application GUI must display and update a graph of the feedback on piston position in real-time while machine is running