[Bug]: [Modbus] Support UDINT with least significant register first (little-endian word order)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- java
- 領域
- backend, embedded-iot
調査の方向性
Start by reading the PLC4J Modbus tag decoding and payload byte-order code; the issue does not name specific files or tests. Check how UDINT currently handles two holding registers and whether byte order can be separated from register order. Done means a documented way to select least-significant-register-first produces 1431377 for the reported register values.
索引モデルが issue の本文から書いたものです。
説明
What happened?
I would like to request support for decoding 32-bit unsigned integer values (UDINT) from Modbus holding registers when the least significant 16-bit register is transmitted first.
My Modbus energy meter exposes a 32-bit unsigned energy value across two consecutive holding registers. The meter returns the least significant register first, followed by the most significant register.
I can read both registers successfully using the UINT data type and manually reconstruct the 32-bit value. However, I have not been able to obtain the expected result directly using UDINT with LITTLE_ENDIAN.
Environment
Protocol: Modbus TCP
Driver: Apache PLC4X Modbus TCP
Device: Modbus energy meter
Unit Identifier: 19
Request timeout: 5000 ms
Default payload byte order: BIG_ENDIAN
Connection URL
String connectionUrl =
"modbus-tcp:tcp://10.10.121.55:502"
+ "?unit-identifier=19"
+ "&request-timeout=5000"
+ "&default-payload-byte-order=BIG_ENDIAN";
Steps to Reproduce
- Read the two holding registers as UINT
PlcReadRequest request = connection.readRequestBuilder()
.addTagAddress(
"energy",
"holding-register:29[0..1]:UINT{unit-id: 19}"
)
.build();
The response contains:
response = [55121, 21]
Tag: energy
Response code for energy: OK
The two 16-bit register values are:
First register: 55121
Second register: 21
- Reconstruct the unsigned 32-bit value manually
The expected result is calculated by placing the second register in the upper 16 bits and the first register in the lower 16 bits:
long energyValue =
((long) 21 << 16) | 55121L;
Result:
Assembled Energy Value: 1431377
This produces the expected energy value.
- Attempt to read the value directly as UDINT
I am unable to obtain the same expected value by reading the two registers directly as UDINT with LITTLE_ENDIAN byte order.
I would like PLC4X to support decoding this register arrangement directly, without requiring applications to read individual registers and reconstruct the value manually.
Expected Behavior
PLC4X should support decoding a 32-bit unsigned integer from two Modbus holding registers when the least significant register is first.
For the example above:
Register 1 (LSW) = 55121
Register 2 (MSW) = 21
Expected UDINT value = 1431377
The driver should provide a documented and supported way to select the register/word order independently of the byte order within each 16-bit register, where necessary.
Actual Behavior
The two registers can be read successfully as UINT, and the expected value can be calculated manually.
However, I cannot obtain the expected result directly using UDINT with LITTLE_ENDIAN.
Requested Enhancement
Please clarify whether the Modbus driver supports 32-bit unsigned integer decoding with least significant register first.
If this arrangement is not currently supported, please consider adding support for configurable 16-bit register/word ordering for multi-register data types such as:
UDINT — unsigned 32-bit integer
DINT — signed 32-bit integer
REAL — 32-bit floating-point value
Other supported multi-register data types, where applicable
The configuration should distinguish between:
Byte order: the ordering of bytes within an individual 16-bit register.
Word/register order: the ordering of the two 16-bit registers that make up a 32-bit value.
These settings should be independently configurable where the protocol and driver implementation permit it.
Additional Information
The Modbus connection and read request are successful, and the response code is OK.
The issue concerns decoding the two register values into the expected 32-bit unsigned integer rather than reading the registers themselves.
Version
v1.0.0
Programming Languages
- plc4c
- plc4go
- plc4j
- plc4net
- plc4py
Protocols
- AB-Ethernet
- ADS /AMS
- BACnet/IP
- C-Bus
- CANopen
- EtherNet/IP
- Firmata
- IEC-69870
- KNXnet/IP
- Modbus
- OPC-UA
- PLC4X
- Profinet
- S7
- Simulated
- SLMP
- UMAS
- 主要言語
- Java
- スター
- 1.8k
- フォーク
- 512
- 平均マージ
- 2日 2時間
- マージ済み PR（30日）
- 34
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/plc4x のほかの issue
-
Ethernet/IP java
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
apache/plc4x#2733 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
-
[Bug]: TagBatch reuses a cached PlcReadRequest bound to a closed connection, so fetches fail after the first and never recover after a PLC restart対応中かも @chrisdutz が 4 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
[Bug]: OPC-UA driver 1.0.0 fails against a certificate-less server even with security-policy=NONE (regression vs 0.13.1)対応中かも @splatch が 9 日前に担当しました。 オープン
メンテナーはふだん 1 日以内に返信
-
[Bug]: OPC UA UserNameIdentityToken sends length+password+nonce instead of the plain password when token security policy is None対応中かも @splatch が 28 日前に担当しました。 オープンOPC-UA
apache/plc4x#2791 · コメント 2 件 · 担当者 2 名 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
breaking change bug needs human review not ready priority medium size S
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
martin-francois/symphony-trello#1193 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Mend: dependency security vulnerability
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
status: waiting-for-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
spring-projects/spring-framework#37614 ·
メンテナーはふだん 1 日以内に返信