ph-meter-interface

https://github.com/sniprbiome/ph-meter-interface

Repository

README.org

#+TITLE:  ph-meter-interface
#+OPTIONS: toc:2
#+OPTIONS: ^:nil
#+LATEX_HEADER: \usepackage[margin=2.5cm]{geometry}

CLI interface written in python for the consort d230 ph-meter and a pump system made up of "NE-500 oem" pumps from syringepumps.com. Given a protocol (in an excel format) describing an experimental setup using the ph-meter and a pump system, it can execute said protocol while logging recorded ph-data.

An example of a protocol and a sample output can be seen below. Sample protocol:


#+ATTR_HTML: width="400px" :style margin-left: auto; margin-right: auto;
#+ATTR_ORG: :width 400
[[./images/sample-protocol.png]]

Sample output:

#+ATTR_HTML: width="300px" :style margin-left: auto; margin-right: auto;
#+ATTR_ORG: :width 300
[[./images/sample-output.png]]

* Contents
:PROPERTIES:
:TOC:      :include all :depth 3
:END:
:CONTENTS:
- [[#contents][Contents]]
- [[#a-short-introduction-to-the-ph-meter-and-pumps][A short introduction to the ph-meter and pumps]]
  - [[#consort-d230][Consort d230]]
  - [[#ne-500-oem-syringe-pumps][NE-500 oem syringe pumps]]
- [[#installing-and-running-the-program][Installing and running the program]]
- [[#protocol-setup][Protocol setup]]
  - [[#extended-pumptasks][Extended pumptasks]]
- [[#how-to-use][How to use]]
  - [[#program-options][Program options]]
    - [[#setting-the-protocol-used-for-the-run][Setting the protocol used for the run]]
    - [[#calibrate-ph-measuring-probes][Calibrate ph-measuring probes]]
    - [[#run-selected-protocol][Run selected protocol]]
    - [[#assign-new-ids-for-the-pumps][Assign new ID's for the pumps]]
    - [[#restart-failed-run][Restart failed run]]
    - [[#live-read-ph][Live read pH]]
    - [[#exit-program][Exit program]]
  - [[#settings][Settings]]
- [[#notes-for-other-developers][Notes for other developers]]
  - [[#general-program-structure][General program structure]]
  - [[#interacting-over-the-com-port][Interacting over the COM-port]]
  - [[#cli][CLI]]
  - [[#scheduler][Scheduler]]
  - [[#ph_meter][PH_Meter]]
  - [[#pumpsystem][PumpSystem]]
- [[#bonus][Bonus]]
- [[#references][References]]
:END:


* A short introduction to the ph-meter and pumps

The program connects to the consort d230 ph-meter and one-or-more NE-400 oem syringe pumps. Below is a brief introduction to how these devices work.

** Consort d230

The program is designed to be used together with the consort d230 ph-meter seen pictured below.

#+ATTR_HTML: width="300px"
#+ATTR_ORG: :width 500
[[./images/consort-d230.png]]

The device can contain up to seven removable modules (the columns). Four ph-probes can be connected to each of these modules.

Internally each of the modules have an ID, e.g. "F.0.1.22", which is independent of the position of the module in the device. The pH probe number 1 of a module will be the top-most probe, probe 2 will be the one below it, and so on. The ID's are important when designing a protocol. In a protocol, probe 2 of module "F.0.1.22" will be designated as "F.0.1.22_2".

It is connected to the computers com-port using an RS-232 cable. It is not possible to use an adapter from RS-232 to usb for the ph-meter.

Further information can be found at [[https://consort.be/Shop/electrochemistry/dataloggers/d230/][consorts website]] and in the user manual.

** NE-500 oem syringe pumps

The program is designed to be used together with a pump system consisting of one-or-more NE-500 oem syringe pumps pictured below:

#+ATTR_HTML: width="300px"
#+ATTR_ORG: :width 500
[[./images/NE-500-oem.png]]

The pump pumps using a given syringe filled with a liquid. The program currently only allows for bases to be pumped, as it assumes any pumping will give rise to an increase in pH.

Multiple pumps can be daisy-chained together to form a pump network. A pump-network can be set up by initially connecting the computer to the first pump using a specialized com-port-to-network-port cable. The pump can then be connected to another pump using a network cable, which can be connected to another pump and so on.

Each pump needs to be assigned an unique pump-id consisting of a integer between 0 and 99. This is needed so the program is able to send instructions to a specific pump. How to assign pump id's is described in a later section.

* Installing and running the program

+ Install python
+ Install the required python packages, by going to the ph-meter-interface folder and running "pip install -r requirements.txt" in the command line. If there are any conflicts, you might need to install everything as a virtual environment.
+ Start the program by running the .bat file (assuming that you are using Windows). This will open a console running the program.

* Protocol setup

ph-meter-interface uses excel files for protocols, with one row for each "pumptask". A pumptask is a task associated with a pump.

A pumptask contains the following information:

+ *Pump*: The pump-ID of the pump associated with the task. Will be a unique integer between 1 and 99.
+ *On/off*: Whether the pump should actually pump or not. If it is 1, it will pump when it detects a pH that is lower than expected for the current time period. If it is 0, it will not pump no matter what.
+ *pH probe*: The ID of the ph-probe associated with the task, e.g. "F.0.1.22_3". Technically it does not have to be unique, meaning that more than one pump can share the same ph-probe.
+ *Step*: How long the task should run for in minutes.
+ *pH start*: The pH at the start of the run.
+ *pH end*: The desired pH at the end of the run.
+ *Dose vol.*: The amount of liquid that the pump should dispense in case the associated ph-probe measures a pH that is less than expected at the current time-point.
+ *Force delay*: The minimum delay between each time it is considered whether the pump should pump. This is to ensure time for the dosed volume to mix into the liquid and affect the pH.

Note that pH start must be different from pH end. If the pH needs to be held constant, you can just make pH end slightly different from pH end.

A sample protocol with 12 pumptasks can be seen illustrated below:

#+ATTR_HTML: width="400px" :style margin-left: auto; margin-right: auto;
#+ATTR_ORG: :width 400
[[./images/sample-protocol.png]]


** Extended pumptasks

Sometimes we want to do something more complicated than just increasing the pH from a given pH at a given timepoint to another pH at a later timepoint. Sometimes we have multiple of these periods, of different lengths and different increases. ph-meter-interfaces can also handle this.

To add another period, just add new step, pH start, pH end, Dose vol. and Force delay values to the end of the pump task row. When the program then runs the protocol and finishes the first part of a task, it will then start the next part of the task, and so on.

An example of a protocol with multi-part pumptasks can be seen illustrated below:

#+ATTR_HTML: width="600px" :style margin-left: auto; margin-right: auto;
#+ATTR_ORG: :width 600
[[./images/sample-multitask.png]]


* How to use

When starting the program you will be presented with the following options:

1. Start the program the normal way. Use this if only one instance of a protocol needs to be run at the same time.
2. Start a pH-meter physical systems server, that manages the pH-meter and the pump system. Only instantiate one server.
3. Start at pH-meter-interface client. Multiple clients can be started at the same time. The server needs to be started first.

By writing the number associated with the option in the console and pressing enter, that option will be executed. Normally, you will just use option (1). Option (2) and (3) should only be used when multiple protocols needs to be run indepdently of each other.

** Starting a normal program
<>

When either starting the program the normal way (1) or starting a pH-meter-interface client (3), you will be presented with the following options:

1. Set protocol used for run.
2. Calibrate ph-measuring probes.
3. Run selected protocol.
4. Assign new ID's for the pumps.
5. Restart failed run.
6. Live read ph.
7. Exit program.

In a typical situation you would first select the desired protocol (1), calibrate the ph-probes (2), live read the pH of the samples to calibrate their initial pH (6), and finally start the program (3).

Note that before the program is started you should ensure that the settings are correct. They can be found in the [[./config.yml]] file, and it can be edited as a normal text file.

Each program option is described in detail in the sections below:

*** Setting the protocol used for the run

This will open a file dialog where you can explore your file system and choose the protocol you want to execute.

The default protocol chosen can be changed in the settings.

*** Calibrate ph-measuring probes

This will allow you to calibrate the probes used in your experiment. If this option is not run before the experiment is started, old calibration data will be used instead. It requires a buffer with a low pH, e.g. 4, and a high pH, e.g. 7.

When this option is run, you will be asked to enter the probe id's of the probes you want to calibrate as a comma-seperated list, eg. "F.0.1.22_3, F.1.0.13_1, ...". To select all the probes used in the protocol write "ALL". Capitilization does not matter.

After this you will be asked to place the selected probes in the buffer with the low pH, and to enter the pH of this buffer. Do this, and it will begin to print out the mV values detected by the selected probes. When these values have stabilized, press any key, and it will continue.

Repeat the same steps as for the low pH, but now for the high pH.

After this, the pH probes will have been calibrated and the results of this calibration can be seen in the calibration file, normaly found [[./calibration_data.yml]]. It is recommended to give a quick look over the calibration data to see if it looks approximatly correct.

*** Run selected protocol

This option will run the selected protocol. The program will initially try to connect to the pump system and the ph-meter, and if the connection cannot be established, it will fail.

For each row in the protocol, it will then create a pump-task. The program will the run the protocol on the basis of these pump-tasks. For information regarding how it fundamentaly works, see the section about the scheduler under developer information.

Depending on the settings, it may write the actions it takes to the console. Depending on the settings it might also save the intermediate results. This is important if the run fails for some reason, as the saved results then can be used to restart the run from where it stoped.

When the run has finished, the program will save all the results to the folder of the program as an excel file. The file will be named {time run was started}_{name of protocol}_results.xlsx.

A sample output can be seen picture below:

#+ATTR_HTML: width="300px" :style margin-left: auto; margin-right: auto;
#+ATTR_ORG: :width 300
[[./images/sample-output.png]]


*** Assign new ID's for the pumps

This option will begin the assignment of ID's for the pump. To do this, you will have to insert the main cable going from the computer, into the pump that you want to assign an ID to. It must not be plugged into the rest of the pump network.

You will be asked to assign enter the pump ID that you want to assign it. This must be a number between 1 and 99. Enter the ID, and the ID will be assigned to the pump. You can then continue to assign ID's by pluging the main cable into a new pump, and continuing like before.

When have finished assigning ID's, simply enter "STOP".

Note that the pumps will remember the ID's that they have been assigned.

*** Restart failed run

This option will allow you to restart a failed run, assuming that the intermediate results have been saved (this can be enabled in the settings file). This means that if the computer suddenly looses power 16 hours into a run, then the run can be restarted from the point where power was lost, instead of from the beginnning.

When this option is chosen, it will ask for the name of the intermediate file, which you should then give it. It will assume that the protocol used for the failed run is the same as the currently selected protocol. The program will then restart the run.

When restarting a run, the program will do the following:

+ It will look at the time the first action was taken, and assume that the start time of the run was the time when this action was executed.
+ It will then look at the pump task, and reschedule them based on the last time they were executed. This means that if there for example have been a 20 minute delay between the run failing and the run being restarted, the tasks might immediatly be executed if their task time is less than 20 minutes.
+ The final results will be saved to the program folder with the name {time run was started}_{name of protocol}_restarted_{time run was restarted}_results.xlsx.


*** Live read pH

This option will begin printing the pH values measured by the probes in the currently selected protocol, to the console. It will continue to do this until a key is pressed.

*** Exit program

This exits the program.

** Starting multiple clients

To start multiple clients, and thus run multiple different independent protocols, multiple instances of the program needs to be started: One server, and one client for each protocol. To run two independent protocols, three instances of the program thus needs to be started.

One of these instances needs to be turned into a server by pressing (2). This makes it responsible for managing the physical instruments. It listens on the network for messages from clients, executes the commands (ie. pump this amount with this pump, give me the pH measurement of this probe and so on) and returns an answer.

The other instances of the program needs to be turned into clients by pressing (3). This will turn them into a normal instances of ph-meter-interface, except that instead of managing the physical instruments by themself, they will send requests to the server. The clients can be used in the same way as described in [[sec:normal-start]].

Note that the protocols used by different clients must NOT use the same pumps nor pH probes as each other, and the program will return an error if this is attempted.

** Settings

A number of settings exists for the program, most of them concerning what information should be printed to the console.

It should be pretty obvious what most of the settings do, but some of them are very important to set correctly:

+ Com ports:
  + The com ports for the ph-meter and the pump system should be set correctly. The com port settings should be a number, typically 1 or 2, corresponding to which com port in the computer running the program that the devices are connected to.
+ Pump syringe settings:
  + Specifications for the syringes used by the pumps and how they are used. This includes the diameter of the syrringe. Note that the programs assumes that all the pumps uses the same kind of syringe.
  + The infusion rate, corresponding to how fast the pumps will pump. It is not very important, as long as the value is not very low or very high.
+ Intermediate results saving:
  + Depending on whether this is true or false, the program will save the results as it runs. This is only important in terms of restarting the run, as this requires the intermediate results.
+ ShouldInitiallyEnsureCorrectPHBeforeStarting:
  + This will add an extra step when starting a run using a given protocol, if it is set to True. This step consists of ensuring that the pH of all the samples measured by the probes used in the protocol is not less than the pH start value found in the protocol. The purpose of this step is to make the callibration of the samples pH (using the read live pH functionality) easier and to clean up the output data: Simply ensure that the pH is less that the pH start value found in the protocol for all the samples, start the run, and it will then only really begin the run when all the samples are ready.
  + The associated setting "IncreasedPumpFactorWhenPerformingInitialCorrection:" must be an integer, like 1 or 5.
+ AdaptivePumpingActivateAfterNHours:
  + This determines the number of hours after which the adaptive pumping should be enabled. Adaptive pumping fixes the problem with bacteria that might (suddenly) begin to produce more acid: In case the pH falls between measurements, in spite of pumping, it will begin to increase the number of pumps done whenever a pH measurement is made.
  + It is recommended that the adaptive pumping is not activated immediately, as sometimes it takes some time before the tubes connected from the syringes to the samples are completely filled. This means that it will take a number of pumps before base is actually pumped into the samples, which will make the adaptive overcorrect when base suddenly is pumped into the samples. A value of 0.75 (45 minutes) should suffice.
+ EmailSettingsFile:
  + File name/path of the file containing the email setttings, see section below. "ShouldSendEmail" needs to be "True", if emails should actually be send.

The settings are loaded as a yaml file, so if there are questions regarding the formating of the settings, look up yaml formatting.

* Setting up email responses

Ph-meter-interface is able to send an email if a run succeeds or crashes. This can be enabled in the config file, but the emails settings uses its own config file, ".env". This file should contain the following information:

+ SENDER_EMAIL: The email address that should be used to send the email.
+ SENDER_SMTP_SERVER: The smtp server of the sender email. If a gmail is used, this will be "smtp.gmail.com". Note that the email needs to be set up for this, which is not completely trivial, but documentation can be found on the internet.
+ EMAIL_PASSWORD: The password of the sender email, e.g. password123.
+ SSL_PORT: Port used for sending the email. Typically 465.
+ RECEIVER_EMAIL: The email address that the email should be send to.

To see an example setup, look in the "test/.test_env" file.

* Notes for other developers

This is mostly for any future developer of the program.

** General program structure

The general structure of the program is as follows:

Starter -> ClientCLI or
Starter -> PhysicalSystemServer

PhysicalSystemServer -> PhysicalSystems

ClientCLI -> Scheduler
ClientCLI -> PhysicalSystemsInterface (either PhysicalSystem or PhysicalSystemClient)

Scheduler -> PhysicalSystemsInterface (passed from the ClientCLI)

PhysicalSystemClient ~> PhysicalSystems (indirectely, over the network)

PhysicalSystems -> PH_Meter
PhysicalSystems -> PumpSystem

Notably, PhysicalSystems and PhysicalSystemClient implements the PhysicalSystemsInterface, so that the ClientCLI and Scheduler can work the same way, no matter if the network is used or not.

Where:

+ *Starter*: A starter class. It can either start a ClientCLI that does not communicate over the network, a ClientCLI that does communicate over the network, or a PhysicalSystemServer.
+ *ClientCLI*: A class corresponding to the console interface. It starts the actual program by either creating an instance of PhysicalSystems (which connects to the ph-meter and pumpsystem) if it does not communicate over the network, or a PhysicalSystemClient (which sends messages to the PhysicalSystemServer to do the same things as PhysicalSystems) if it does communicate over the network. It also creates a Scheduler and is respsonsible for asking it to start a run, and it handles the execution of other small tasks like calibrating the probes.
+ *Scheduler*: A class that handles the scheduling and execution of the pumptasks, as described in a given protocol. It is passed a PhysicalSystemsInterface instance from the ClientCLI and uses it to pump and measure pH-values as needed when executing the tasks.
+ *PhysicalSystemServer*: A class that works as a server, and which manages an PhysicalSystems instance (that connects to the ph-meter and pumpsystem). It listens to messages/commands from PhysicalSystemClient's, executes them, and replies with the result (e.g. the pH value of a given probe).
+ *PhysicalSystemInterface*: An interface describing the methods used by the PhysicalSystem class (see below). Both PhysicalSystem and PhysicalSystemClient implements the interface, so that the Scheduler and ClientCLI can work the same way, no matter if communication happens over the network or not.
+ *PhysicalSystems*: A wrapper for the two physical systems classes used in the program, the PH_Meter and PumpSystem. It serves as an interface for the two classes, only exposing the methods that are needed by the Scheduler and CLI. It creates an instace of a PH_Meter and PumpSystem. It implements the PhysicalSystemsInterface.
+ *PhysicalSystemClient*: Essentially works as a wrapper for the PhysicalSystems. It provides the same methods via its implementation of the PhysicalSystemInterface, but it does this by sending and recieving messages to and from the PhysicalSystemServer.
+ *PH_Meter*: A class that works as an interface for interaction with the ph-meter. It connects to the ph-meter over a serial port and allows for easy measuring of pH values.
+ *PumpSystem*: A class that works as an interface for interaction with the pump-system. It connects to the pump-system over a serial port and allows for easy pumping operations.

In addition to this there are some other helper classes:

+ The class *PumpTask* is used to store all the relevant data associated with a pump task.
+ The class *SerialCommands* is used to store information regarding commands given to the ph-meter, and results returned from the ph-meter.


** Interacting over the COM-port

Communication over the com-port is done using the python library (py)serial, and by creating a serial connection using serial.Serial. The communication protocols for the ph-meter and the pumps are described in their respective manuals.

Notably, it was found that it was necessary to make a short thread.sleep call of approximatly 0.5 seconds after a command is send, as otherwise any message comming from for example the ph-meter would not be detected.

** Network commiunication to enable use of multiple clients

As mentioned, PhysicalSystemClient's communicates with a PhysicalSystemServer over the network. This of course happens on localhost (but it could be generalized to enable communcation on wider networks), and works using the python implementation of the zmq library.

Communication is quite simple using this library, and works using a simplified version of message passing:
+ From the side of the server, the server listens for a message, recieves a message (from a client), and responds to the same client, and then begins listening again. The response is automaticly sent to the same client that send the original message.
+ From the side of the client, whenever it wants to execute a command, it sends a message to the server describing the desired command. It then awaits a response before continuing.

The messages from the client to the server is structured as a list, with the first element of the list (the header) being the command that needs to be executed (e.g. get_ph_values_of_selected_probes) and the other elements being parameters for the command (e.g. a JSON dump of the list ["F.0.1.13_1", "F.0.1.13_2"]). The reply will either be "Done", or another result, like a JSON dump of a list of pH values. The client will then decrypt the reply, and pass it on, most likely to the Scheduler.

** CLI

The CLI creates the instance of the PhysicalSystems that will also be used by the scheduler. It is important to not create multiple instances, as we cannot create multiple serial connections to the same device.

The CLI simply works as a while-true loop, where for each loop the user will be asked for a console input: Based on the input it will then execute the corresponding action and loop again.

** Scheduler

How the Scheduler fundamentaly works is quite simple, and is described below:

+ To start with, it recives an instance of PhysicalSystems which it will use to read ph-values and pump fluids.
+ It then loads the selected protocol:
  + It uses this to initialize the pumps used in the protocol. This ensures that the pumps have the correct settings.
  + Based on the protocol it also creates PumpTasks. They are put into a priority queue which is prioritized on the basis of the time-of-next-operation of the pump tasks.
+ Depending on the settings, it might execute a start-up step:
  + This step ensures that the pH values measured by all the probes used in the protocol is great than the assocaited start pH value of their pump tasks.
  + Each 30 seconds it checks the pH values of all the probes used in the protocol, and for all probes where the pH is less than the start pH value, it pumps. It continues until all pH probes measure a pH value greater than their associated start pH value.
+ It then handles the tasks in a loop until they are all done:
  + It looks at the pump tasks that have not finished yet, and selects the one that is scheduled to run first. It then waits until it is time to handle said task.
    + When a run is started, all tasks in the protocol are scheduled for the start of the run, and they will then be selected in the order they are found in the protocol -> row number 1/task number 1 will run first.
  + It then handles the tasks by first measuring the actual pH and comparing it to the expected pH:
    + It calculates the expected pH as the linear difference between the initial pH and the desired pH over time. So if the task time is 4 hours, and the initial and desired pH is 5 and 6 respectively, then the expected pH 2 hours into the run will be 5.5. 3 hours into the run it will be 5.75.
    + If, for some reason, the mv value cannot be measured using the probe, it will reschedule the task for 15 seconds later.
  + How it determines whether to pump or not depends on whether or not adaptive pumping is turned on:
    + In the case that adaptive pumping is off, if the pH is less than what is expected, it pumps.
    + If adaptive pumping is on, it tries to manage cases where the acid production of the samples becomes to much for a single pump to handle, by allowing for multiple pumpts:
      + If the current pH is below the expected pH *and* the current pH has *decreased* since last time it measured the pH (where it pumped n times), it will pump n+1 times.
      + If the current pH is below the expected pH *and* the current pH has *increased* since last time it measured the pH (where it pumped n times), it will look at how much the pH has increased since the pH measurements five times ago. If this increase has been to sharp, it will pump n-1 times, in an attempt to avoid overshooting the expected pH to much. If the increase has not been to sharp, it will pump n+1 times.
      + If the current pH is above the expected pH *and* the current pH is significantly above the expected pH, pump n/2 - 1 times, rounded down. Otherwise, pump n-1 times.
  + It records the data as well as whether it has pumped or not.
  + It then reschedules the pump task at the current time + the forced delay.
    + If this time-point is after the end of the task (the start time of the task + the step time), one of two things happen:
      1) If there is another task period in the protocol associated with the pump task, it will switch to the settings for that task period before rescheduling the task.
      2) If there are no other task period associated with the task, it will not reschedule the task, and thus it will not be selected again.
+ Finally, when all the tasks are done it will save the results to the folder of the program.

** PH_Meter

The communication to the pH-meter is over a serial port using the serial.Serial class.

It is only possible to request the readings of a module, not a specific probe, from the pH-meter. Thus when requesting the pH of probe "F.0.1.22_3", it will request all the mV values from "F.0.1.22", isolate the value associated with probe 3, and then calculate the pH and return this.

The protocol actually used by the ph-meter is a little weird, and I advice reading the manual for further informaton regarding this if necessary. In very basic terms, to measure the value of probe "F.0.1.22_3", it will send a command to the ph_meter requesting the values for the module "F.0.1.22" and then it will read the reply over the serial port. This will then be used for the later calculations. Here the wrapper class PhSerialCommand is used to store relevant information regarding a message that needs to be sent to the ph-meter (For example, request mV values from module "F.0.1.13"), and SerialReply to store relevant information recieved from the ph-meter (For example, the mV values of the probes connected to module "F.0.1.13").

The ph-meter protocol requires the use of checksums when sending and recieving messages from the ph-meter. Currently this is only used when a message is sent to the ph-meter.

The pH calculations are done on the basis of the mV readings from the pH probes and the calibration data. It is a simple linear fit between the two points (mv_at_low_ph_buffer, ph_of_low_ph_buffer) and (mv_at_high_ph_buffer, ph_of_high_ph_buffer). Thus if 100 mV was measured at pH 4, and 600 at pH 9, if the probe measures 300 mV it will be converted into a pH of 6.

** PumpSystem

The communication to the pump system is over a serial port using the serial.Serial class.

Before actually using the PumpSystem it is important to set up the pumps that needs to be used in the given protocol. This is done using the setup_pumps_used_in_protocol method. It ensures that there is connection to the pumps in the protocol and that these settings are correct, including that whenever a pump pumps, it pumps the desired amount of liquid.

This setup is based on both the settings file and the protocol.

An actual pump instruction consists of the message "{pump_id_of_pump} RUN", after which that pump will pump its set amount of liquid.

* Bonus

The serial ports found on the computer in the lab actually comes from a pci-to-serial board card. Using the ports therefore requires drivers. The drivers can be found here: https://www.startech.com/en-us/cards-adapters/pex2s953lp.

* References

[[https://www.syringepump.com/download/NE-500%20OEM%20Syringe%20Pump%20User%20Manual%20V3.9.pdf][Syringe Pump User Manual]]

Owner

Citation (CITATION.cff)

cff-version: 1.2.0
title: SNIPR-Gut pH-meter-interface
message: >-
  If you use this software, please cite it using the
  metadata from this file.
type: software
authors:
  - given-names: Jesper
    family-names: Samsø Birch
    email: jesper.birch3@gmail.com
repository-code: 'https://github.com/sniprbiome/ph-meter-interface'
abstract: >-
  CLI interface written in python for the consort d230
  ph-meter and a pump system made up of “NE-500 oem” pumps
  from syringepumps.com. CLI interface written in python for
  the consort d230 ph-meter and a pump system made up of
  “NE-500 oem” pumps from syringepumps.com.
license: LGPL-3.0
commit: b3aa9b05ccb446ed64f4886da77ebea7062120fe
version: '1.0'
date-released: '2025-06-05'

GitHub Events