Modbus Read/Write Variables: Configuring HMI Setpoints

Use one HMI tag for a setpoint only when the controller exposes a genuinely readable and writable application object through a holding register. In the controller architecture described here, a network write feeds a function-block input while a network read returns a block output, so assigning both operations to one application variable is not inherently available. Where the runtime cannot provide a combined object, retain separate command and effective-value registers and make the HMI handle them as one operator control.

Why a Single HMI Setpoint Can Show the Wrong Value

The requested behavior is common: an operator enters a setpoint, the controller applies limits or other corrections, and the same HMI field then displays the value actually used by the control algorithm. A single read/write tag makes that workflow simple because the HMI writes a requested value and later reads the resulting effective value from the same logical object.

The difficulty is not the HMI field itself. It is the controller's mapping between protocol data and the cyclic FBD application. In this implementation, writing a Modbus variable writes directly to the input of a connected block. Reading the variable reads directly from the output of a block. Inputs and outputs have different roles in the FBD dataflow and cannot simply occupy the same application cell.

Observed symptom	Likely mechanism	Engineering response
The HMI accepts a new setpoint, but the value immediately returns to an older value.	The cyclic program rewrites the readable value, or the HMI reads a different mapped object after writing.	Trace the write destination, application processing path, and read source separately.
The entered value remains visible, but it does not show controller limiting.	The HMI displays its local write value rather than reading the effective controller value.	Force a readback after the write or display the effective-value register.
Two numeric fields are required for one setpoint.	The runtime exposes a command input and a calculated output as separate Modbus variables.	Use an HMI faceplate, script, or tag alias to present both addresses as one operator control.
A value written from the network is lost.	The cyclic application overwrites the same storage on its next execution.	Add ownership and change-detection logic; do not rely on scan timing.
A program using the new address map will not load on core version 236.	That core does not support address allocation used by the new map.	Enable Old map or update to a core that supports the new map.

Separate Modbus Data Spaces from Application Ownership

Modbus defines distinct logical data spaces: discrete inputs, coils, input registers, and holding registers. Their names describe protocol-level access and intended use; they do not require every controller to implement them as a particular physical RAM layout. The decisive question is how the device maps each protocol object into its runtime.

Holding registers are the normal choice for settings that a master must both write and read. A controller can expose a setting through a holding register, allow local logic or a controller panel to modify it, and return its current value on the next master read. That design requires one authoritative application object with controlled write access from all producers.

Mapping an input register and a holding register to the same numeric offset is not automatically equivalent to one read/write tag. They remain different Modbus data spaces, and the master selects a space through the operation it issues. Some HMI drivers also model them as separate tags even when their numeric offsets match. Confirm the HMI driver's address syntax and supported read/write operations before relying on an overlapping address.

Do not confuse a protocol address with ownership. If the network, local panel, limiter, and FBD logic can all write the setting, the application needs explicit precedence rules. Without them, the fastest writer wins, and a valid network command may survive for only one program cycle.

How the Cyclic FBD Runtime Changes the Design

A cyclic FBD program is a directed dataflow, not a conventional subroutine that receives a structure, modifies it, and returns it. A block input is formed from constants, network variables, or outputs of preceding blocks. A block output becomes data for later blocks and for mapped readback. The blocks do not independently acquire an arbitrary shared cell and retain it after execution.

The controller may execute hundreds of cycles per second. That does not mean Modbus registers should be transmitted or rewritten hundreds of times per second. It means application outputs can be recalculated that often. If a communication write lands on an object that the application also assigns every cycle, the application assignment can erase the external value almost immediately.

A safe setpoint design separates the events:

1. Accept a network or local command only when a new value is detected.
2. Validate the command against the application's permitted range and operating state.
3. Store the accepted command in an application-owned setting.
4. Apply dynamic limiting or correction to produce the effective setpoint.
5. Expose the effective value for readback.

If the runtime supports a combined network/application read-write object, the stored or effective value can back one holding register. A trial implementation modeled after an EEPROM-style object—readable and writable from both the program and network—proved awkward to use in this FBD environment, so no generally accepted combined-variable mechanism was available. Treat a visually shared address as valid only after testing its scan behavior.

Select a One-Register or Two-Register Architecture

