The CNiTH-i8DH33-5-EIT supplied humidity and temperature values to Ignition after the device was configured for Modbus TCP, the driver was set to one holding-register request at a time, zero-based addressing was selected, and unit ID 1 was used. The controller’s embedded Ethernet web page confirmed browser access, but that alone did not establish which Modbus mode or register addressing Ignition needed.
Which network path carries the readings into Ignition?
Trace the request from Ignition to the controller before editing tag paths. A browser request reaches the device’s web interface and displays live readings; an OPC tag request instead goes from Ignition’s Modbus driver over the Ethernet connection to the controller’s Modbus service. The readings only appear in an OPC tag when the driver mode, unit ID, register function, address convention, and request grouping match the device configuration.
For this installation, the working driver was Modbus TCP, not Modbus RTU over TCP, even though the controller communication manual described RTU transmission mode. Treat the manual’s wording as a reason to test the RTU-over-TCP option, not proof that it is the option the Ignition driver must use. The actual successful read is the deciding result.
| Path or observation | What it establishes | What it does not establish |
|---|---|---|
| Browser displays live values | The web interface can be reached over the device’s Ethernet connection. | That Ignition is using the right Modbus mode or register request. |
| Ignition device status is connected | The driver reports a connection. | That a particular register read is valid. |
| OPC tag returns a value with good quality | The driver has obtained a usable register value for that tag. | That the value has the intended engineering meaning; compare it with the device display. |
Before proceeding, confirm the browser still displays current readings and record the Ignition device’s connection state separately from each tag’s value and quality.
Which Modbus mode should the device and driver use?
Configure the controller’s panel communication settings for Modbus operation, then select Modbus TCP in the Ignition driver. The successful installation used this combination; its earlier RTU-over-TCP configuration did not produce valid reads. Do not infer the transport mode from the words “RTU transmission mode” alone: RTU describes the Modbus message framing, while an Ethernet gateway or embedded server can expose communication through a TCP connection. A driver setting must match the device’s actual service and framing expectations.
In the reported setup, changing the Ignition driver to Modbus TCP produced a value using the item path [eip885b]1.HR27. The `1.` component was part of the successful path, and the final working configuration used unit ID 1 rather than the default 0. Preserve the actual device name configured in Ignition; `eip885b` is the installation’s device name, not a universal identifier.
After selecting Modbus TCP and setting the controller mode, check that Ignition still reports the device connected, then test one register before building more tags. A connected status is only a transport-level clue; the register read is the next proof point.
How should you interpret the register numbers and function codes?
Use the device’s register map and its stated function codes to identify the data type and address. The manual material cited for this controller lists function code 03 for holding registers and function code 04 for input registers. The final working configuration used a holding-register item path, so do not change it to an input-register path without confirming the mapped register and function code in the device documentation.
| Manual entry described in the setup | Interpretation reported | Engineering action |
|---|---|---|
| 01 — Setpoint 1 | Register map entry | Confirm register type and address in the map before creating a tag. |
| 02 — Setpoint 2 | Register map entry | Confirm register type and address in the map before creating a tag. |
| 27 — RH% value | Humidity measurement | Read using the map’s address convention and compare against the front panel. |
| 28 — Temperature value | Temperature measurement | Read using the map’s address convention and compare against the front panel. |
| 29 — Dewpoint value | Dewpoint measurement | Optional for this installation; the integrator reported calculating dewpoint from humidity and temperature instead. |
The map’s register entries were described in hexadecimal. In particular, 0x27 equals decimal 39. That conversion does not by itself decide how an Ignition item path should be written: the driver’s address convention and zero-/one-based setting also affect which register is requested. An early attempt to use HR39 did not solve the read, while the reported successful path was [eip885b]1.HR27 with the final settings below. Treat those as separate facts, then resolve any apparent discrepancy against the exact device map and the driver’s address interpretation rather than assuming every displayed number uses the same radix or offset.
Before adding tags, verify one mapped register’s function code, radix, and offset with the manual and the driver’s addressing convention; then confirm the resulting value against the device display.
Which connection settings affect the register request?
Apply the settings that made the read succeed as a group. A correct device connection can still return invalid quality when the driver asks for the wrong unit, address offset, or number of consecutive holding registers. The reported successful settings were:
| Setting | Working selection | Why it matters |
|---|---|---|
| Ignition Modbus driver | Modbus TCP | This driver selection returned values in the installation. |
| Holding-register request limit | One request | Restricts the holding-register request span; useful where broader requests encounter unsupported or invalid map locations. |
| Addressing mode | Zero-based; one-based checkbox unticked | Determines the offset applied when translating a tag path to a Modbus register address. |
| Unit ID | 1 | The default zero did not match the successful setup. |
| Register path |
1.HR27 for device eip885b
|
The final reported working OPC item path was [eip885b]1.HR27. |
Do not compensate for a wrong unit ID by changing a register number, or compensate for an addressing offset by changing the function code. Change and test one variable at a time after setting the known working combination. The one-register request limit is a request grouping constraint; do not interpret it as a change to the map’s register numbers.
After applying the driver settings, read a single known mapped register and confirm that its tag quality remains usable rather than alternating between Unknown and Not Connected.
How do you distinguish a bad tag path from a transport problem?
Use the symptoms to narrow the failing layer. A connected device entry does not guarantee successful register reads, and a tag that alternates between Unknown and Not Connected needs a register-level test rather than repeated browser checks.
| Symptom | Likely layer to check | Next diagnostic |
|---|---|---|
| Browser cannot show live readings | Device reachability or web interface | Restore browser access before diagnosing OPC tags. |
| Device reports connected, tag is null or quality alternates | Modbus request configuration | Check driver mode, unit ID, function/register type, address basis, and request limit. |
| Value appears but does not match the expected quantity | Register mapping or interpretation | Compare the tag with the corresponding device display and verify the map entry, radix, and offset. |
| One register reads but a wider set does not | Request span or unsupported map locations | Keep holding-register requests limited to one and test additional mapped registers individually. |
The earlier path [eip885b]HR27 returned null with alternating quality even while the driver configuration showed connected. A trial of HR39 also did not resolve the issue. The working result followed a mode change to Modbus TCP and use of the full successful configuration, including the unit ID and zero-based addressing; avoid treating a single address conversion as the whole fix.
Once a single tag reads, compare it directly to its live controller display. If the quality remains unstable, inspect the tag’s requested path and the device’s configured Modbus mode before expanding the tag set.
How should you add humidity, temperature, and optional dewpoint tags?
Build the tag set from the device map only after one read succeeds. The installation reported obtaining humidity and temperature directly from the controller. The map entries cited were RH% at 27, temperature at 28, and dewpoint at 29; the integrator later chose not to read dewpoint because it could be calculated from the other two values.
- Create one OPC tag for the mapped humidity register using the driver’s confirmed address notation and compare the value with the controller’s %RH display.
- Create a second tag for the mapped temperature register and compare it with the displayed temperature using the controller’s configured units.
- Add a dewpoint tag only if the application needs the device-provided value. Otherwise calculate it from humidity and temperature using a defined, validated calculation appropriate to the measurement units and operating range.
- Keep the one-holding-register request limit in place while commissioning each tag; do not assume a successful RH read proves the temperature or dewpoint mapping.
The source does not give the data scaling, signedness, or temperature units for these registers. Read those details from the device’s register documentation and confirm them against the display before using the values in alarms, trends, or calculations. Do not infer engineering units from a plausible-looking integer.
Check each tag independently for stable quality and agreement with the corresponding live device value before using it downstream.
How do you verify the complete Ignition data path?
Commission from the physical interface inward: confirm the browser reaches the controller, confirm the configured Modbus TCP connection, read one mapped holding register with unit ID 1 and zero-based addressing, and then validate humidity and temperature separately. A successful tag value alone is insufficient if it maps to the wrong register or scale.
- Confirm the embedded web page shows current readings.
- Confirm the Ignition device uses Modbus TCP and reports connected.
- Confirm the connection settings use unit ID 1, zero-based addressing, and a one-register holding request.
- Read the mapped humidity register and compare the numeric value to the controller’s %RH display.
- Read the mapped temperature register and compare it to the displayed temperature, accounting for the documented scale and units.
- Trend or monitor both tags long enough to confirm stable quality and changing values when the controller readings change.
Proceed to production use only after both tags retain valid quality and agree with their corresponding controller readings.
FAQ
Why does the Omega iServer show connected but the OPC tag is null?
A connected status does not prove the register request is valid. Check Modbus TCP mode, unit ID 1, zero-based addressing, the correct register type, and a one-register holding request.
Why does the device manual say RTU when Modbus TCP worked?
The installation’s manual described RTU transmission mode, but the successful Ignition configuration used the Modbus TCP driver. Test the driver mode against an actual mapped-register read rather than relying on the wording alone.
Why does hexadecimal register 0x27 equal decimal 39?
0x27 is hexadecimal notation for decimal 39. The Ignition path also depends on the driver’s address convention and zero-based setting; the reported working path was [eip885b]1.HR27, so verify the exact map and path convention together.
How do I confirm the Omega humidity and temperature tags are correct?
Read the mapped RH and temperature registers one at a time, verify stable tag quality, and compare each value with the controller display using the documented scaling and units. Complete this comparison before relying on either tag in application logic.