DEV Community: yujin hu

air=true Is Not a Diagnosis: A Testable Python Evidence Gate for Fluidics AI Agents

yujin hu — Tue, 25 Aug 2026 07:40:22 +0000

When an instrument reads air=true from a Modbus register, it is tempting to treat the bit as a fault verdict. That shortcut is unsafe.

The bit tells us what the sensor adapter observed. It does not tell us whether the event was expected during priming, caused by an empty source, produced by a suction-side leak, replayed from an old frame, or invalidated by the wrong tube setup.

This article shows a small, dependency-free Python pattern for keeping that distinction explicit.

The real engineering question

Consider two events that contain the same raw value:

{"air": true}

The first occurs 120 ms after a reagent switch. The pump is following a validated priming recipe, and the interface lasts 80 ms.

The second occurs during forward aspiration from a reagent bottle. It persists for 900 ms while the valve route is unchanged.

The raw observation is identical, but the engineering meaning is not. A controller therefore needs an evidence contract, not only a decoded bit.

At minimum, the contract should carry:

sample timestamp and monotonic sequence number;
communication, frame and sensor-readiness status;
configuration identity and tube-setup verification;
process phase and time since phase entry;
pump state, direction and valve route;
observed fluid state and event duration.

The AI layer may help generate the protocol adapter, analyse logs or explain a result. The final state transition should remain deterministic and testable.

A deliberately conservative state model

The reference implementation returns one of six verdicts:

Verdict	Interpretation	Example controller action
`LIQUID_CONFIRMED`	Current evidence supports a liquid observation	Continue under existing interlocks
`EXPECTED_INTERFACE`	A short interface is inside an allowed process window	Log and continue under phase rules
`POSSIBLE_AIR_INGRESS`	Air persists during forward aspiration	Pause fluid motion and diagnose
`SENSOR_SETUP_SUSPECT`	Configuration, installation or residue evidence is inconsistent	Pause and inspect setup
`COMMUNICATION_INVALID`	Frame, readiness, time or sequence evidence is invalid	Safe hold
`NEEDS_HUMAN_REVIEW`	Context is insufficient for a deterministic interpretation	Safe hold and review

Notice what is intentionally missing: there is no air_detected == emergency_stop rule.

Put data validity before process interpretation

The evaluator first rejects stale, malformed or replayed observations. Only then does it reason about physical context.

if (
    not evidence.communication_ok
    or not evidence.frame_valid
    or not evidence.sensor_ready
    or age_ms < 0
    or age_ms > policy.max_sample_age_ms
    or sequence_invalid
):
    return EvaluationResult(
        Verdict.COMMUNICATION_INVALID,
        "Communication, frame, readiness, timestamp, or sequence evidence is invalid",
        "SAFE_HOLD",
    )

This ordering prevents a common AI-agent failure mode: confidently explaining a number that should never have entered the decision path.

The next gate checks configuration identity, tube setup and residue evidence:

if (
    evidence.config_revision != evidence.expected_config_revision
    or not evidence.tube_setup_verified
    or evidence.residue_suspected
):
    return EvaluationResult(
        Verdict.SENSOR_SETUP_SUSPECT,
        "Configuration, tube setup, or residue evidence invalidates interpretation",
        "PAUSE_AND_INSPECT_SETUP",
    )

Only a validated observation reaches the process-phase rules.

Distinguish an expected interface from possible ingress

An air event may be expected during priming, reagent switching or rinsing, but only inside a validated time window and below a validated event duration.

expected_phase = evidence.phase in {
    ProcessPhase.PRIMING,
    ProcessPhase.REAGENT_SWITCH,
    ProcessPhase.RINSE,
}

if (
    expected_phase
    and evidence.phase_elapsed_ms <= policy.expected_interface_window_ms
    and evidence.event_duration_ms <= policy.max_expected_air_event_ms
):
    return EvaluationResult(
        Verdict.EXPECTED_INTERFACE,
        "The air event falls inside an allowed interface window",
        "LOG_AND_CONTINUE_UNDER_PHASE_RULES",
    )

