In this system a Digi PortServer TS 4 MEI sits behind a site-to-site VPN. Serial port 1 feeds an XSPOC master radio. Serial port 2 feeds a FreeWave master radio over RS-232. That radio used to serve ClearSCADA and now has to serve Ignition, polling SCADAPack PLCs through FreeWave FGR2-C-U remote radios. The final configuration used the Digi's Industrial Automation (IA) Modbus TCP profile on port 2. With it, a generic Modbus client on the server read 10 registers instantly while Ignition 7.8 still showed null tags. The fix was a matter of addressing and driver module, not network plumbing. The sections below build the path one hop at a time, and each ends with the check that proves the hop before you move to the next.
Which hops does an Ignition Modbus poll cross to reach a SCADAPack?
Trace one read request from origin to the answering device. A failure at any hop looks the same from Ignition: a null or bad-quality tag. For that reason you verify from the far end back toward the master.
| Hop | Device | Medium / protocol | Addressing that selects the next hop |
|---|---|---|---|
| 1 | Ignition server (hosting site) | Ethernet, Modbus TCP or RTU-over-TCP | Digi IP address + TCP port |
| 2 | VPN tunnel | IP routed | Customer subnet route to the Digi |
| 3 | PortServer TS 4 MEI Ethernet side | TCP listener per port profile | TCP port maps to serial port 2 |
| 4 | PortServer serial port 2 | RS-232, Modbus RTU framing | Baud/parity/stop bits must match the radio |
| 5 | FreeWave master radio | RF point-to-multipoint | Transparent. It broadcasts the frame to all remotes. |
| 7 | SCADAPack PLC | Modbus RTU slave | RTU station address in the frame (the unit ID) |
The radio network is a shared broadcast medium. Every remote hears every request, and only the PLC whose station address matches the frame replies. That is why one Digi IP and one serial port can reach many PLCs. The TCP port picks the serial port. The Modbus unit ID picks the PLC.
Check: from the Ignition server, ping the Digi's IP across the VPN and open its web interface. If you cannot reach the web UI, stop and fix VPN routing before you touch any Modbus setting.
Which serial-port profile should port 2 run for Ignition?
A PortServer serial port runs one profile at a time. The profile decides what the server has to speak. The three candidates for this job behave differently:
| Port profile | What the server sees | What the server must send | Fit for Ignition |
|---|---|---|---|
| RealPort | A virtual COM port created by the RealPort driver installed on the host | Raw serial bytes through a serial-capable master | Suits a serial-native master such as the previous ClearSCADA setup. It requires a serial Modbus driver on the master side. |
| TCP sockets (raw) | A TCP listener on a port-specific number | Modbus RTU frames (with CRC) wrapped in TCP | Use Ignition's Modbus RTU-over-TCP mode. The Digi passes bytes through unchanged. |
| IA Modbus TCP | A Modbus TCP server, typically on port 502 | Standard Modbus TCP (MBAP header). The Digi converts to RTU on the serial side. | Use Ignition's plain Modbus TCP mode. This is the configuration that worked here. |
RealPort is the reason someone told the project to "request the COM port". The earlier master talked serial through a virtual COM port. If the rest of your fleet already runs Modbus TCP, reconfigure port 2 for TCP sockets or IA Modbus TCP and leave RealPort out of the Ignition path. Protocol mismatch is the most common fault in this setup. If Ignition sends Modbus TCP into a raw TCP-sockets port, the PLC receives an MBAP header with no CRC and discards it. If Ignition sends RTU-over-TCP into an IA Modbus TCP port, the Digi rejects the frame. Either way the request goes out and nothing comes back.
Check: in the Digi web UI, confirm port 2 shows the intended profile. Record the TCP port it listens on. For IA Modbus TCP that is the Modbus TCP port you entered, 502 in this installation. For TCP sockets, read the raw TCP port number from the port's profile page. Leave port 1 on its existing profile so the XSPOC master is not disturbed.
Is the radio link answering before the Digi is in the path?
Early in this project, traffic left the Digi but no responses came back. Before blaming the gateway, remove it from the path. Test the RF segment and the PLCs directly.
- Disconnect the Digi's port 2 cable from the FreeWave master radio.
- Connect a laptop's RS-232 port, or a USB-serial adapter, to the radio's data port. Use the same cable and pinout the Digi used.
- Run a Modbus master test tool such as Modbus Poll in RTU mode. Set baud rate, data bits, parity, and stop bits to the radio's data-port settings. These must also match the SCADAPack serial port configured as Modbus RTU slave.
- Enter one SCADAPack's station address as the slave ID. Read a small block of holding registers.
- Raise the response timeout well above a wired-link value. Radio round-trip time includes key-up, over-air transfer, and the remote's turnaround. A short timeout reports a healthy link as dead.
- Repeat for each field PLC's station address.
Check: every PLC returns register data with its own station address. If one does not respond, the fault sits in that remote radio, its cabling, or that PLC's Modbus slave configuration. The Digi and Ignition play no part in it yet.
How does the Digi pick the serial port and the PLC from one static IP?
Reconnect port 2 to the radio and set its serial parameters to exactly what the laptop test proved. Then map the addressing layers:
| Layer | Field | Selects | Where you set it |
|---|---|---|---|
| IP | Digi IP address | The PortServer at the customer site | Ignition device connection, VPN route |
| TCP | Destination port | Serial port 2 (and its profile) | Digi port profile; Ignition device port setting |
| Modbus | Unit ID (MBAP) or slave address (RTU frame) | The individual SCADAPack on the radio network | Ignition unit ID per device or per tag; SCADAPack station address |
| Modbus | Function code + register address | The data point inside the PLC | Ignition tag address |
In IA Modbus TCP mode, the Digi strips the MBAP header, builds an RTU frame, and uses the unit ID as the RTU slave address. It then appends CRC and transmits on port 2. In TCP-sockets mode the Digi does none of this. Ignition's RTU-over-TCP mode must build the full RTU frame, including the slave address and CRC. Both modes reach many PLCs through one IP and one TCP port. The unit ID is the discriminator.
Check: the Digi's port diagnostics or statistics should show both transmit and receive byte counters rising while a master polls. If transmit rises and receive stays flat, the serial settings, cable, or unit ID are wrong.
Does the Digi return data to a generic Modbus TCP client over the VPN?
Isolate the Digi from Ignition next. In this installation, the operators installed Modbus Poll on the hosting server. They pointed it at the Digi's IP on port 502 in Modbus TCP mode and requested 10 registers, and the data returned immediately. That result proves hops 1 through 7 end to end: VPN, Digi profile, serial settings, radio, and PLC. It also proves the Digi translates Modbus TCP to RTU correctly.
Note which unit ID the test tool used. Most Modbus test clients default to slave/unit ID 1. A successful read with the default tells you the target PLC answers at station address 1. It says nothing about what Ignition sends.
Check: record the working test parameters: IP, port, unit ID, function code, start address, and count. Ignition must reproduce these exactly.
Why does Ignition show null tags when the Digi reports good communications?
This is the state the installation reached. The Digi showed healthy communications, the Ignition device showed connected, and every tag read null. A connected device in Ignition only means the TCP session to the Digi is open. It says nothing about Modbus responses from the PLCs. Work the causes in this order:
| Symptom | Likely cause | Decisive test / fix |
|---|---|---|
| Requests go out, no responses come in | Serial parameter mismatch, wrong cable/pinout, or wrong protocol mode for the port profile | Laptop test on the radio (above); match the Ignition mode to the port profile |
| Device connected, all tags null; test tool reads fine | Ignition sending unit ID 0 while the test tool sends 1 | Set the unit ID explicitly in Ignition to the SCADAPack station address |
| Tags read wrong values or off by one register | Zero-based vs one-based addressing mismatch between tool and driver | Compare against the test tool's addressing convention; toggle the driver's zero-based addressing option |
| Intermittent nulls or timeouts on some PLCs | Request timeout shorter than radio round trip; multiple concurrent requests on one serial port | Raise the device timeout; limit the device to one outstanding request |
| Addressing verified correct, still null | Driver module defect in the installed Ignition version | Update the module that provides the Modbus driver (in this case, on Ignition 7.8, the OPC-UA module) |
Unit ID 0. Ignition's Modbus driver sends unit ID 0 unless you specify another value. On Modbus TCP that is a legitimate value. Once the Digi converts it to an RTU frame, however, address 0 is the Modbus RTU broadcast address. Every SCADAPack on the radio network accepts a broadcast write, and none of them replies. A broadcast read therefore gets no answer, and the tag reads null. The Digi still reports healthy communications because it transmitted successfully. Set the unit ID in Ignition to each PLC's station address. If one Ignition device polls several PLCs through the same Digi port, map a unit ID per address range or per tag rather than relying on a device-wide default. Check the Ignition user manual for your version for the exact unit-ID syntax.
Driver module. In this installation, the RTU addressing was already correct and tags still read null on Ignition 7.8. They began returning data only after Inductive Automation supplied an updated OPC-UA module. Ignition 7.x ships its built-in device drivers, Modbus included, inside the OPC-UA module. A driver-level defect therefore shows up as bad reads even when the device configuration is correct. If unit ID and addressing match the working test-tool read exactly, check the installed OPC-UA module version in the Gateway's module configuration. Obtain the current module for your Ignition version through Inductive Automation support. A third-party Modbus OPC server is the fallback, but a module update resolved it here without adding another driver layer.
Check: create one test tag with the same function code, register, and unit ID as the successful Modbus Poll read. Confirm it shows good quality and the same value before you build the full tag set.
What must change on port 2 before ClearSCADA hands over the radio?
A Modbus RTU radio network tolerates exactly one master. If ClearSCADA still polls through RealPort while Ignition polls through the same radio, their requests collide over the air. Responses then arrive at the wrong master or corrupt each other. Changing port 2's profile from RealPort to IA Modbus TCP or TCP sockets also cuts off any RealPort COM-port session still bound to that port.
- Disable the ClearSCADA channel that uses port 2 so it stops polling before you change the profile.
- Change only port 2's profile. Port 1 carries the XSPOC master radio and keeps its current configuration.
- Confirm the RealPort virtual COM port for port 2 on any host no longer holds the port open.
- Bring the Ignition device online with its timeout sized for radio latency and a single outstanding request.
Check: watch the Digi port 2 counters with Ignition disabled. They must stay flat, which proves no other master is still transmitting. Then enable Ignition and confirm the counters move only at its poll rate.
How do you prove the full Ignition-to-SCADAPack path end to end?
- Ping the Digi from the Ignition server across the VPN and confirm the web UI loads.
- Confirm port 2 profile, serial parameters, and listening TCP port in the Digi UI. Confirm port 1 is unchanged and the XSPOC master still polls.
- From the server, read each PLC with Modbus Poll using the Digi IP, the port-2 TCP port, and each station address as the unit ID.
- In Ignition, confirm the device mode matches the port profile: Modbus TCP for IA Modbus TCP, RTU-over-TCP for TCP sockets.
- Confirm every Ignition tag carries an explicit unit ID matching its PLC's station address, with no unit ID 0 on read tags.
- Compare one register per PLC between Modbus Poll and Ignition. The values must match, with good quality.
- Leave Ignition polling at the production scan rate and watch the Digi port 2 transmit and receive counters. Both must rise together, and receive errors must stay flat.
- Force a known value change in one SCADAPack register and confirm it appears in Ignition within one scan cycle plus radio round trip.
FAQ
What happens if Ignition sends unit ID 0 through a Digi PortServer to a Modbus RTU slave?
The Digi converts it into an RTU frame addressed to 0, which is the Modbus RTU broadcast address. No slave replies to a broadcast, so reads time out and tags show null while the Digi still reports good communications. Set the unit ID in Ignition to the PLC's station address.
What happens if I switch a PortServer port from RealPort to IA Modbus TCP?
The virtual COM port on the RealPort host stops working for that serial port. The port instead accepts Modbus TCP connections on the configured TCP port (502 here) and converts them to Modbus RTU. Stop the old serial master first so two masters do not poll the same radio.
What happens if Ignition uses Modbus TCP mode against a Digi port set to TCP sockets?
The Digi passes the MBAP-framed request unchanged to the serial line. The SCADAPack sees an invalid RTU frame with no valid CRC and ignores it. Use Ignition's RTU-over-TCP mode for a TCP-sockets port, or change the port to IA Modbus TCP.
How do I poll multiple SCADAPack PLCs through one Digi serial port and one IP?
Point every Ignition device or tag group at the same Digi IP and TCP port, and give each one a unique unit ID equal to its PLC's Modbus station address. The radio network delivers the request to all remotes, and only the PLC with the matching address replies.