Ewon Modbus Provides the Working PLC Alarm Path to Ignition

The tested working path is to expose PLC values as Ewon variables over Modbus TCP and let Ignition read those variables; the direct Siemens/ISO-on-TCP path remained unresolved. Treat these as two separate acquisition designs: a Siemens driver reading the PLC directly, or Ignition reading a Modbus map published by Ewon.

Choose the acquisition path that has passed a data test

The system was intended to carry alarms from a Siemens S7-300 through an Ewon cellular connection to Ignition at a dynamic public IP address. Testing instead used an S7-1200 over its PROFINET port with ISO-on-TCP. In that test, the PLC and Ewon exchanged data, but Ignition’s device status alternated between “connected” and “connecting.” Enabling the Ignition OPC server’s “Expose Configured Tags” setting did not resolve the read problem. A separate configuration using Ewon variables published through Modbus did communicate with Ignition.

Use the Modbus route as the proven path for this application, while keeping the direct Siemens route as a separate commissioning task if it is still required. The test used an S7-1200, while the intended machine uses an S7-300; validate the chosen route with the CPU and program that will run in production. A successful test with one CPU is not proof that another CPU uses the same address syntax or driver configuration.

1. Record the target PLC model and the Ewon variables that contain the alarm data.
2. Choose either direct Siemens access or Ewon-to-Ignition Modbus access for each Ignition device. Do not combine their addressing assumptions in one tag path.
3. For this tested implementation, proceed with Modbus and document the Ewon register map before building Ignition tags.

Check 1: With the intended PLC running, confirm the selected Ewon variables change when the corresponding PLC values change. The expected reading is a value in Ewon that follows the PLC value, not merely a connected device indicator.

Separate hostname resolution from protocol communication

Dynamic DNS gives Ignition a hostname to resolve as the cellular public IP changes. It does not guarantee that the resolved address is current, that a TCP session can be established, or that a PLC value can be read. The setup reports that the same DDNS hostname worked for an Ignition Modbus TCP device, while the Siemens device was intermittent. That comparison makes a general hostname failure less likely, but each protocol and destination still needs an independent test.

The setup also reports ports 102 and 502 as open. An open port only shows that a network path may reach a listener; it does not prove that the listener speaks the expected protocol, accepts the session, or serves the requested data. Check the resolved public address, the Ewon’s current WAN address, and the device status or connection diagnostics at the same time. If they disagree, resolve that network discrepancy before investigating tag syntax.

Industrial protocol ports exposed directly to the public internet increase the attack surface. Prefer a secured remote-access tunnel and restrict access to the required endpoints rather than treating an open port as the security design.

1. Resolve the DDNS hostname from the Ignition host and compare the returned address with the Ewon’s current reachable address.
2. Check the Ewon and Ignition connection logs during a “connecting” interval; note whether name resolution, session establishment, or application-level reads fail.
3. Repeat the check for the specific protocol and listener in use. A successful Modbus test does not verify Siemens ISO-on-TCP service, or vice versa.

Check 2: During a test, the hostname resolves to the current Ewon endpoint and Ignition reports a stable session to the selected protocol service. If the hostname or session fails, fix that layer before changing tags.

Keep Siemens addressing tied to the selected CPU

Siemens memory-area syntax depends on the CPU family and the driver’s supported addressing mode. The attempted global-tag paths were [test]M10#1, [test]M10.1, and [test]MX10.1, intended to read Merker bit 10.1. None was reported working. Do not treat these trial strings as interchangeable valid syntax: select the Ignition Siemens driver and its documented addressing mode for the exact CPU, then use that mode consistently.

The discussion called out a difference between addressing for S7-300/S7-1500 and S7-1200/S7-200 families. Because the test and intended installation use different CPUs, confirm the applicable family rules in the documentation for the installed driver and CPU. Verify the memory area, byte/bit interpretation, and address format in the PLC program. A tag name in a global Tags folder is only a place to store a tag; it does not by itself bind that tag to a PLC address.