By contrast, persistent air evidence during forward aspiration should trigger a different path:

if (
    evidence.phase is ProcessPhase.ASPIRATION
    and evidence.pump_running
    and evidence.pump_direction is PumpDirection.FORWARD
):
    return EvaluationResult(
        Verdict.POSSIBLE_AIR_INGRESS,
        "Persistent air evidence during aspiration requires source and suction-side checks",
        "PAUSE_FLUID_MOTION_AND_DIAGNOSE",
    )

The word possible matters. The signal still does not identify root cause. Diagnosis may require checking the source container, fittings, tubing, valve route, mounting, medium and recent maintenance history.

Make the boundary executable

The complete reference project includes nine regression tests. They cover:

normal liquid evidence;
an expected short interface;
possible air ingress during aspiration;
stale samples;
invalid frames;
configuration mismatch;
residue suspicion;
unknown physical state;
replayed or out-of-order sequences.

Run everything with standard Python 3.9+:

git clone https://github.com/blmdxiao/fluidics-bubble-evidence-gate.git
cd fluidics-bubble-evidence-gate
python3 -m unittest discover -s tests -v
python3 -m examples.evaluate_event

The repository is available here: Fluidics Bubble Evidence Gate on GitHub.

Where AI helps—and where it should stop

Claude Code, Codex, ChatGPT, Gemini or another coding agent can be useful for:

generating UART, TTL or Modbus adapter scaffolding;
producing test fixtures from a written evidence contract;
checking unit conversions and schema completeness;
clustering logs and proposing diagnostic hypotheses;
reviewing whether every state has an explicit safe action.

The model should not silently invent register definitions, validated limits or tube-specific thresholds. It should also not replace deterministic interlocks with a natural-language confidence score.

A useful division of labour is:

sensor/protocol adapter
        ↓
normalized evidence package
        ↓
deterministic evidence gate
        ↓
safe controller action + auditable log
        ↓
AI explanation or diagnostic assistance

Engineering limits

The timing values in the example are demonstrations, not release limits. Real values must be validated for tube material, wall thickness, inner diameter, medium, flow rate, mounting, sensor response and the instrument risk analysis.

For public detector specifications and application context, see the FOREACH ABD air-bubble detector.

The broader lesson is simple: a sensor bit is evidence, not a diagnosis. Giving an AI agent more context is useful, but putting an explicit, tested state contract between the agent and the hardware is what makes the workflow auditable.

An AI Agent Can Switch a Rotary Valve—But Only After These 7 Checks

yujin hu — Tue, 18 Aug 2026 12:11:09 +0000

An AI agent can generate a valve command in milliseconds. That does not mean the intended fluid path exists in the instrument.

In an IVD analyzer or laboratory-automation system, a successful register write proves only that software sent a value. It does not prove that the valve was homed, that the requested port is physically connected to the intended reagent, that the previous liquid has been displaced, or that the pressure is safe for switching.

That distinction matters as teams begin using ChatGPT, Codex, Claude Code, Gemini, DeepSeek, and other AI tools to generate control code, test sequences, and troubleshooting workflows.

This article proposes a bounded control pattern for a future AI-agent layer. It uses the FOREACH MRV3 product page as a concrete engineering reference, but FOREACH does not currently claim that the MRV3 contains autonomous AI control. The AI workflow below is a design recommendation, not a description of a shipping AI feature.

1. Resolve route intent to a physical port map

An agent should never act on a vague instruction such as switch to wash.

It needs a versioned route map that resolves the semantic intent to a physical port, destination, tube, and allowed sequence:

{
  "intent": "wash_to_waste",
  "valve_id": "V1",
  "requested_port": 12,
  "source": "wash_buffer_A",
  "destination": "waste_2",
  "map_revision": "fluidics-2026-08-18"
}

If the route-map revision in the controller does not match the instrument configuration, the safe action is to stop—not to guess.

2. Verify home and current position

