Most of the Modbus protocol is about moving numbers: read this register, write that coil. Function code 43 is different. Instead of process data, it asks a device to describe itself - who made it, what model it is, and what firmware it runs - as human-readable text strings. This guide explains how the encapsulated FC43 read works, why it lives under a sub-function called MEI Type 14, why support for it is optional and uneven across vendors, and how commissioning tools lean on it to recognize a device before anyone has loaded a register map.
FC43 Device Identification in one line: Modbus function code 43 with MEI type 14 is the Read Device Identification command, an encapsulated request that returns a device's identity as a set of text objects - vendor name, product code, and major-minor revision at minimum. It lets a client discover what a device is without reading process registers, but it is an optional part of the specification, so many field devices do not implement it.
Function code 43 is the Encapsulated Interface Transport, a general-purpose wrapper that carries a different kind of message inside a normal Modbus frame. What distinguishes one FC43 use from another is the MEI type, a byte that immediately follows the function code. MEI type 14 is Read Device Identification; other MEI types exist for other encapsulated services. So a device-identification read on the wire is really function code 43 followed by MEI type 14, and a client that wants identity data must send exactly that pairing rather than a bare function code.
The response comes back not as raw registers but as a list of identification objects, each with a numeric object ID and an ASCII string value. The specification defines a small set of standard objects: object 0 is the vendor name, object 1 is the product code, and object 2 is the major and minor revision, and these three are the mandatory basic block. Higher-numbered objects such as vendor URL, product name, model name, and application name are optional extensions. Because the objects are strings of varying length, the response also carries a conformity level indicating which categories the device supports and a more-follows flag with a next-object-id, so a client can page through a long identification block across several requests when it does not all fit in one frame.
The request itself specifies a read-device-id code that selects how much to return - just the basic block, the regular block, the extended block, or one specific object. That lets a lightweight tool ask only for vendor and product code while a more thorough discovery pass requests everything the device is willing to expose. The whole exchange rides on top of ordinary Modbus RTU, ASCII, or TCP framing, so it needs no special transport, only a device and a client that both agree to speak MEI type 14.
Read Device Identification is a conformance option, not a core requirement, and that single fact shapes everything about how it behaves in the field. A perfectly compliant Modbus device can implement holding registers, coils, and the common read and write function codes while never supporting function code 43 at all. When a client sends the request to such a device, the device answers with an illegal-function exception rather than an identity block. Discovery tools therefore have to treat an exception as a normal outcome and fall back to other methods rather than concluding the device is broken.
Even among devices that do implement it, support is uneven in scope. Some return only the mandatory basic block and stop there; others populate the full extended set with model names and application strings. The text values are also entirely up to the manufacturer, so the vendor-name and product-code strings vary in format, spelling, and abbreviation from one maker to the next. Two devices from the same vendor may format their product codes differently across firmware generations. This variability means a tool can use FC43 as a strong hint about identity but rarely as a rigid key, because the strings were written for humans to read, not for software to match exactly.
The practical consequence is that FC43 is best understood as a helpful convenience layered on top of a protocol that predates it, rather than a guaranteed capability. Where it works, it is genuinely useful; where it does not, the surrounding tooling must degrade gracefully. Serial gateways and protocol converters add another wrinkle, since a gateway may or may not pass an encapsulated request through to the far-end device, so a successful identification read against a gateway sometimes describes the gateway rather than the instrument behind it.
The reason FC43 matters for people building monitoring systems is that it addresses one of the most tedious steps in Modbus commissioning: figuring out what is actually on the wire. A raw Modbus device is anonymous. Its registers are just numbered slots with no names, no units, and no hint of what they mean until someone loads a register map that describes them. Before that map exists, a technician is often reading a manual, matching a part number, and manually associating a device with the right template. Read Device Identification short-circuits that when it is supported, because a commissioning tool can query vendor name and product code and immediately propose the correct template.
In a cloud SCADA workflow this is the difference between a device that self-describes and one a technician has to catalog by hand. When a Merobix edge gateway or connector first reaches a Modbus device across a field link, attempting an FC43 read is a cheap, low-risk probe: if the device answers, the platform can suggest a matching driver profile and register map, pre-fill the vendor and model, and let the person confirm rather than type. That speeds up onboarding a new well pad or metering skid, where there may be dozens of instruments to bring online and every avoided lookup saves time in the field.
Because the read is optional, the platform cannot depend on it, and good tooling never does. The identity probe is an accelerator, not a gate. When a device returns nothing, the operator selects the template manually, exactly as they would have anyway. When it does return a clean vendor and product code, the tool has turned an anonymous serial address into a recognized device with a proposed map attached, which is precisely the kind of small friction reduction that adds up across a large distributed fleet of oil and gas assets.
No. Read Device Identification under MEI type 14 is defined as an optional conformance feature, not a mandatory function code. A fully compliant Modbus device can support registers and coils while returning an illegal-function exception to an FC43 request. Any tool that uses it must handle that exception as a normal, expected response rather than an error.
At minimum it returns the mandatory basic block: vendor name, product code, and a major-minor revision string. Devices that implement the regular or extended blocks may also return vendor URL, product name, model name, and application name. Each item is an ASCII string tied to a numeric object ID, and the exact text and formatting are chosen by the manufacturer.
You can use it as a strong hint, but not as a strict machine key. The identification strings are free-form text written by each manufacturer, so formatting and abbreviations vary between vendors and even between firmware versions of the same product. Discovery tools typically use the vendor and product code to propose a matching template that a person confirms, rather than to match devices exactly and automatically.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.