Where does the Modbus request travel?
Ignition's Modbus TCP driver is the master. It opens a TCP connection to the AutomationDirect Modbus gateway. The gateway strips the TCP header and re-issues the request as a Modbus RTU frame on the RS232 link to the MOSCAD unit. The MOSCAD answers on serial, the gateway wraps the reply back into TCP, and Ignition updates the tag. Each tag resolves to one of these transactions. A bad address therefore shows up in one of two ways: an exception reply from the MOSCAD, or a timeout at the gateway.
| Hop | Carries | What must match | Failure signature |
|---|---|---|---|
| Ignition to gateway (Ethernet) | Modbus TCP, function 04 for input registers | Gateway IP, Modbus TCP port (502 unless changed) | Device status not Connected |
| AutomationDirect gateway | TCP-to-RTU conversion | Unit ID handling, serial baud/parity/stop bits matching the MOSCAD port | Timeouts while the device still shows Connected |
| RS232 to MOSCAD | Modbus RTU | Slave address, register present in the MOSCAD Modbus table | Illegal data address exception, or no reply |
Start at layer one. A Connected status in Ignition proves hop one only. An open TCP socket to the gateway says nothing about whether the serial side answers. Subscribe to one tag, then watch the gateway's serial activity or diagnostics page. If requests leave on RS232 and nothing comes back, the problem is the unit ID or the serial settings, not the tag address.
How does 306146:01 decode into a register and a bit?
306146 is a six-digit Modbus reference. The leading 3 selects the input register table (function code 04). The remaining five digits, 06146, are the one-based register number: input register 6146. The suffix after the colon is a separate field.
The suffix runs :01 through :16 on the first register. That count matches the width of a 16-bit register exactly, so each suffix is one bit of the word. The second block, 306402:01 to :08, uses only 8 of 16 bits, which fits a register that is only partly populated with points.
| Interpretation of suffix | Ignition item path for 306146:01 | For | Against |
|---|---|---|---|
| Bit within register (recommended) | [Device]1.IR6146.0 |
Maximum suffix is 16, which equals the register width. A partial block ends at :08. | Bit order (LSB first or MSB first) has to be confirmed in the field |
| Modbus unit/slave ID |
[Device]1.IR6146, [Device]2.IR6146 ... [Device]16.IR6146
|
Ignition syntax does support a unit ID prefix | Sixteen slaves behind one RS232 port, all sharing the same register numbers, is not how RTU input tables are laid out |
The 1. in the paths above is the unit ID prefix. Take the real value from the MOSCAD port configuration or from the existing Wonderware item/topic definition. Do not carry 1 forward unverified.
Address mapping table or direct item paths?
Ignition's Modbus device configuration has an optional address mapping section. It defines custom prefixes that translate into Modbus ranges, which helps when a device documents its points in a proprietary format. The points themselves do not belong in the device configuration. Individual addresses go into the OPC Item Path of each tag.
| Criterion | Address mapping in device config | Direct item paths in tags |
|---|---|---|
| Setup effort | Define mapping rules, then still create tags | Create tags only |
| Traceability to MOSCAD list | Indirect, through custom prefix | One line per point: 306146:01 to IR6146.0
|
| Needed for 3xxxxx references | No. Standard input registers use the built-in IR designator. |
Yes, native |
| Troubleshooting | Extra translation layer to check | The request address is visible in the path |
Use direct item paths. The MOSCAD list is already standard Modbus, so a mapping layer adds nothing.
How do you build the tags?
- Record the unit ID, serial settings, and register format from the working Wonderware configuration. It is the only proven reference you have for this link.
- In the Tag Browser, create one Integer OPC tag per register as a raw diagnostic word, for example
ns=1;s=[Device]1.IR6146. - Create Boolean OPC tags for the bits. Subtract one from each suffix:
:01becomes.0and:16becomes.15. - Repeat the same pattern for every register block. For example,
306402:01through:08becomeIR6402.0throughIR6402.7. - For large site lists, build a UDT parameterized on register number, or generate the tags through tag import rather than typing each path.
MOSCAD Ignition OPC Item Path
306146:01 -> ns=1;s=[Device]1.IR6146.0
306146:02 -> ns=1;s=[Device]1.IR6146.1
...
306146:16 -> ns=1;s=[Device]1.IR6146.15
306402:01 -> ns=1;s=[Device]1.IR6402.0
...
306402:08 -> ns=1;s=[Device]1.IR6402.7All 16 bits of IR6146 come from a single register read. The driver groups contiguous registers into one request, so subscribing to many bits does not multiply serial traffic.
What if the values read wrong?
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| Bad quality, illegal data address | Register off by one, or the wrong table | Read raw IR6145, IR6146, IR6147 and compare each against Wonderware |
Correct the register, or the zero-based addressing setting on the device |
| Timeouts, device shows Connected | Unit ID mismatch, serial parameter mismatch, or a competing master | Gateway serial diagnostics: are requests sent, and are replies received? | Match the unit ID and serial settings to the Wonderware configuration |
| Plausible values that belong to another point | Neighbouring register being read | Raw word comparison against Wonderware | Shift the register by one |
| Right register, wrong bit | MOSCAD numbers :01 as the MSB |
Toggle one known input | Remap so :01 goes to .15
|
| Intermittent stale data | Two masters contending for one serial port | Check whether Wonderware still polls the RS232 port directly | Route both SCADA systems through the gateway, or stop one of them polling |
RS232 Modbus RTU is single-master. If Wonderware keeps its direct serial connection while the gateway polls the same MOSCAD port, frames collide. Parallel operation is only safe when both systems reach the MOSCAD through the gateway and the gateway serializes their requests.
How do you verify each point before cutover?
- Read the raw Integer tag for
IR6146and compare it with the value Wonderware shows for the same register at the same moment. - Convert the value to binary and confirm the set bits match the Boolean tags
.0through.15. - Change one field input with a known suffix, or pick one whose state you can see. Confirm the expected bit flips and no other bit does. This settles bit order.
- Repeat on a partially used register such as
306402, and confirm that bits.8through.15stay unused. - Walk every point at every site from the field device to its Ignition tag and record the result against the MOSCAD list before retiring the Wonderware path.
FAQ
What happens if I enter 306146 directly as the Ignition register number?
IR306146 asks for input register 306146, which is beyond the 16-bit Modbus address range. The request fails. Drop the leading 3 and the leading zero, and use IR6146.
What happens if I use the MOSCAD suffix number as the Ignition bit number?
Every point shifts by one bit, and :16 becomes .16, which does not exist in a 16-bit register. Subtract one: :01 maps to .0 and :16 maps to .15.
What happens if zero-based addressing is enabled on the Ignition Modbus device?
With zero-based addressing on, IR6146 requests the next register up from the one the one-based MOSCAD reference means. Every tag then reads its neighbour. Choose one setting, and confirm it with a raw word comparison against Wonderware.
What happens if Wonderware and Ignition both poll the MOSCAD during testing?
If both reach the MOSCAD through the gateway, the gateway serializes their requests and both systems work. If Wonderware stays on the RS232 port directly, the two masters collide and you get timeouts and stale values.
How do I confirm the unit ID before building hundreds of tags?
Copy the unit ID from the working Wonderware configuration and create a single raw tag such as [Device]1.IR6146. A timeout with a Connected device points to the wrong unit ID. A value that matches Wonderware confirms it, and then you can generate the remaining tags.