Power-up reset is useful, but a supervisory controller still needs evidence that the expected reference sequence completed and that the reported position is credible.

Before switching, check at least:

the valve has completed its reset or homing sequence;
the current position is known;
the requested port is valid for the installed valve configuration;
the last movement did not end in a timeout or position fault.

The FOREACH MRV3 page lists automatic reset on power-up. In an agent-managed system, that event should become an explicit verified state—not an assumption hidden inside startup code.

3. Check fluid and wetted-material compatibility

The agent needs more than a list of port names. It needs fluid metadata: chemistry, concentration, temperature, cleaning requirements, and compatibility with every wetted material in the route.

For example, the MRV3 page lists PCTFE, zirconia ceramic, and sapphire among the wetted materials. An engineering database can use that information as an input, but compatibility still has to be evaluated for the actual formulation and operating conditions.

If fluid identity is unknown or its compatibility record is missing, the route should be unavailable to autonomous execution.

4. Budget internal volume, carryover, and flush volume

A route can be mechanically correct and analytically wrong.

Internal volume changes the amount of liquid retained in a path and therefore affects flush demand, mixing, and carryover risk. The MRV3 reference page lists different channel diameters and corresponding internal volumes, including 15.8 uL, 10 uL, and 2.9 uL configurations.

The controller should combine valve volume with tube volume and downstream cell volume, then require a validated displacement factor:

required_flush = retained_route_volume x validated_displacement_factor

The factor is not universal. It should come from instrument testing with the real fluid pair, tubing, flow rate, and acceptance criterion.

5. Match pressure, bore, and interface constraints

The command is unsafe if the requested route violates the operating envelope.

The agent should compare:

expected pressure against the permitted pressure range;
selected channel bore against required flow and pressure-drop limits;
connection type against the installed fittings;
pump behavior against the transient created by switching.

The official MRV3 page lists a 0.7 MPa pressure rating, multiple channel diameters, and both 1/4-28UNF and 6-40UNF interfaces. Those are configuration inputs, not values an AI model should infer from a photo or product family name.

6. Enforce a no-flow switching sequence

An agent should not issue a port change while the pump is still pressurizing the line unless the complete fluidic design explicitly permits it.

A conservative sequence is:

stop or decelerate the pump;
confirm pressure is below the switching threshold;
command the valve;
wait for verified position or timeout;
begin the validated flush sequence;
restart process flow only after postconditions pass.

The MRV3 page lists switching within two seconds per revolution and under 100 milliseconds for adjacent ports. These times can inform a timeout budget, but they do not replace instrument-level validation.

7. Require feedback, fault handling, and a safe fallback

The agent must distinguish three states:

requested: software asked for a position;
reported: the controller returned a value;
verified: the instrument satisfied the defined physical and analytical checks.

A compact command contract could look like this:

{
  "intent": "wash_to_waste",
  "requested_port": 12,
  "preconditions": {
    "pump_stopped": true,
    "pressure_kPa": 0,
    "route_map_current": true
  },
  "verified_state": {
    "homed": true,
    "reported_port": 12,
    "fault": null
  },
  "postcondition": "flush_then_measure"
}

The fallback should be deterministic: stop the pump, preserve the fault context, prevent retries beyond a defined limit, and require operator recovery when physical state cannot be verified.

A small software guardrail

AI can propose an action, but a deterministic function should decide whether the action is eligible for execution:

from dataclasses import dataclass

@dataclass
class ValveContext:
    homed: bool
    pump_stopped: bool
    pressure_kpa: float
    route_map_current: bool
    fluid_compatible: bool
    requested_port: int
    allowed_ports: set[int]


def may_switch(ctx: ValveContext, max_switch_pressure_kpa: float) -> bool:
    return all([
        ctx.homed,
        ctx.pump_stopped,
        ctx.pressure_kpa <= max_switch_pressure_kpa,
        ctx.route_map_current,
        ctx.fluid_compatible,
        ctx.requested_port in ctx.allowed_ports,
    ])

The important architecture choice is separation of concerns:

the AI layer interprets intent and proposes a plan;
deterministic guardrails validate eligibility;
the controller executes the command;
sensors and state feedback verify the result;
validated instrument logic decides whether processing can continue.

Product reality: what the reference valve actually provides

The FOREACH MRV3 ceramic multiport rotary valve is presented for fluid-path selection in automated analytical instruments. The official page lists 10-, 16-, and 24-channel options, several channel diameters and internal volumes, automatic power-up reset, optional drivers, and RS232/RS485 communication.

Those features make the product page a useful reference for discussing configuration-aware control. They do not, by themselves, turn a valve into an autonomous system. Safe operation still depends on the surrounding mechanics, electronics, firmware, tubing, fluids, sensors, test evidence, and application requirements.

The practical takeaway

The near-term value of an AI agent is not to bypass control engineering. It is to make the engineering state more explicit: route intent, configuration revision, compatibility evidence, carryover budget, interlocks, and recovery steps.

When those facts are machine-readable, AI can help generate test cases, review route plans, explain faults, and propose sequences. The final permission to move fluid should remain bounded by deterministic checks and verified physical state.

Disclosure: I am a member of the FOREACH team. The product facts in this article are paraphrased from the official MRV3 page linked above. The AI-agent architecture is an engineering proposal and is not a claim that the current product provides autonomous AI control.

Reference: FOREACH — MRV3 Ceramic Multiport Rotary Valve

Claude Code, Codex, or Gemini Can Suggest a Pump — But Never Skip These 5 Fluidic Checks

yujin hu — Mon, 17 Aug 2026 15:20:53 +0000

AI coding agents are becoming useful engineering assistants. Claude Code, Codex, and Gemini can read specifications, normalize tables, generate calculation scripts, and prepare comparison matrices much faster than a manual copy-and-paste workflow.

But a language model should not be the final authority for a microfluidic design.

If an agent confuses mL/min with μL/min, treats a free-flow pump rating as the actual operating point, or invents a missing material-compatibility value, the output can look convincing while being physically wrong.

The safer pattern is simple:

Let the LLM propose. Let deterministic code validate. Let an engineer approve.

The five-layer workflow

1. Convert the request into an explicit engineering schema

Do not start with: “Choose a pump for my analyzer.” Start with structured requirements that make missing data visible.

{
  "application": "automated reagent dispensing",
  "fluid": "aqueous buffer",
  "temperature_c": 23,
  "target_flow_ml_min": 12,
  "tubing_id_mm": 0.8,
  "tubing_length_mm": 650,
  "max_pressure_kpa": 80,
  "wetted_materials": ["PTFE", "PEEK"],
  "control": "PWM",
  "missing_fields": ["target_lifetime_cycles"]
}

An agent may help extract these fields from a requirements document, but it must not silently fill missing_fields with guesses.

2. Retrieve candidates, not conclusions

The retrieval layer should return candidate components and the evidence behind each field:

source datasheet and revision;
rated flow and the test conditions;
pressure range;
wetted materials;
connector geometry;
control interface;
temperature and lifetime limits.

Every number needs provenance. “The model remembers this value” is not provenance.

3. Run deterministic unit and range checks

Before any physics calculation, reject inconsistent units, nonphysical values, and missing constraints.

from dataclasses import dataclass

@dataclass
class FluidPathInput:
    flow_ml_min: float
    tube_id_mm: float
    tube_length_mm: float
    viscosity_pa_s: float
    max_pressure_kpa: float

def validate(x: FluidPathInput) -> list[str]:
    errors = []
    if not 0 < x.flow_ml_min <= 10_000:
        errors.append("flow is outside the configured engineering range")
    if not 0.05 <= x.tube_id_mm <= 20:
        errors.append("tube ID is missing or implausible")
    if x.tube_length_mm <= 0:
        errors.append("tube length must be positive")
    if x.viscosity_pa_s <= 0:
        errors.append("dynamic viscosity must be positive")
    if x.max_pressure_kpa <= 0:
        errors.append("pressure limit must be positive")
    return errors

