oms-modbus FAQ
Short, direct answers to the questions we hear most often. Each one is answered in a sentence or two — follow the links for the full treatment.
What is oms-modbus?
A pure-Rust Modbus library with a unified client and server API for TCP, RTU, and ASCII — plus passive bus monitoring (WireTap). Dual-licensed MIT/Apache-2.0, on crates.io.
Which protocols does it support?
Modbus TCP (MBAP), RTU (CRC-16), and ASCII (LRC). All three ship full client and server support through one API.
Is it async or synchronous?
Async-only, built on tokio. Every client and server call is async/await.
Which function codes are implemented?
FC 01–06, 08 (Diagnostic), 15, 16, 22, and 23 — eleven codes covering the read/write workhorses plus masked-write and combined read/write operations. See the function-code reference.
Is FC 43 (Read Device ID) supported?
Not yet, and neither is FC 17 (Report Server ID). The function-code reference lists the complete, honest coverage.
What is WireTap?
A passive, read-only bus observer that attaches at the I/O boundary and records every frame — direction, raw bytes, and microsecond timestamps — without participating in the bus, like a logic analyzer clipped onto RS-485.
How do I capture bus traffic?
Create a BusCapture, pass it to ClientOptions via with_tap, run your I/O, then drain() it for PacketRecord frames with ISO 8601 timestamps. Start with the WireTap quick start.
Does it support auto-reconnect?
Yes — built-in, fixed-interval reconnection for both serial and TCP, including USB serial resilience.
Does it enforce the 3.5T silent interval?
Yes, at the protocol level for RTU and ASCII frames, per Modbus Serial Line Spec V1.02. Read why it matters.
Is the library panic-free?
It is a design goal: zero .unwrap() in production paths, poison-safe mutexes, and checked arithmetic.
What are the runtime dependencies?
Eight crates: tokio, tokio-serial, tokio-util, bytes, futures-util, async-trait, thiserror, and log — no transient dependencies.
What license is it under?
Dual MIT OR Apache-2.0, your choice. Hosted on GitHub and crates.io.
Can I run it on a Raspberry Pi or embedded Linux?
Yes — anywhere std and tokio run, over a serial port or TCP transport. The generic transport means no platform-specific code.
Is it no_std?
No. It requires the standard library and tokio, so it targets hosted environments rather than bare-metal microcontrollers.
How do I read holding registers?
client.read_holding_registers(slave, address, quantity).await — the slave id is explicit in every call.
Does it support server/slave mode?
Yes — RtuServer, TcpServer, and AsciiServer, backed by a SlaveStore that holds registers, coils, and discrete inputs.
What quantity limits apply?
FC 03/04 read at most 125 registers; FC 16 writes 123; FC 01/02 read 2000 coils; FC 15 writes 1968. Exceeding a limit is an error, not a warning — see the pitfalls article.
How are errors reported?
As a structured ModbusError with a short Display, a detailed detail(), and a machine-readable label(). Exception responses surface as ModbusError::Exception.
Is there a synchronous API?
No — async-only. If you need blocking I/O, tokio-modbus offers a sync feature and libmodbus is natively blocking. See the library comparison.
How mature is the project?
It is a v0.2.0 preview; the API may change based on feedback. The community is smaller than libmodbus or tokio-modbus — we are upfront about that in the comparison.
Question not answered? Open an issue on GitHub and we will add it here. oms-modbus is a transport-generic Modbus library in Rust — TCP, RTU, and ASCII through one API — used at OrangeHorse to build diagnostic tools for our Modbus-enabled sensors.