04-20-2026, 10:06 AM
- Firmware Version: v3.24.3 (Build Date: Apr 12 2026)
- Hardware: A16v3
- Communication: Modbus RTU (RS485)
## Description:
I have encountered an issue regarding the implementation of Modbus Function Code 05 (Write Single Coil).
According to the official Modbus specification, to turn a coil ON, the data field must send FF00. To turn it OFF, the data field must send 0000. However, my A16v3 running firmware v3.24.3 does not seem to accept this standard.
## Observed Behavior:
The device expects (or only responds to) a "bit-encoded" state in the data field. For example:
Instead of FF 00, the device expects 01 00 (or similar bit masks) to activate the coil.
Instead of 00 00, it expects 00 00.
This behavior is non-standard. It appears the firmware is treating FC05 as if it were a "Mask" or mimicking the data structure of FC15 (Write Multiple Coils) rather than the strict FF00/0000 pattern required by the Modbus standard.
## Steps to Reproduce:
Establish Modbus TCP connection to the device (IP: 10.130.1.43).
Send standard Modbus FC05 frame to any valid coil address (e.g., 00 01):
Standard ON: [Slave ID] 05 [Addr High] [Addr Low] FF 00 [CRC]
Standard OFF: [Slave ID] 05 [Addr High] [Addr Low] 00 00 [CRC]
Observe that the coil state does not change (or the device returns an exception/incorrect response).
Send a modified frame using bit-encoded data (e.g., 01 00 for ON).
Observe that the coil toggles successfully.
## Expected Behavior:
The device should strictly adhere to the Modbus specification for Function Code 05, using FF00 for ON and 0000 for OFF.
## Questions / Requests:
- Is this a known issue in v3.24.3?
-Is there a configuration flag in the Web UI (e.g., "Strict Mode," "Legacy Mode," or "Compatibility Mode") that can switch the device to standard Modbus compliance?
-If not, is this planned to be fixed in a future firmware update?
## Additional Context:
Software Version: v3.24.3
Build Date: Apr 12 2026
I am using a standard Modbus master software (PLC/SCADA) that strictly adheres to the FF00 standard, so I cannot easily modify the protocol structure on the master side.
- Hardware: A16v3
- Communication: Modbus RTU (RS485)
## Description:
I have encountered an issue regarding the implementation of Modbus Function Code 05 (Write Single Coil).
According to the official Modbus specification, to turn a coil ON, the data field must send FF00. To turn it OFF, the data field must send 0000. However, my A16v3 running firmware v3.24.3 does not seem to accept this standard.
## Observed Behavior:
The device expects (or only responds to) a "bit-encoded" state in the data field. For example:
Instead of FF 00, the device expects 01 00 (or similar bit masks) to activate the coil.
Instead of 00 00, it expects 00 00.
This behavior is non-standard. It appears the firmware is treating FC05 as if it were a "Mask" or mimicking the data structure of FC15 (Write Multiple Coils) rather than the strict FF00/0000 pattern required by the Modbus standard.
## Steps to Reproduce:
Establish Modbus TCP connection to the device (IP: 10.130.1.43).
Send standard Modbus FC05 frame to any valid coil address (e.g., 00 01):
Standard ON: [Slave ID] 05 [Addr High] [Addr Low] FF 00 [CRC]
Standard OFF: [Slave ID] 05 [Addr High] [Addr Low] 00 00 [CRC]
Observe that the coil state does not change (or the device returns an exception/incorrect response).
Send a modified frame using bit-encoded data (e.g., 01 00 for ON).
Observe that the coil toggles successfully.
## Expected Behavior:
The device should strictly adhere to the Modbus specification for Function Code 05, using FF00 for ON and 0000 for OFF.
## Questions / Requests:
- Is this a known issue in v3.24.3?
-Is there a configuration flag in the Web UI (e.g., "Strict Mode," "Legacy Mode," or "Compatibility Mode") that can switch the device to standard Modbus compliance?
-If not, is this planned to be fixed in a future firmware update?
## Additional Context:
Software Version: v3.24.3
Build Date: Apr 12 2026
I am using a standard Modbus master software (PLC/SCADA) that strictly adheres to the FF00 standard, so I cannot easily modify the protocol structure on the master side.