These ranges are project configuration, not universal laws. The important point is that they are explicit, testable, version-controlled, and independent of the model’s prose.

4. Call a physics calculator as a tool

The agent should pass validated inputs to a deterministic calculator rather than estimate pressure loss in free-form text.

For laminar flow in a straight circular tube, the Hagen–Poiseuille relationship highlights an important sensitivity:

ΔP = 128 μ L Q / (π d⁴)

Because pressure drop scales with the inverse fourth power of internal diameter, changing a tube ID from 1.0 mm to 0.5 mm can increase the theoretical straight-tube pressure drop by 16× when the other variables are unchanged.

Real fluid paths also contain valves, fittings, bends, filters, probes, entrances, contractions, and possibly non-Newtonian fluids. The model must preserve those limitations instead of presenting one equation as a complete system model.

For a practical check, the FOREACH Fluid Resistance Calculator supports known-flow or known-pressure-drop modes, fluid properties, tube segments, local resistance, and Cv-based elements. It is useful for early engineering estimates—not a replacement for bench validation.

5. Require human approval before execution

The final report should separate facts, calculations, assumptions, and unresolved questions:

PASS  Units are consistent
PASS  Candidate pressure rating exceeds calculated steady-state loss
WARN  Startup pressure spike was not modeled
WARN  Material compatibility requires supplier confirmation
FAIL  Target lifetime is missing

Only after an engineer resolves every FAIL and accepts each documented WARN should the design proceed to procurement, prototype testing, or device control.

What AI agents are genuinely good at here

Used with these guardrails, AI tools can provide real leverage:

extract parameters from multiple datasheets;
normalize naming and units;
generate test matrices and Python notebooks;
identify missing requirements;
compare calculated results with logged bench data;
draft a traceable engineering summary;
prepare regression tests when the fluid path changes.

They are much less reliable as an unreviewed source of product limits, chemical compatibility, safety decisions, or “best component” claims.

A useful rule for engineering agents

Do not ask whether an AI agent can select a pump or valve. Ask whether the workflow can prove where every requirement, value, calculation, and approval came from.

That shift—from autonomous-sounding answers to traceable engineering evidence—is what makes an AI-assisted fluidic workflow useful.

Disclosure: I work with FOREACH, which develops microfluidic pumps, valves, sensors, tubing, fittings, and related components. The linked calculator is a free engineering resource from our website. Product selection and final operating limits should always be verified against the relevant datasheet and physical tests.

Why Fluid Carryover Remains After a Solenoid Valve Switch

yujin hu — Sun, 16 Aug 2026 13:42:40 +0000

FOREACH 6010 Series Solenoid Valve. Product image from the official FOREACH website.

In an IVD instrument, analytical system, or laboratory-automation platform, a solenoid valve can complete its mechanical motion long before the fluid path is actually clean. A valve may switch in milliseconds, yet the first packet of the next reagent can still contain a measurable amount of the previous fluid.

This is not automatically a valve failure. Carryover can remain in the valve chamber, fittings, manifold passages, probe, and nearby tubing. A useful troubleshooting approach is to separate three time scales:

the mechanical switching time of the valve;
the displacement time required for the new fluid to pass through the local path;
the slower decay caused by mixing, diffusion, adsorption, recirculation, and low-velocity zones.

The electrical command mainly controls the first time scale. Assay purity and wash performance are often governed by the other two.

A simple mixed-volume estimate

As an early engineering approximation, treat the valve chamber and adjacent short passages as one well-mixed volume, Vd. If the accumulated volume of new wash fluid is Vf, the remaining fraction of the old fluid can be approximated by:

C / C0 = exp(-Vf / Vd)

This is not a complete CFD model. It is a screening equation that converts a vague delay into a measurable flush-volume target.

To reduce the old-fluid concentration to 1%:

Vf ≈ 4.6 × Vd

To reduce it to 0.1%:

Vf ≈ 6.9 × Vd