The “Expose Configured Tags” OPC server setting was initially disabled and was later enabled, with no change in the symptom. It is therefore a configuration item to check when using the relevant OPC path, not a substitute for a valid device connection and correct item address.

1. Identify the PLC CPU in the active Ignition device configuration, not only in a project note.
2. Confirm that the selected driver and protocol support that CPU and the intended memory area.
3. Create one test item for a known Merker bit using the documented syntax for that exact CPU and driver.

Check 3: The test item quality is good and its value matches the known PLC bit as that bit is forced on and off. If the device is connected but the item is bad or static, investigate driver addressing and item configuration rather than changing DDNS.

Map Ewon variables to Modbus data

In the successful alternative, Ewon publishes its variables over Modbus and Ignition reads those variables through the Ewon device. Modbus provides a defined data map; it does not automatically preserve Siemens symbolic names or Merker addresses. The Ewon’s configured Modbus mapping is the source of truth for the register or coil location, data type, and any scaling or word order required by the variable.

No register numbers or variable data types are specified in this installation description. Read them from the Ewon configuration rather than guessing an address from the Siemens memory location. Confirm whether each alarm is represented as a bit, a register value, or a multi-register value, and note the exact map and interpretation that the Ewon exposes. Use the matching Modbus item type and address in Ignition.

1. Select the Ewon variables to expose and record their Modbus mapping from the Ewon configuration.
2. Confirm the Ewon’s Modbus service configuration and the host/port used by the Ignition device. Use the actual configured values; do not infer them from the other protocol’s port.
3. In Ignition, create a Modbus device for the Ewon and add one test tag at a documented mapped address.
4. Expand the map only after the single-value test reads correctly; preserve a register map alongside the PLC alarm list.

Check 4: The Ignition test tag quality is good and its value agrees with the corresponding Ewon variable. A successful device connection with an incorrect or unchanged value means the map, data type, or source variable still needs correction.

Bind Ignition tags to the Modbus map

Configure Ignition tags against the Ewon Modbus device, not against the Siemens syntax used for direct PLC access. Keep the tag’s Modbus item address and data interpretation aligned with the Ewon map. Use descriptive tag names for alarm meaning, but do not confuse a descriptive name with the protocol address that supplies the value.

For diagnosis, start with one discrete alarm or one simple numeric value whose state can be controlled at the PLC. Add tags in small groups and retain the mapped address and data type in the engineering record. If a tag is bad quality, inspect the Ignition device diagnostics and compare the requested address with the Ewon map. If quality is good but the value is wrong, verify that Ignition is reading the intended variable and interpreting the returned bits or registers correctly.

1. Create a test tag using the exact Modbus location and type shown in the Ewon map.
2. Set or change the associated PLC value in a controlled test and observe the Ewon variable.
3. Observe the Ignition tag, then add remaining alarm tags using their separately verified map entries.

Check 5: The Ignition tag remains good quality and follows the Ewon variable through both expected states or values. Do not commission alarms from a tag that only appears connected but has not been matched to its source.

Verify the alarm path end to end

A device status is not an end-to-end alarm test. The full path is PLC state, Ewon variable, Ewon Modbus publication, Ignition device read, and the Ignition alarm/tag behavior configured for the application. Test each transition in that order so a stale value or mapping error has a clear boundary.

1. Operate or simulate a known PLC alarm input/state. Expected reading: the PLC bit or value changes as defined in the PLC program.
2. Read the corresponding Ewon variable. Expected reading: it follows the PLC state without an unexplained inversion or delay.
3. Read the mapped Modbus item from Ignition. Expected reading: good quality and a value matching the Ewon variable according to the documented mapping.
4. Observe the final Ignition alarm/tag behavior for both asserted and cleared states. Expected reading: each state transition is represented correctly and the cleared state returns as expected.
5. Repeat while monitoring the device connection and network diagnostics. Expected reading: the hostname remains current, the Modbus session remains stable, and no unexplained status changes or stale values appear.

Check 6: The alarm asserts and clears correctly from the PLC through Ewon to Ignition, with good tag quality and a stable Modbus device status. This is the commissioning pass condition; a successful ping or open port alone is not.

Frequently asked questions