[
https://issues.apache.org/jira/browse/PLC4X-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989191#comment-16989191
]
Alvaro del Castillo commented on PLC4X-156:
-------------------------------------------
Ok, let's try to test it. The modbus server I am testing with is started from a
docker image with:
{code:java}
docker run --network=host --name=modbus -e PROTOCOL=tcp
panterdsd/diagslave:latest "/usr/bin/diagslave" -p 1502:502{code}
and in the console I can see logs with the modbus requests received by the
server (from the client using plc4x).
I have a test that I can reuse for this case:
{code:java}
private PlcReadResponse readModbusTestData(int offset, int readSize) throws
ExecutionException,
InterruptedException,
ProtocolException {
String modbus_url = "modbus:tcp://" + ip + ":" + port + "?slaveId=50";
// Create a modbus connection
ProtocolClient client = ProtocolClientFactory.build(modbus_url);
PlcReadRequest readRequest = client.getConnection().readRequestBuilder()
.addItem(registerName, "register:" + offset + "[" + readSize + "]").build();
return readRequest.execute().get();
}
{code}
ProtocolClient has a PlcConnection which is the one used. I have added to the
modbus_url the slaveId *50* and we must see this id in the modbus server logs.
I am now defining the best way to deploy specific versions of PLC4x and using
them. Once I have done it, I will report here the results.
> The unitId (device id/slave id) is hardcoded to 0 which is the broadcast id
> in modbus
> -------------------------------------------------------------------------------------
>
> Key: PLC4X-156
> URL: https://issues.apache.org/jira/browse/PLC4X-156
> Project: Apache PLC4X
> Issue Type: Bug
> Components: Driver-Modbus
> Reporter: Alvaro del Castillo
> Assignee: Christofer Dutz
> Priority: Critical
> Labels: config
> Fix For: 0.6.0
>
> Attachments: Plc4XModbusProtocol.java
>
>
> Trying to use the modbus driver, it is always trying to read and write from
> the slave 0 in the modbus slave/server. This identifier is the one used for
> broadcasting reads and writes to all the slaves in the modbus network. In
> modbus TCP this identifier is not needed, but it is needed to support legacy
> devices.
> And testing with with some modbus serves like:
> [https://pypi.org/project/pyModSlave|https://pypi.org/project/pyModSlave/]
> and in the second case, if you try to read a register:
> {noformat}
> 2019-11-27 08:29:29,837 ERROR modbus.handle_request Thread-1 invalid request:
> Function 3 can not be broadcasted{noformat}
> This unitId should be a param but if it must be hardcoded, changing it to *1*
> is a fix. But in some cases, you could need a
> specific id to connect to a device. For example, for the XY-MD02 sensor
> connected via serial to a Modbus TCP client, in order to read the values from
> the sensor you need to provide the right device id (in this case is also 1,
> but it could change).
> The unitId is defined in:
> [https://github.com/apache/plc4x/blob/develop/plc4j/protocols/modbus/src/main/java/org/apache/plc4x/java/modbus/netty/Plc4XModbusProtocol.java#L92]
> I have tested in 0.4.0 release that changing the unitId to *1* fixes the
> problem with modbus servers. I have attached the file with this minor
> modification.
> I can send a PR if you find the fix useful.
> Thanks!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