For a 20 µL valve chamber, the ideal mixed-volume estimate gives approximately 92 µL for 1% residual and 138 µL for 0.1% residual. The volume of fittings, manifold channels, tubing, and probes must still be added.

Fast valve response does not mean a clean path

Consider a valve that responds in roughly tens of milliseconds. At a wash flow of 1 mL/min, passing 92 µL through the path requires about 5.5 seconds. In this example, the fluid-displacement time is far longer than the mechanical switching time.

This distinction explains a common bench observation: the valve and driver work correctly during an unloaded test, but the first sample or reagent packet remains unstable after the complete fluid path is installed.

During troubleshooting, record at least:

valve drive command and actual switching time;
pump speed or measured flow rate;
accumulated flush volume after the switch;
conductivity, absorbance, fluorescence, or another signal that reveals carryover.

A fixed delay alone is not a robust wash specification. When flow changes, the same delay corresponds to a different displaced volume.

Why real systems often need more wash volume

The well-mixed approximation is usually optimistic. Actual fluid paths can contain:

low-velocity regions inside valve cavities and fittings;
recirculation zones at steps, bends, and manifold intersections;
adsorption and desorption on flexible tubing or polymer surfaces;
trapped bubbles that create bypass flow;
fluids with different viscosity, density, or surface tension;
transient backflow caused by pump pulsation or pressure imbalance.

Therefore, 4.6 dead volumes should be treated as a theoretical starting point rather than a final cleaning requirement. A practical validation can test 1, 2, 4, 6, and 8 equivalent dead volumes, measure the residual signal at each point, and build an empirical decay curve.

What to check during valve selection

Port diameter and maximum pressure are not enough for a switching application. The design review should also include:

valve-chamber volume and internal passage geometry;
2-way or 3-way configuration and normally open or normally closed behavior;
diaphragm material and reagent compatibility;
threaded, barbed, or manifold interface;
operating pressure, backpressure, and possible negative-pressure aspiration;
response time, long energized periods, coil heating, and energy-saving drive requirements.

The official FOREACH 6010 Series Solenoid Valve page publishes the 1.4 mm orifice, 20 µL valve-chamber volume, pressure range, diaphragm options, response time, and interface choices used in the example above:

FOREACH 6010 Series Solenoid Valve — specifications and selection information

The purpose of referencing a product page is not to replace representative testing. It shows why valve-chamber volume belongs in the same selection table as pressure, material, interface, and response time.

A repeatable validation sequence

Estimate the total retained volume of the valve chamber, fittings, manifold, probe, and adjacent tubing.
Convert 1–8 equivalent volumes into actual flush volume and time at the expected flow rate.
Measure residual concentration with conductivity, color, fluorescence, absorbance, or the actual assay signal.
Repeat at different flow rates and backpressures.
Confirm the final setting under worst-case temperature, viscosity, assembly tolerance, aging, and contamination conditions.

Separating “the valve has switched” from “the fluid path has been displaced and cleaned” turns a vague software delay into an engineering requirement that can be calculated, measured, and verified.

Disclosure: This article was prepared by the FOREACH engineering team. The linked product page is an official FOREACH resource. The equations are intended for early engineering estimates; final designs require representative testing of the complete fluid path.

Why a Pump's Maximum Flow Is Not Its Operating Flow (with Python)

yujin hu — Thu, 13 Aug 2026 15:16:43 +0000

Choosing a pump from its maximum-flow number is an easy mistake to make.

That headline value is normally measured with little or no backpressure. At the other end of the curve, maximum pressure occurs near shutoff, where flow approaches zero. Once tubing, valves, filters, needles, and a fluidic chip are connected, the pump works somewhere between those two endpoints.

That real condition is the operating point: the intersection of the pump curve and the system curve.

This post builds a small, dependency-free Python model to estimate that intersection during early design.

1. Approximate the pump curve

Measured pressure-flow data is always preferable. But when a datasheet provides only maximum flow and shutoff pressure, a linear approximation is a useful first screen:

ΔP_pump(Q) = ΔP_max × (1 - Q / Q_max)

