Modbus4J changes in Mango 1.8.2

---

Hi,

I upgraded from 1.8.0 to Mango 1.8.2. I'm since getting frequent exception messages from Modbus4J that I didn't get in 1.8.0, like this:

WARN 2010-04-07 10:23:07,562 (com.serotonin.mango.rt.dataSource.modbus.ModbusDataSource.receivedException:226) - Modbus exception
com.serotonin.modbus4j.exception.IllegalFunctionException
at com.serotonin.modbus4j.msg.ModbusResponse.createModbusResponse(ModbusResponse.java:50)
at com.serotonin.modbus4j.serial.rtu.RtuMessageResponse.createRtuMessageResponse(RtuMessageResponse.java:16)
at com.serotonin.modbus4j.serial.rtu.RtuMessageParser.parseMessageImpl(RtuMessageParser.java:21)
at com.serotonin.modbus4j.base.BaseMessageParser.parseMessage(BaseMessageParser.java:17)
at com.serotonin.messaging.MessageControl.data(MessageControl.java:129)
at com.serotonin.messaging.InputStreamListener.run(InputStreamListener.java:76)
at java.lang.Thread.run(Thread.java:619)

As an illegal function exception is reported, I'm guessing that the Modbus4J is using a modbus function that wasn't used before. Despite these error reports, my data is still comming in OK in Mango by the way.

I'm polling holding registers with Mango. The modbus device supports the modbus function 3 (read block), 6 (write single reg), 16 (write block). I know that Modbus4J reads with function 3 and writes with function 6 in the Modbus4J version that shipped with Mango 1.8.0. Did this mechanism perhaps change in the latest version ?

Hi Andras,

That message is being thrown by the incoming message processing. Data is coming back from the modbus device, and Modbus4J is trying to parse it into a response message, but the function code is not recognized. I've enhanced the exception to report the function code that was sent. To implement, replace the Modbus4J jar file with the attached.

The Modbus4J package did recently undergo some changes as a result of an overhaul of the messaging system within seroUtils. But these changes were only to make it compliant to the new base, not to change any functionality. In any case, a change is a change, and so could be responsible for what you are seeing.

Can you please implement the attached and post the function code that you are getting. We can use this as a starting point in diagnosing the problem.

Attachment: download link

Hi Andras,

If it is possible to also get a dump of the serial line communication, that would be helpful.

Hi Matthew,

I replaced the Modbus4J.jar and set my modbus source to poll holding register 6 and 8 every 5 seconds (serial settings: 9600 8N1). I noticed that most of the time there is no error reported. About 1 out of 10 times I get an error message like this:

WARN 2010-04-09 10:09:05,029 (com.serotonin.mango.rt.dataSource.modbus.ModbusDa
taSource.receivedException:226) - Modbus exception
com.serotonin.modbus4j.exception.IllegalFunctionException: Function code: 0x28
at com.serotonin.modbus4j.msg.ModbusResponse.createModbusResponse(Modbus
Response.java:50)
at com.serotonin.modbus4j.serial.rtu.RtuMessageResponse.createRtuMessage
Response(RtuMessageResponse.java:16)
at com.serotonin.modbus4j.serial.rtu.RtuMessageParser.parseMessageImpl(R
tuMessageParser.java:21)
at com.serotonin.modbus4j.base.BaseMessageParser.parseMessage(BaseMessag
eParser.java:17)
at com.serotonin.messaging.MessageControl.data(MessageControl.java:129)
at com.serotonin.messaging.InputStreamListener.run(InputStreamListener.j
ava:76)
at java.lang.Thread.run(Thread.java:619)
tried to access field gnu.io.RXTXPort.IOLocked from class gnu.io.RXTXHack

The function code 0x28 reported above isn't always the same; it changes now and then. If we look at the serial trace it becomes clear why:

Request: 9-4-2010 10:09:04.25764 (+4.9375 seconds)
01 03 00 06 00 03 E5 CA ......åÊ
Answer: 9-4-2010 10:09:04.28864 (+0.0313 seconds)
01 03 06 00 00 00 00 00 D2 A1 28 ........Ò¡(

It looks like the 0x28 is the last byte of the CRC. Normally I see only 1 request and 1 reply in the trace every 5 secs, but when this error occurs Modbus4J retries and we see a second try shortly after the one that didn't succeed:

Request: 9-4-2010 10:09:05.77264 (+0.4375 seconds)
01 03 00 06 00 03 E5 CA ......åÊ
Answer: 9-4-2010 10:09:05.80464 (+0.0313 seconds)
01 03 06 00 00 00 00 00 D2 A1 28 ........Ò¡(

I suppose that's why I still get the data in Mango despite the errors.

Note that the request-reply that preceded the one with timestamp 10:09:04.25764 looks like this:

Request: 9-4-2010 10:08:59.25764 (+4.9688 seconds)
01 03 00 06 00 03 E5 CA ......åÊ
Answer: 9-4-2010 10:08:59.31964 (+0.0625 seconds)
01 03 06 00 01 00 00 00 D2 9C E8 ........Ò?è

So the 0x28 didn't appear in the answer message prior to the one that didn't succeed.

Hi Andras,

The new code wasn't marking the buffer in case of incomplete messages. Can you please replace the existing seroUtils with the attached and let me know if it helps.

Attachment: download link

Yes, that did the trick. I no longer get the error messages :) Thanks !

No problem. Thanks for getting back.