Ignition SCADA Modbus Driver Testing Guide

Ignition, from Inductive Automation, takes a different architectural approach to Modbus than most SCADA platforms: instead of a proprietary point database with bolted-on protocol drivers, every device connection — Modbus, Allen-Bradley, Siemens, Omron — goes through a central OPC UA server that ships as a core part of the platform. This guide covers how Ignition's Modbus TCP/RTU driver is configured, how address mapping turns raw registers into usable tags, and how to validate the whole chain against a Modbus simulator before real field devices are in the loop.

Ignition's OPC UA Architecture

Every Ignition Gateway includes an OPC UA server module as a core, included component — not a separately licensed add-on. That server hosts a suite of built-in device drivers, and Modbus has been one of them since 2010, when Inductive Automation added a free Modbus TCP/IP driver to the Ignition OPC-UA server. The same module bundles drivers for Allen-Bradley, Siemens, and Omron PLCs, all configured through the same Device Connections interface and all ultimately exposed as OPC UA tags inside Ignition's Tag Browser.

Connection Type	What It Connects To	Module Requirement
Modbus TCP	Native Modbus TCP/IP devices over Ethernet	Core OPC UA module (no extra purchase)
Modbus RTU (native serial)	Serial RS-232/RS-485 devices via a physical or USB COM port on the Gateway host	Core module from 8.1.20+; Serial Support Gateway module required before 8.1.20
Modbus RTU over TCP	Serial RTU devices reached through a fieldbus/terminal server gateway	Core OPC UA module (no extra purchase)

Setting Up a Modbus TCP Device Connection

1. In the Ignition Gateway webpage, go to Config > OPC UA > Device Connections
2. Click Create new device and select the Modbus TCP driver type
3. Give the device a descriptive name and enter its IP address (default Modbus port is 502, editable if the target uses a non-standard port)
4. Save and confirm the connection status shows Connected on the Device Connections overview page before moving on to address mapping

The device connection settings also expose timing parameters worth tuning before commissioning rather than after: request timeout (how long Ignition waits for a slave response before flagging a fault), the polling rate for each address group, and the maximum number of registers requested per transaction. Leaving these at defaults is fine for a first test against a simulator, but on a real RS-485 segment with multiple slow slaves, an aggressive polling rate or an overly long per-request register count is a common cause of intermittent timeouts that look like a wiring problem but are actually a configuration one.

Modbus RTU Serial Setup in Ignition

For devices on a physical serial bus rather than Ethernet:

• Choose the Modbus RTU driver instead of Modbus TCP when creating the device connection
• Select the serial port under the connectivity settings — for example COM3 on a Windows Gateway host, or the equivalent /dev/tty device on Linux
• Set baud rate, parity, data bits, and stop bits to match the target device (commonly 9600 8N1 or 8E1, but always confirm against the device manual)
• Set the unit ID (slave address) for each device sharing the RS-485 bus

Version matters for serial support: before Ignition 8.1.20, native serial Modbus RTU required installing the separate Serial Support Gateway module. From 8.1.20 onward, the native serial libraries ship as part of the core platform, so RTU over a physical COM port works without installing anything extra. If your Gateway host has no physical serial port at all — common on virtualized or cloud-hosted Gateways — the alternative is Modbus RTU over TCP, where Ignition sends RTU-framed requests over a TCP socket to a serial-to-Ethernet fieldbus gateway that does the actual RS-485 conversion in the field.

Address Mapping and Tag Configuration

Once a device connection is up, register addresses still need to become usable Ignition tags:

1. Open the device's More > Addresses page from the Device Connections list
2. Use Ignition's Modbus Address Map to enter a block of addresses at once — for example holding registers 40001–40020 — rather than defining each register individually one at a time
3. The driver expands the block into individually addressable OPC items and lists them in the OPC browser
4. Open the Ignition Designer, browse to the device under the OPC Quick Client or OPC Browser, and drag the addresses you need into the Tag Browser to create bound tags
5. Set each tag's data type (Boolean for coils/discrete inputs, Int16/Int32/Float for holding/input registers) to match how the source device actually packs its data