Q_max is the low-backpressure flow rate and ΔP_max is the pressure at approximately zero flow.

This is deliberately simple. A diaphragm, peristaltic, piston, or gear pump may have a nonlinear curve, and the curve can change with voltage, speed, fluid, and control mode.

2. Model the tube as a resistance

For fully developed laminar flow of an incompressible Newtonian liquid through a circular tube, Hagen-Poiseuille gives:

ΔP_system = R × Q
R = 128 μ L / (π D⁴)

The fourth-power dependence on inner diameter is the detail worth remembering. Changing the ID from 0.8 mm to 0.7 mm raises theoretical tube resistance by:

(0.8 / 0.7)⁴ ≈ 1.71

That is about 71% more resistance, before adding valves, filters, connectors, needles, bends, or manifolds.

3. Solve the intersection

Set the pressure available from the pump equal to the pressure required by the system:

ΔP_max × (1 - Q / Q_max) = R × Q

For this simplified linear case, the solution is direct:

Q = ΔP_max / (R + ΔP_max / Q_max)

Here is a compact implementation with explicit unit conversion:

from dataclasses import dataclass
from math import pi


@dataclass(frozen=True)
class Pump:
    max_flow_ml_min: float
    max_pressure_kpa: float


@dataclass(frozen=True)
class Tube:
    inner_diameter_mm: float
    length_m: float
    viscosity_mpa_s: float = 1.0


def operating_point(pump: Pump, tube: Tube) -> tuple[float, float]:
    q_max = pump.max_flow_ml_min * 1e-6 / 60.0  # m³/s
    p_max = pump.max_pressure_kpa * 1e3         # Pa
    diameter = tube.inner_diameter_mm * 1e-3    # m
    viscosity = tube.viscosity_mpa_s * 1e-3     # Pa·s

    resistance = (
        128.0 * viscosity * tube.length_m
        / (pi * diameter**4)
    )

    flow = p_max / (resistance + p_max / q_max)
    pressure = resistance * flow

    return flow * 60.0 * 1e6, pressure / 1e3

4. Run a practical example

Suppose the early design inputs are:

maximum flow: 120 mL/min;
maximum pressure: 80 kPa;
tube length: 1 m;
tube ID: 0.8 mm;
viscosity: 1 mPa·s.

pump = Pump(max_flow_ml_min=120.0, max_pressure_kpa=80.0)
tube = Tube(inner_diameter_mm=0.8, length_m=1.0)

flow, pressure = operating_point(pump, tube)
print(f"Operating flow: {flow:.2f} mL/min")
print(f"Pressure drop: {pressure:.2f} kPa")

Output:

Operating flow: 34.42 mL/min
Pressure drop: 57.06 kPa

The pump is advertised at 120 mL/min, but the estimated flow in this system is only about 34 mL/min.

Now change only the tube ID to 0.7 mm. The estimated operating flow falls again, to about 22.89 mL/min, while the pressure drop rises to about 64.74 kPa. A tolerance that looks small on a drawing can therefore move the actual operating point substantially.

5. What should be added next?

The single-tube model is a screening tool, not a system qualification. A realistic pressure budget may also include:

valves, filters, restrictors, and fittings;
sampling or dispensing needles;
microchannels and sudden contractions;
inlet/outlet pressure and elevation differences;
temperature-dependent viscosity;
pump-curve tolerance and tube-ID tolerance.

Extra care is needed for gases, bubbles, non-Newtonian fluids, two-phase flow, compliant tubing, and pulsatile pumping.

The full implementation, input validation, and tests are available in the GitHub repository.

For a quick independent check of circular-tube resistance and pressure drop, I also use the FOREACH Fluid Resistance and Pressure Drop Calculator.

Disclosure: I work with the FOREACH team that develops this calculator. Both the code and calculator are intended for early engineering estimates; measured pump curves and prototype validation should be used before design release.

The useful selection question is not "What is the pump's maximum flow?" It is: Where will this pump operate in my actual fluidic system?