The engineer sees two ECD2-M setpoint controls on the web interface, but both commands are transmitted to the register address configured for the first control in the Modbus template. Reordering the controls only changes which address receives every command. Follow the packet from the web command through the template lookup and into the communication-line log: the decisive setting is the unique command number assigned to each control channel.
Where does the command path stop?
The request begins when the operator changes a setpoint on the web interface. The application identifies the selected control channel, resolves that channel through the Modbus template, builds the write request, and passes it to the communication line. The line then carries the request to the instrument.
| Path stage | Reading to take | Expected distinction | Next check |
|---|---|---|---|
| Web control | Selected setpoint or control channel | Each displayed control selects a different configured command | Inspect template command numbers |
| Template lookup | Command number |
Every command has a unique number | Compare resolved register addresses |
| Modbus request builder | Destination address and write data | The address matches the selected setpoint | Read the communication-line log |
| Communication line | Transmitted request | Different controls produce requests for their respective addresses | Verify the instrument response |
The observed request reaches the communication line, so the web control and basic communication path are active. The wrong register address appears before the instrument can interpret the command. That places the fault in command selection or template mapping, not in the device's handling of the written value.
Does layer one carry a complete request?
Layer one first. Confirm that operating either setpoint produces an outbound entry in the communication-line log. Record the selected control, transmitted destination address, request data, response status, and timestamp shown by the logging system. The log is the boundary between configuration intent and traffic actually placed on the link.
| Log result | Meaning | Next action |
|---|---|---|
| No request for one control | The request stops before transmission | Check whether that web control is connected to a command channel |
| Requests appear, but both use the first configured address | The template resolves both controls through the same command entry | Compare command numbers |
| Requests use different intended addresses | Template dispatch is working | Check the returned response and device-side register definition |
| Request is transmitted but no valid response returns | The mapping symptom has been passed; investigate the physical link and protocol settings | Compare line settings and device communication configuration |
Do not start by changing register addresses when the log shows that both controls already select the first address. The configured addresses may be correct individually; the application is selecting the wrong template entry before constructing the request.
Are the command numbers unique?
Open the Modbus template and compare the command number assigned to every setpoint and control command. These numbers identify separate command definitions. They are not labels for positions in a list of command types.
When multiple controls share a command number, the dispatch lookup is ambiguous. In the reported configuration, the lookup selected the command placed first in the template. Both web controls therefore inherited that entry's Modbus address. Moving the second setpoint to the first position changed the address used by both controls, which isolates the fault: template order affected the selected mapping, while the individual address entries themselves did not determine the result.
| Template observation | Interpretation | Decision |
|---|---|---|
| Two commands have the same number | Both controls can resolve to one command definition | Assign unique sequential numbers |
| Numbers are unique, but one web control references the wrong number | The channel-to-command connection is incorrect | Correct that control's reference |
| Numbers and references are unique | Dispatch identifiers are not colliding | Compare the transmitted address with each template address |
Do the command number and register address serve different roles?
Keep the application identifier separate from the Modbus destination. The command number selects a command definition inside the template. The register address tells the generated Modbus request where the device value belongs. A correct address cannot compensate for a duplicated selector.
| Setting | Role | Failure symptom |
|---|---|---|
Command number |
Distinguishes one configured command from another | Duplicate values can route multiple controls through the first matching entry |
| Command type | Describes the operation represented by the command | Confusing it with the command number creates duplicate selectors |
| Register address | Selects the destination within the instrument's Modbus data map | A wrong value directs an otherwise correctly selected command to the wrong location |
| Template order | Controls which definition appears first | Reordering changes the common destination when identifiers collide |
The order-dependent test is especially useful. If whichever entry appears first captures all writes, search for a duplicated lookup key before investigating byte order, value scaling, or the instrument's register behavior.
How should the template be corrected?
- Stop issuing setpoint changes while editing the template so that old and revised mappings are not mixed in the log.
- List every control command in template order, including its web control,
command number, command type, and Modbus register address. - Assign the first command number
1, then continue with a different sequential number for each remaining command. The working configuration used numbers starting at1and continuing upward. - Keep each command connected to its intended web control. Changing numbers without checking these references can replace one mapping error with another.
- Retain each intended register address. Change an address only when comparison with the instrument's register map shows that the address itself is wrong.
- Apply the revised template using the normal configuration workflow, then reopen it and confirm that the stored command numbers remain unique.
The correction acts on the selector that chooses the template entry. It does not require moving a setpoint to the top of the template; reordering only masks which definition wins the collision.
How do you verify every resolving branch?
- Clear or mark the communication-line log so the verification traffic is easy to isolate.
- Issue one controlled write from the first web setpoint and record its transmitted address and data.
- Issue a different controlled write from the second setpoint and record the same fields.
- Confirm that the two requests use their respective configured addresses rather than the address of whichever command appears first.
- Read back each affected value through the available device or application feedback path. Confirm that only the selected setpoint changed.
- Repeat the test for every additional command number introduced by the template correction.
If transmitted addresses remain identical, return to the channel-to-command references and look for another duplicated number. If transmitted addresses differ correctly but the wrong device value changes, continue at the device register map; the command-selection fault has been removed.
FAQ
Why does ECD2-M send both setpoint commands to one address?
The Modbus template can route both controls through the same command definition when their command number values are duplicated. Assign a different number to every command, starting with 1 and continuing upward.
Why does moving a command to the top change the address used?
An order-dependent destination indicates that duplicate command identifiers are resolving to the first matching template entry. Reordering changes the winning entry but does not remove the collision.
Why does a correct Modbus register address still receive the wrong command?
The application selects the command definition before it builds the Modbus request. If the command number selects the wrong definition, the request uses that definition's address even when another address is entered correctly elsewhere.
How do I verify the ECD2-M command-number fix?
Send one distinct write from each web control and inspect the communication-line log. The final verification is that every control transmits to its own configured address and readback shows that only the selected setpoint changed.