I’ve been running cultures in a turbidostat setup and was aiming to capture the point when the growth rate is at its maximum. To determine this, I ran precultures to analyze growth curves and pinpoint the time/OD corresponding to peak growth. I then used this to set target OD for the PIOs to dilute at.
While working with the PIOs, I noticed that setting a target OD directly can be error-prone, since there can be variability or jumps in OD readings between experiments. Especially if you need to use a different unit. I realized that it’s more reliable to start the turbidostat at a fixed time point instead. Ideally, I’d like to automate this process: start the turbidostat after a specific time from the experiment’s start, take a “snapshot” of the current OD at that moment, and use that value as the target OD for subsequent dilutions.
I looked into using profiles to achieve this, but couldn’t find a way to take a snapshot of the current OD and set it as the new target OD automatically.
If I understand what your asking, profiles should be able to do this:
experiment_profile_name: start turbdiostat with current OD
metadata:
author: Cameron DP
description: Start the turbidostat after N hours, and use the current OD reading as the target OD. OD reading should be on whe n this profile starts.
common:
jobs:
dosing_automation:
actions:
- type: start
hours_elapsed: 2
options:
automation_name: turbidostat
target_od: ${{::od_reading:od2.od}}
exchange_volume_ml: 1.5
This dynamically fetches the latest OD reading, and sets it to target_od at turbidostat start up.
Thanks for your quick reply. So I tried your solution with slight modifications.
experiment_profile_name: start turbdiostat with current OD
metadata:
author: Cameron DP
description: Start the turbidostat after N hours (time is based on start of this profile), and use the current OD reading as the target OD. OD reading should be on whe n this profile starts.
common:
jobs:
dosing_automation:
actions:
- type: start
hours_elapsed: 10
options:
automation_name: turbidostat
target_od: ${{::od_reading:od2.od}}
volume: 4
- type: stop
hours_elapsed: 24
temperature_automation:
actions:
- type: stop
hours_elapsed: 24
stirring:
actions:
- type: stop
hours_elapsed: 24
growth_rate_calculating:
actions:
- type: stop
hours_elapsed: 24
od_reading:
actions:
- type: stop
hours_elapsed: 24
led_automation:
actions:
- type: stop
hours_elapsed: 24
I got this error for one of the PIOs:
dosing automation|GPIO-13 is currently locked but a task is overwriting it. Either too many jobs are trying to access this pin, or a job didn’t clean up properly. If your confident you can release it, use pio cache clear pwm_locks 13 --as-int on the command line for P04.|
And for the other one it actually did not take the right target OD for some reason it went higher. I would like to add the OD readings as a picture and the logs but I am not allowed as a new user.
I already found a clue about one of the problems. I think when I run this profile the time between dosing is set to 60 Minutes (normally we have it at 0.25 seconds). Therefore the target OD was correct but sometimes after 60 minutes not reached and it only checked for target OD again after another 60 minutes therefore diluting later.
Yes, I forgot to add the duration param to the turbidostat section, which defaults to 60 if not provided:
experiment_profile_name: start turbdiostat with current OD
metadata:
author: Cameron DP
description: Start the turbidostat after N hours (time is based on start of this profile), and use the current OD reading as the target OD. OD reading should be on whe n this profile starts.
common:
jobs:
dosing_automation:
actions:
- type: start
hours_elapsed: 10
options:
automation_name: turbidostat
target_od: ${{::od_reading:od2.od}}
duration: 0.25
volume: 4
- type: stop
hours_elapsed: 24
temperature_automation:
actions:
- type: stop
hours_elapsed: 24
stirring:
actions:
- type: stop
hours_elapsed: 24
growth_rate_calculating:
actions:
- type: stop
hours_elapsed: 24
od_reading:
actions:
- type: stop
hours_elapsed: 24
led_automation:
actions:
- type: stop
hours_elapsed: 24
For the that GPIO-13 error, would it be possible that the media pump was already running when the turbidostat started (like some other process / activity was using it?)
We have locks to prevent multiple “things” using the PWMs outputs (like pumps). If you feel confident it’s okay or it was a bug, you can use