Modbus FC17 (Report Server ID)

Back to Blog

What FC17 Reports

Function code 17 sends no data in the request beyond the slave address and the code. The device replies with a byte count, a server ID whose format is defined by the device, a run-indicator byte that is on or off depending on whether the device is running, and then any additional device-specific data the vendor chooses to include. Because the ID and the extra data are device-defined, the reply is only fully meaningful with the device's documentation in hand.

The one field with a fixed meaning is the run indicator, which tells you whether the device considers itself running. That single bit of universal information, plus a quick confirmation that something answers at the address, is the practical value of FC17. It is a serial-line command in the same family as the framing described in the Modbus TCP vs RTU comparison, and it does not touch the register or coil tables.

FC17 Versus FC43 Device Identification

Modbus later added function code 43 with a device-identification subfunction that returns structured, standardized fields such as vendor name, product code, and revision. That structured form is portable across vendors, whereas FC17's server ID is device-defined and inconsistent. Where a device supports FC43, it is the better choice for reliable identification, as covered in the Modbus FC43 device identification reference.

FC17 remains common on legacy serial equipment and stays useful as a lightweight liveness and run-status check even where FC43 exists. If a device rejects FC17 with an illegal function exception, it simply does not implement the code, which is entirely allowed since many function codes are optional. The general meaning of that rejection is in the Modbus exception code reference.

The Exchange on the Wire

The request is minimal: the server address, the byte 0x11, and the CRC. The reply is where the structure lives, such as it is:

Field	Content
Server address	Echoed address
Function code	0x11
Byte count	Length of the data that follows
Server ID	Device-defined identifier bytes
Run indicator	0xFF for on, 0x00 for off
Additional data	Optional, device-defined

Decoding a capture is straightforward until the device-defined parts: after the byte count, you cannot know where the server ID ends and the additional data begins without the vendor's documentation, because the specification fixes only that a run indicator of 0xFF means on and 0x00 means off. A practical trick when documentation is missing: capture the reply in both run states, and whichever byte flips between 0xFF and 0x00 is the run indicator - the ID is what precedes it.

FC17 as a Commissioning Liveness Probe

Because the request carries no register addresses or counts, FC17 cannot fail for configuration reasons the way a data read can, which makes it a clean liveness probe during commissioning: if the device replies at all, the address, baud rate, parity, and wiring are proven in one exchange, before you know anything about its register map. During a station bring-up it is a reasonable first poll for walking the address range and inventorying what answers. Two caveats apply. An illegal-function exception still proves liveness - the device heard you and answered, it just lacks the code - so treat that as a success for probing purposes. And a silent address proves little on its own, since a missing function code and a wiring fault produce the same silence when combined with other problems. Once the devices are proven alive, the polling design that follows is the subject of the Modbus-to-cloud connection guide.

Serial Only: Gateways and Native TCP Devices

FC17 is defined as a serial-line function, and that has practical consequences in mixed networks. A native Modbus TCP device typically does not implement it, so a poll that works on the RS-485 side of a gateway may draw an illegal-function exception when aimed at a TCP-only target. Gateways themselves vary: some pass any function code through to the serial side transparently, in which case FC17 reaches the end device and works, while others whitelist only the data-access codes and reject everything else at the gateway itself. An FC17 failure through a gateway therefore indicts the gateway's forwarding rules as much as the end device. For identifying devices across a routed, mixed network, the structured identification function is the portable path; FC17 is best treated as a tool for the serial segment you are physically working on.

Run Status Semantics: Trust but Verify

The run indicator's meaning is fixed only at the level of on versus off; what running means is the vendor's choice. A PLC may report its program mode, a simpler device may report merely that it is powered and answering, and a drive might report whether its output is active. Treat the run indicator as a hint to verify against the device manual, never as a universal machine state, and do not build control or alarm logic on it - status used for decisions belongs in documented registers polled with the ordinary data functions. Where a fleet mixes vendors, a useful convention is to log each device's FC17 reply during commissioning as documentation of what that model reports, then rely on mapped status registers for operations from that point on.

Frequently Asked Questions