How to load hardware controllers

[bicarlsen]

In commit 2e19490 on the split_files branch I've updated the architecture a bit. The idea with this reorganization being that a System consists of a lamp, SMU, computer (which defines file locations), and IV system (which defines calibration parameters). The lamp and SMU are controllers with a common interface -- e.g. every lamp has the lamp_on, lamp_off, etc. methods -- where the actual instances are pulled in, but are separate from the main package.

My idea is that each of the hardware controllers has a unique name that can be specified in the settings. In the Computer settings you can specify folders to find the hardware controller implementations, and there will be a function that searches these folders, pulls in all the sound controllers, and uses the one with the matching name specified in the lamp or smu settings.

Another possibility would be to just specify the file location of the controllers directly in the lamp and smu settings.

[bicarlsen]

Or a possbily better way is to have each system be it's own thing, and you tell the application which system to use. Again, each system would implement a standard API for use within the application. This way we would have more control over how the compoennts of the system interact, and allow them to be more dynamic.

[FTEickemeyer]

First of all I really like your approach you mentioned in the first paragraph, having a common interface and pulling in the instances from separate modules.
The question you raise is important. My first idea reading your text was that we should have a system folder where the hardware controllers are in with a unique name, i.e. your first option. The problem there might be that we might want to run several IV systems with the same computer. I e.g. might want to use my or the lab laptop to run different IV systems. So far, we used a system settings file to define which system to use, there one could define the location and filename of the controllers as well. Then one could choose in the main program which system to use. Does that make sense to you?

[bicarlsen]

Yeah. So I think the best would be:

1. In the application you can define where to look for Systems. Any System found in those locations can be selected. If only one system is found, the application will default to it.
2. Systems will implement a common System interface and be the main point of interaction for application to communicate with the hardware.
   1. Each system consists of a
      • Lamp represented by a Lamp object.
      • SMU represented by an SMU object.
      • Computer configuration represented by a ComputerParameters object.
      • IV system configuration represented by a IVSystemParameters object.
      • Any other components required to drive the system (e.g. an arduino)
   2. Each System will implement the methods for basic measurement types, and can add additional measurements for that specific system.
      • connect, disconnect - connect was previously initialize_hardware
      • lamp_on, lamp_off
      • measure_light_intensity
      • measure_iv_curve
      • measure_chronopotentiometry - Constant current measurement
      • measure_chronoamperometry - Constant voltage measurement
      • measure_mpp
      • calibrate (admin only)
3. A System's user facing measurements are defined in a name-method dictionary. User facing measurements are defined in its _user_measurements property and admin only measurements are defined in its _admin_measurements property. This allows each system to implement additional measurements.

[FTEickemeyer]

Sounds good!
Just one comments, I wonder if we need 2i) "Any other components required to drive the system". Those components are used in our systems e.g. to drive the filter wheel or a shutter which is in principle part of the lamp.

[bicarlsen]

That comes for free in the sense that the one developing the System has complete control over its operation, and so can include any additonal components they want or need. As long as the System adheres to the designated API, the designer can do whatever they want.