Add support for running multiple instances #192
Assignees
Labels
Comments
csatt
added a commit
that referenced
this issue
Mar 12, 2023
This commit adds the feature requested in Issue #192. IV_Swinger2_gui.py - GraphicalUserInterface class changes: - __init__: - Add instance and main_gui creation parameters - Add attributes: - self.instance (string) - Initial value from creation parameter - Will always be None for the main GUI - self.main_gui (object) - Initial value from creation parameter - Set to self if creation parameter value is None - self.instance_gui (dict of objects) - Only exists for main GUI - Contains - Initial value is empty dict: {} - Added to when an instance GUI is launched - Deleted from when an instance GUI is closed - Set root to tk.Toplevel() instead of tk.Tk() for instance GUIs - Pass instance value to set_root_options() method - Append /inst/{instance} to app_data_dir for instances and pass that in the creation of the ivs2 object - Set instance ivs2 object's usb_port property to DISCONNECTED - Set instance app_dir property to the main GUI's value (for Windows bug workaround) - Add derived properties: - instances - Sorted list of already-created instances - usb_ports_in_use - List of ports used by the main GUI and all instance GUIs - Change check_app_data_dir() method to take the app_data_dir as a parameter so it can be called before the creation of the ivs2 object - Modify set_root_options() method: - Added instance parameter - Append instance to title if instance is not None - In swing_loop() method, change minimum value of delay_ms from 1 to 10 to prevent any GUI from monopolizing the CPU - Modify start_centered(), start_to_right(), and start_to_left() methods to tile instance GUIs - Modify the close_gui() method: - Add warning if closing the main GUI and instance GUIs are still open - Add instance name to dialog that is generated when there are >5 changes to the config file - When the method is called for an instance GUI, remove the instance GUI object and delete it from the main GUI's instance_gui dict - Modify the run() method: - Suppress attempting the Arduino handshake if the usb_port property is DISCONNECTED - Suppress calling mainloop for instances - MenuBar class changes: - Add the instances menu to the MenuBar class - Call new create_instances_menu() method in __init__ - Add methods: - create_instances_menu() - populate_instances_menu() - depopulate_instances_menu() - update_instances_menu() - launch_entry_action() - launch_instance() - add_new_instance() - show_instances_help() - Add InstancesHelpDialog class - Suppress creating the Mac Preferences and Help menus for instance GUIs (because they crash, but are still present from main GUI) - Modify update_usb_port_menu() method: - Add call to find_serial_ports before populating the menu - Disable entries that are in use by other GUIs - Add DISCONNECTED entry to allow user to disconnect from any USB port - Modify select_serial() method: - Handle value of DISCONNECTED; - Close the current USB port (if any) by calling the ivs2 object's close_usb() method - Disable the go button - Save value in the config file - Modify run_simulator() method to pass the app_data_dir value in the creation of the SimulatorDialog object IV_Swinger2.py: - Move code to get the default app_data_dir into a global function so it can be used by GUI - Resurrect the extended PrintAndLog class. - Add instance variable for log_file_name to allow (but not require) instance-specific logging - Remove terminate_log() global function since it is a method in the extended PrintAndLog class - Modify the apply_usb method in the Configuration class: - Handle the case where the USB port is in use: - print and log a message - set ivs2 object's usb_port property to DISCONNECTED - Handle the case where the config value is DISCONNECTED - Treat just the same as case where the port in the config is attached; do not try to find an Arduino port - Add optional usb_ports_in_use creation parameter to IV_Swinger2 class - If the object is created with that parameter specified, set the object's usb_ports_in_use attribute to the list passed in. Otherwise, set it to an empty list - Add a close_usb() method and use that in the reset_arduino() method. This method is now used by the GUI when closing an instance GUI. - Add logging of the resetting of an Arduino IV_Swinger2_sim.py: - Add support for non-default app_data_dir: - Pass the app_data_dir creation parameter to the IV_Swinger2 __init__ - Add app_data_dir creation parameter to the SimulatorDialog class and pass it to the ivs2_sim object at creation
This was referenced Apr 3, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The majority of users connect a single IV Swinger 2 to a laptop at a time. However, there have been some users recently who need to connect two or more IV Swinger 2's to the same laptop and swing curves concurrently on them. This presents a few issues. First, separate instances of the application must be run concurrently, and that requires creating copies of the application. Second, there is a single configuration file, and that configuration file will be written with conflicting information by the different instances resulting in incorrect behavior (such as erroneous calibration scaling.) Third, it is not easy for the user to distinguish which results are for which IV Swinger 2.
It is possible to avoid these issues with the current software by using a different user account for each instance since all of the directories and files are under the user's home directory. This solution is not ideal, however, because any interaction with the software requires switching user accounts to control different instances.
This issue requests an enhancement to the software to allow running multiple instances by the same user. The main GUI should allow the user to create new instances and launch new GUIs to control them. Each instance should have all of its files (configuration, log files, results) in a directory dedicated to that instance. This will prevent conflicts and will make it easy for the user to keep track of which results are for which IV Swinger 2. Although each instance has its own GUI, only one copy of the application itself should be running. All of an instance GUI's controls (menus, buttons, etc) should be specific to that instance. So, for example, the Results Wizard should display the instance's results only.
Note that this feature could be useful even for users who do not have a need to run multiple instances concurrently. Instances can also be used simply to organize results that are collected for different PV modules (or experiments, or whatever.)
The text was updated successfully, but these errors were encountered: