more

Author: CamDavidsonPilon

developer-guide/03-Background jobs/02-writing-background-jobs.md

@@ -83,7 +83,7 @@ class IntroJob(BackgroundJob):
 
     def set_intensity(self, intensity):
         self.intensity = intensity
-        led_intensity(channels=self.LED_channel, intensities=self.intensity)
+        led_intensity({self.LED_channel: self.intensity})
 ```
 
 Next, we create the "on exit" behaviour (turn off LED) by overwriting the `on_disconnected` function.
@@ -107,7 +107,7 @@ class IntroJob(BackgroundJob):
 
     def set_intensity(self, intensity):
         self.intensity = intensity
-        led_intensity(channels=self.LED_channel, intensities=self.intensity)
+        led_intensity({self.LED_channel: self.intensity})
 
     def on_disconnected(self):
         self.set_intensity(0)
@@ -133,7 +133,7 @@ class IntroJob(BackgroundJob):
 
     def set_intensity(self, intensity):
         self.intensity = intensity
-        led_intensity(channels=self.LED_channel, intensities=self.intensity)
+        led_intensity({self.LED_channel: self.intensity})
 
     def on_disconnected(self):
         self.set_intensity(0)
@@ -143,7 +143,7 @@ if __name__ == "__main__":
     from pioreactor.whoami import get_assigned_experiment_name
 
     unit = get_unit_name()
-    experiment = get_unit_name(unit)
+    experiment = get_assigned_experiment_name(unit)
 
     job = IntroJob(unit=unit, experiment=experiment)
 
@@ -210,7 +210,7 @@ We see that the `__init__` requires the two parameters for PWM: `hz` and an `ini
 We next initialize the PWM code (this is still in the `__init__`) that controls the PWM outputs on the HAT, and add more imports:
 
 ```python
-from pioreactor.hardware_mappings import PWM_TO_PIN
+from pioreactor.hardware import PWM_TO_PIN
 from pioreactor.utils.pwm import PWM
 from pioreactor.config import config
 
@@ -220,7 +220,7 @@ from pioreactor.config import config
     def __init__(...)
         ...
 
-        pwm_pin = PWM_TO_PIN[config["PWM_reverse", "motor_driver"]]
+        pwm_pin = PWM_TO_PIN[config.get("PWM_reverse", "motor_driver")]
         self.pwm = PWM(pwm_pin, self.hz)
         self.pwm.lock()
 
@@ -318,7 +318,7 @@ import json
 
 from pioreactor.config import config
 from pioreactor.background_jobs.base import BackgroundJob
-from pioreactor.hardware_mappings import PWM_TO_PIN
+from pioreactor.hardware import PWM_TO_PIN
 from pioreactor.utils.pwm import PWM
 from pioreactor.utils import clamp
 
@@ -337,7 +337,7 @@ class MotorDriver(BackgroundJob):
         self._initial_duty_cycle = initial_duty_cycle
         self.duty_cycle = initial_duty_cycle
 
-        self.pwm_pin = PWM_TO_PIN[config["PWM_reverse", "motor_driver"]]
+        self.pwm_pin = PWM_TO_PIN[config.get("PWM_reverse", "motor_driver")]
 
         self.pwm = PWM(self.pwm_pin, self.hz)
         self.pwm.lock()

developer-guide/03-Background jobs/03-avoiding-od.md

@@ -22,7 +22,7 @@ class JustPause(BackgroundJobWithDodgingContrib):
 class JustPause(BackgroundJobWithDodgingContrib):
 
     def __init__(self, ...):
-        super().__init__(..., enable_dodging_od=True or False) # set to True if you want the dodging behaviour right away.
+        super().__init__(..., enable_dodging_od=False, plugin_name="just-pause") # set to True if you want the dodging behaviour right away.
 
 
     def action_to_do_before_od_reading(self):
@@ -45,15 +45,15 @@ You can handle the "dodging" case and "continuous" with the `initialize_*` metho
 class JustPause(BackgroundJobWithDodgingContrib):
 
     def __init__(self, ...):
-        super().__init__(..., enable_dodging_od=True or False) # set to True if you want the dodging behaviour right away.
+        super().__init__(..., enable_dodging_od=False, plugin_name="just-pause") # set to True if you want the dodging behaviour right away.
 
     ...
 
     def initialize_dodging_operation(self):
-        self.logger("OD reading is ON and I'm enabled for dodging, so set up what I need...")
+        self.logger.debug("OD reading is ON and I'm enabled for dodging, so set up what I need...")
 
     def initialize_continuous_operation(self):
-        self.logger("OD reading is off, or being ignored, so set up what I need for that...")
+        self.logger.debug("OD reading is off, or being ignored, so set up what I need for that...")
 
     def action_to_do_before_od_reading(self):
         # example
@@ -69,7 +69,7 @@ class JustPause(BackgroundJobWithDodgingContrib):
 4. We also want some "buffer" time before and after an OD reading. For example, if using a bubbler, we want the bubbles to dissipate completely before taking an OD reading. We should stop bubbling early then. To set these times, add the following to your config.ini:
 
 ```