This block-based address mapping is one of the more practical differences from a driver like the FX5U's Predefined Protocol Support (covered in our Mitsubishi PLC Modbus setup guide) — Ignition's approach front-loads the register layout definition once per device, rather than defining each polled request individually in ladder configuration.

Modbus Function Codes and Data Types in Ignition's Address Map

Ignition's address mapping syntax ties directly to standard Modbus function codes, and getting the type right matters more than the raw address:

Modbus Data Type	Function Codes	Typical Ignition Tag Data Type
Coils	FC01 (read), FC05/FC15 (write)	Boolean
Discrete Inputs	FC02 (read only)	Boolean
Holding Registers	FC03 (read), FC06/FC16 (write)	Int16, Int32, Float (device-dependent packing)
Input Registers	FC04 (read only)	Int16, Int32, Float (device-dependent packing)

Holding and input registers are the ones most likely to cause data problems, because a single 32-bit float or long integer spans two consecutive 16-bit registers, and the order those two registers combine in (high word first vs low word first) isn't standardized across manufacturers. Ignition's address map lets you specify the data type per mapped point, but it can't know the device's actual word order for you — that has to come from the device's Modbus register documentation, or from testing against known values.

Ignition's Centralized Tag Model vs Per-Screen Driver Configuration

One architectural difference worth calling out for engineers moving from a more traditional SCADA package: in Ignition, a Modbus device connection and its address mapping are defined once, centrally, in the Gateway — not per-screen or per-project. Any project, Vision or Perspective screen, script, or historian binding on that Gateway can reference the same underlying OPC UA tag once it's created, without redefining the Modbus address anywhere else. This is a different model from HMI-centric platforms like TIA Portal's Comfort Panels (covered in our WinCC SCADA Modbus integration guide), where the Modbus connection typically lives inside a single panel project rather than a shared, Gateway-wide tag namespace serving multiple client applications at once.

Testing Ignition Modbus Communication Against a Simulator

1. Run ModbusSimulator in Slave mode — TCP for a network-based test, or RTU over a virtual/USB COM port if you're validating a serial device connection
2. Load the target device's real register map into the simulator (holding register ranges, coil counts, data types) so the values line up with what production hardware will return
3. Create the Ignition device connection pointing at the simulator's IP/port (TCP) or COM port/baud rate (RTU)
4. Build the address mapping and drag the resulting OPC items into the Tag Browser exactly as you would for the real device
5. Force known test values in the simulator and confirm the Ignition tags update correctly, including scaling and any byte-order handling on multi-register values
6. Stop the simulator mid-poll and verify the tags' quality status correctly flags a communication fault instead of silently holding stale values

This is the same validation discipline described in our SCADA Modbus simulator testing guide — get the device connection, address mapping, and data types right against a simulated slave, so the only new variable on commissioning day is the physical wiring, not the tag configuration.

Common Ignition Modbus Issues

Device connection shows "Disconnected" or "Fault" status

• Confirm the target device (or simulator) is listening on the configured IP/port for TCP, or that the COM port and baud rate actually match for RTU
• For RTU over TCP through a fieldbus gateway, verify the gateway itself is reachable and correctly forwarding to the serial side

Tags show good quality but the values are wrong or scaled incorrectly

• Check the address mapping's data type against the device's actual register format — a 32-bit float read as two separate Int16s (or vice versa) produces plausible-looking but wrong numbers
• Verify byte/word order on multi-register values — see our byte order guide for common patterns

Modbus RTU device connection won't come up on an older Ignition Gateway

• If running a version before 8.1.20, confirm the Serial Support Gateway module is installed — native serial libraries weren't bundled into the core platform until that release

Address mapping block doesn't generate the expected number of tags

• Double check the starting address and register count in the block definition — an off-by-one on the starting address is the most common cause of a mapping that's shifted or short by one register

Intermittent timeouts that look like a wiring fault

• Check the device connection's request timeout, polling rate, and max registers-per-request settings before troubleshooting cabling — an aggressive polling interval against a slow slave on a shared RS-485 segment often masquerades as a hardware problem

Frequently Asked Questions