Architecture	Use when	Main benefit	Main risk
One holding register backed by one authoritative setting	The runtime supports program and network access to the same retained object.	One HMI tag can write and read the current setting.	Application writes can overwrite master writes unless ownership is controlled.
Command register plus effective-value register	Writes map to an FBD input and reads map to an FBD output.	Dataflow and ownership remain explicit.	The HMI must coordinate two addresses.
Overlapping numeric offsets in different Modbus spaces	The controller explicitly supports the mapping and the HMI can select the correct operation.	Numeric addressing may appear compact.	Different spaces are still different protocol objects; driver behavior may defeat the design.
Dedicated buffered communication object	The platform provides a managed buffer or communication stack.	Application and protocol ownership can be isolated.	Consumes RAM and processor time and may not fit a constrained controller.

For this controller family, the command/effective-value pair is the predictable design when the FBD graph cannot bind both directions to one cell. The HMI can still present a single field: write the command address, then refresh the displayed value from the effective-value address. If the HMI cannot assign separate read and write addresses to one object, use an internal HMI tag and a write action followed by a readback action.

Configure the Setpoint and HMI Readback

1. Define the command path. Map a writable holding register to the FBD input that accepts the operator's requested setpoint. Do not connect this input directly to logic that assigns it unconditionally every scan.
2. Detect a new command. Compare the received command with the last accepted command, or use the platform's available update indication. Process the value when it changes instead of copying it continuously without purpose.
3. Validate before use. Apply range checks, operating-state permissions, and any required scaling. Preserve the requested value separately if diagnostics must distinguish an invalid request from an active limit.
4. Calculate the effective setpoint. Apply the controller algorithm, including any dynamic restriction. This result is the value the machine actually uses.
5. Map readback. Expose the effective setpoint through a readable Modbus object. If the platform provides a tested combined holding-register object, map that object instead; otherwise retain a distinct readback address.
6. Coordinate the HMI. On entry, write the command value. After the write completes, issue a normal read and replace the displayed entry with the controller's effective value. Do not leave the HMI's local entry cached as though it were confirmed.
7. Define concurrent-write precedence. Decide whether the network, local panel, or automatic correction owns the value in each machine state. Reject or defer lower-priority writes rather than resolving conflicts through scan order.

The write rate should follow operator or supervisory changes, not the controller scan rate. Settings normally change infrequently. Rewriting an unchanged value every scan or every HMI poll wastes processing capacity and can repeatedly retrigger validation or change-handling logic.

Choose the Memory Map for the Installed Core

The configurable new memory map is supported starting with core version 242. On core version 236, clearing the Old map option produces a load-time message indicating that the core does not support address allocation, and the program will not load. Keep the old map selected for that core or update the core before using the new allocation scheme.

The newer map can reduce occupied controller memory, but it does not reduce the amount of Modbus application data exchanged for the same requests. Memory allocation and network payload are separate concerns. Verify both the compiled memory usage and core compatibility before deploying a map change.

Resource cost also explains why a dedicated communication buffer is not automatically preferable. Tests of this controller architecture found that simultaneous polling through two ports slowed the program by about 10% with direct mapping. A design using fully separate network handlers was estimated to require 8 kB, exactly half of the RAM available to the FBD program, and to consume about 60% of execution performance. These figures apply to the tested architecture; use the controller's compilation report and cycle-time diagnostics to evaluate the actual project.

Verify Traffic, Scan Behavior, and Final Value

Modbus slave communication occurs in response to master requests. Read-only and read/write variables are not continuously pushed into the channel. The slave returns data when the master issues a read and processes data when the master issues a write. Therefore, changing the memory map does not by itself change channel loading; polling frequency, request size, number of ports, and retries control the traffic.

1. Record the requested setpoint, effective setpoint, and controller cycle time before testing.
2. Write a value that requires no limiting. Read back and confirm that the effective value matches the accepted command.
3. Write a value that invokes the configured application limit. Confirm that the control algorithm uses the limited value and that the HMI displays that same effective value after its next read.
4. Stop writing and continue polling. The value must remain stable unless the application intentionally recalculates it.
5. Apply a local-panel change, then read from the master. Confirm the result matches the defined ownership rule.
6. Poll both configured ports, if used, and measure the actual cycle-time change rather than inferring it from network byte count.
7. Power-cycle only if the setting is intended to be retained, then verify retention through the controller's supported storage mechanism.

If a write disappears, watch the command and effective-value objects across consecutive scans. A command that changes and then immediately returns identifies an application overwrite. A command that remains correct while the HMI shows another value identifies an HMI read-address, caching, or refresh problem.

FAQ