-[<job_name>]
+[<job_name>.config]
 pre_delay_duration=<float>
 post_delay_duration=<float>
 enable_dodging_od=1

developer-guide/04-Automations/02-writing-automations-1.md

@@ -104,7 +104,7 @@ class NaiveTurbidostat(DosingAutomationJobContrib):
 
 ```
 
-Run the script with `pio run dosing_atomation --automation-name naive_turbidostat --target-od 0.5`. This will start the job. After a moment, you may notice that warnings are thrown - that's because there's no optical density measurements being produced! You can use crtl-c to stop the job.
+Run the script with `pio run dosing_automation --automation-name naive_turbidostat --target-od 0.5`. This will start the job. After a moment, you may notice that warnings are thrown - that's because there's no optical density measurements being produced! You can use crtl-c to stop the job.
 
 #### Editing attributes over MQTT (optional)
 

developer-guide/07-Plugins/01-intro-plugins.md

@@ -152,15 +152,15 @@ Here's an example of adding a custom automation: place the following code into t
 
 ```python title="/home/pioreactor/.pioreactor/plugins/demo_automation.py"
 # -*- coding: utf-8 -*-
-from pioreactor.automations.dosing.base import DosingAutomationContrib
+from pioreactor.automations.dosing.base import DosingAutomationJobContrib
 
 __plugin_summary__ = "A demo dosing automation"
 __plugin_version__ = "0.0.1"
 __plugin_name__ = "Demo Dosing Automation"
 __plugin_author__ = "Cam Davidson-Pilon"
 __plugin_homepage__ = "https://docs.pioreactor.com"
 
-class DemoAutomation(DosingAutomationContrib):
+class DemoAutomation(DosingAutomationJobContrib):
 
     automation_name = "demo"
 
@@ -169,7 +169,7 @@ class DemoAutomation(DosingAutomationContrib):
         self.volume = volume
 
     def execute(self):
-        self.logger("Here I would execute...")
+        self.logger.debug("Here I would execute...")
 
 ```
 

developer-guide/07-Plugins/03-plugin-as-python-package.md

@@ -43,7 +43,7 @@ Here's a general directory outline of how your files should be organized for a j
 ├─ 📝 setup.py
 ```
 
-The directory outline is very similar for an **automation plugin** &#151 the only difference is the location of the `.yaml` file.
+The directory outline is very similar for an **automation plugin**, the only difference is the location of the `.yaml` file.
 
 ```
 📁 <DISTRIBUTION-NAME with dashes>

static/img/user-guide/inventory-model-overview.png

@@ -0,0 +1,71 @@
+---
+id: change-model
+title: Change your Pioreactor model
+sidebar_label: Change Pioreactor model
+description: Adjust the Pioreactor model in the Inventory page and register custom models that appear in the UI.
+---
+
+
+## Update a Pioreactor's model from the UI
+
+You can update the model that the software uses for each unit from the **Inventory** page.
+
+1. Navigate to **Inventory** in the sidebar.
+2. Locate the Pioreactor you want to configure and open the **Model** dropdown.
+3. Pick the correct entry. The change is saved immediately.
+
+![The Inventory page with the Model dropdown highlighted.](/img/user-guide/inventory-model-overview.png)
+
+Changes to the model update any UI text, configuration safety limits, and workflows that depend on vessel geometry.
+
+## Add a custom model
+
+The UI lists every YAML definition stored in `.pioreactor/models/`. Each file represents a single model.
+
+1. Create the directory if it does not already exist:
+
+   ```bash
+   mkdir -p ~/.pioreactor/models
+   ```
+
+2. Add a new YAML file. Use a descriptive file name such as `my_custom_model.yaml`.
+
+   ```yaml
+   model_name: custom_100ml
+   model_version: "1.0"
+   display_name: "Custom 100 mL, v1.0"
+   reactor_capacity_ml: 100.0
+   reactor_max_fill_volume_ml: 95.0
+   reactor_diameter_mm: 50.0
+   max_temp_to_reduce_heating: 80.0
+   max_temp_to_disable_heating: 85.0
+   max_temp_to_shutdown: 90.0
+   ```
+
+### Required fields
+
+| Field | Description |
+| --- | --- |
+| `model_name` | A unique identifier. Use lowercase letters, numbers, and underscores. Example `pioreactor_20ml` |
+| `model_version` | Semantic version string that differentiates variants of the same model. Example: `1.1` |
+| `display_name` | What appears in the UI dropdown. Example: `Pioreactor 20ml, v1.1`|
+| Capacity and geometry fields | Used by dosing and safety calculations. Provide real measurements in millilitres and millimetres. |
+| Temperature limits | Guardrails for the heater. Adjust them to match your hardware. |
+
+If any field fails validation, the Pioreactor logs an error in `pioreactor.log` and skips the file. Double-check spelling and numeric values if your model does not appear.
+
+### Reload the web UI
+
+After adding or editing model files, restart the web UI service so it picks up the new definitions:
+
+```bash
+sudo systemctl restart pioreactor-web.target
+```
+
+Return to the Inventory page and reopen the **Model** dropdown. Your custom entry should now be available alongside the built-in models.
+
+## Troubleshooting
+
+- **No new dropdown entries:** confirm the YAML file lives in `/home/pioreactor/.pioreactor/models/` on the leader and that the file extension is `.yaml` or `.yml`. Restart the `pioreactor-web.target` service once more.
+- **Validation errors in the logs:** open `pioreactor.log` or run `journalctl -u pioreactor-web.target` to view the message, then update the YAML file accordingly.
+- **Distribute to workers**: workers need these files to, so if you've added it to your leader, you can run `pios cp ~/.pioreactor/models/my_custom_model.yaml` to distribute it to workers.

user-guide/03-Extending your Pioreactor/01-cluster-management/03-change-model.mdx

@@ -52,7 +52,7 @@ pio run experiment_profile execute /home/pioreactor/.pioreactor/experiment_profi
 Stop all running profiles from the CLI with:
 
 ```bash
-pio kill --job-name experiment_profiles
+pio kill --job-name experiment_profile
 ```
 
 Or target a specific profile by its job ID:

user-guide/03-Extending your Pioreactor/04-Experiment Profiles/03-start-stop-profiles.md

@@ -27,7 +27,7 @@ To run the script, you'll first need to install the Python library:
 
 
 ```python
-import sleep
+import time
 import board
 import adafruit_scd4x
 

user-guide/03-Extending your Pioreactor/11-using-stemma-qt.md

@@ -46,7 +46,7 @@ The chemostat automation is the second simplest dosing automation. Every `durati
     * one labelled "media"
 
 
-A turbidostat ("turbidity-static") tries to keep the turbidity (the optical density, or OD), constant over time. This is usually accomplished by taking frequent measurements of the turbidity (every 30 seconds), and performing a set media/waste pump cycle if the optical density (or normalized optical density) exceeds a `target OD` (or `target nOD`). The amount exchanged is the `volume` parameter (mL). For very fast growing cultures, we recommend a `volume` between 1.0 ml and 2.0 ml.
+A turbidostat ("turbidity-static") tries to keep the turbidity (the optical density, or OD), constant over time. This is usually accomplished by taking frequent measurements of the turbidity (every 15 seconds), and performing a set media/waste pump cycle if the optical density (or normalized optical density) exceeds a `target OD` (or `target nOD`). The amount exchanged is the `volume` parameter (mL). For very fast growing cultures, we recommend a `volume` between 1.0 ml and 2.0 ml.
 
 This automation will always dose the `volume` parameter, even if it's not enough for the OD to drop below the `target OD`. If that happens, then `OD > target OD`, and so the automation will trigger after the next check (30 seconds).
 
@@ -104,7 +104,7 @@ To further avoid overflow, we limit how much liquid is added in a single pump cy
 You can edit these parameters in your config.ini files.
 
 
-#### Section `[dosing_auomation.config]`
+#### Section `[dosing_automation.config]`
 
  - `pause_between_subdoses_seconds`: time to wait between doses - this is useful if you want to be sure the newly added liquid is sufficiently mixed before running the waste pump.
  - `waste_removal_multiplier`: the amount of additional time to run the waste pump after the influx pump has run. This is to ensure that the volume of liquid in the vial never exceeds the end of the efflux tube. Ex: if media ran for `0.75` seconds, then the waste will run for `waste_removal_multiplier * 0.75 seconds`