Modicon M340 SCADA: The Driver Is Key, Not the Tag

Live M340 values appear after the HMI uses the correct Modbus data path and each screen object binds to the matching driver-backed tag. When the display stays blank, frozen, or zero, trace the chain from screen object to tag, driver, network interface, and controller data map.

What is the screen telling you?

A blank or static value does not identify the failed layer. The screen object only renders the value delivered through its binding. A correct-looking tag name can therefore hide a disconnected driver, an invalid data reference, or a network path that never reaches the controller.

The diagnostic order matters: screen object → HMI tag → Modbus driver → Ethernet path → PLC data. Start with what the operator sees, but test from the driver inward before rebuilding graphics.

Which free SCADA route fits the project?

The free options described for this application use different runtime models. Select the model before building screens; otherwise, a successful simulator test can be mistaken for a deployable SCADA runtime.

AdvancedHMI and Ignition can both serve a Modbus-oriented PC project. Choose AdvancedHMI for a free application intended to keep running; choose Ignition when faster initial assembly matters more than unrestricted trial duration. A two-hour trial window was reported for Ignition, with license-time resets used for further testing; read the installed license screen before planning a session around that limit.

Does the M340 installation provide a Modbus TCP path?

The stated controller is a Modicon M340 with a BMXP341000 processor. Before configuring SCADA, inspect the actual rack and controller project to identify the active Ethernet interface and confirm that it is configured to serve the required Modbus data. A reference to an M320 having onboard Ethernet does not establish the interface fitted to this M340 installation.

1. Inspect the physical rack and project hardware configuration. Record the Ethernet interface through which the PC will reach the PLC.
2. Read the configured IP settings from the controller project or interface diagnostics. Do not select an address merely because it appears on the local subnet.
3. Confirm that Modbus TCP service is active on that interface and that the variables needed by the mini-project are exposed through a documented Modbus data map.
4. From the SCADA PC, test basic network reachability. If reachability fails, correct the PC address, subnet path, cabling, switch connection, or PLC interface configuration before editing tags.

If the installed rack has no usable Ethernet interface, a Modbus TCP-only setup cannot communicate directly. Select an installed communications interface and a matching driver, or add an appropriate architecture outside the SCADA configuration. The hardware inventory decides this branch.

Is the driver actually reaching the controller?

Create one device connection before importing or constructing a large tag set. Configure the selected SCADA package with the PLC interface address and the connection fields requested by its Modbus driver. Where the driver asks for a device or unit identifier, copy the value required by the controller path rather than inserting an arbitrary default.

Watch the driver's connection state and request diagnostics while polling a single known value. No successful response sends the decision path back to the interface and network settings. Successful requests with a bad tag value move the investigation forward to data mapping.

Is the tag right but the Modbus binding wrong?

Modbus separates data into coils, discrete inputs, input registers, and holding registers. A numeric reference alone is incomplete: the SCADA tag must use the same data area and interpretation as the controller data map. Documentation and drivers may also express the same location with different reference conventions, so copy the driver's native syntax from its configuration help and reconcile it with the PLC map.

1. Select one PLC value whose live state can be observed independently in the controller programming environment.
2. Create one SCADA tag using the matching Modbus data area, reference, access direction, and scalar type.
3. Compare the raw SCADA value with the PLC value. If communication quality is good but the value is wrong, check reference offset conventions before changing the IP configuration.
4. For a value spanning multiple registers, set the required register order and numeric interpretation from the controller data definition. A swapped order can produce a stable but false number.
5. Bind a plain numeric or Boolean screen object directly to the tested tag. Add scaling and formatting only after the raw value matches.

When the tag diagnostic changes but the object does not, reopen the object's binding and select that exact driver-backed tag. Duplicate tag names, local memory tags, and copied objects commonly make the graphic look correctly configured while it reads a different value source.

How do you complete and verify the working setup?

1. Install the selected package. For AdvancedHMI, use its VB.NET project with Visual Studio; for Ignition, create the project within its trial runtime.
2. Create one Modbus device connection using values read from the installed M340 communications path.
3. Build a single test tag from the documented PLC data map and view its raw value and quality.
4. Bind one simple screen object to that tag. Prove the read path before adding alarms, animation, scaling, or write controls.
5. Move the PLC source safely through two distinct known states and confirm that the driver tag and screen object follow both transitions.
6. If writes are required, use a dedicated test point permitted for writing. Confirm the written value in the PLC, then restore the test point to its intended state.
7. Restart the HMI or SCADA runtime and repeat the read test. This exposes configurations that worked only in an editor or simulator session.

FAQ