Fix reading serial slave response RTU

steveohara / j2mod

Enhanced Modbus library implemented in the Java programming language

Apache License 2.0

265 stars 111 forks source link

Fix reading serial slave response RTU #78

Closed NogginBops closed 5 years ago

NogginBops commented 6 years ago

This PR makes it so that the slave implementation expects an answer for messages not meant for it.

This is more of a proof of concept more than a full pr. The same thing should be applied to Modbus ASCII and thought should be put into what to do if there never comes a response. (Maybe a timeout)

This also clarifies some debug printouts that were wrong too. (and adds some for the new feature 🙂)

Fixes #76

NogginBops commented 6 years ago

This fix does not work atm as, if the master resends it's request as the slave is expecting a response the slave doesn't work.

NogginBops commented 6 years ago

There needs to be a good way o either detect if a message is a request or a response, or there needs to be a good way to ignore all messages that are not meant for the slave (Using the 3.5T break as the end of the message).

NogginBops commented 6 years ago

I just pushed a commit which adds the time-based reading on RTU. It reads one byte to check the UnitID and then determines after that if the message should be ignored or not. If it should be ignored we read bytes until we see an interval of 3.5T silence and then resets and waits for another byte to determine if that message should be read. If the first byte corresponds to a ProcessImage then the message is read and parsed the old way of determining the length from the function code.

NogginBops commented 6 years ago

In our system this is working like a charm. We are running a 38400 baud with two slaves. Our master and one of our slaves is running j2mod. This code correctly filters out the messages meant for the other slave. There are still some hard coded values left in the code that are not what they should be according to the spec (The inter-char timeout and message interval). I will work towards a commit where these values are correct.

steveohara commented 6 years ago

I can't accept this PR I'm afraid;

It must be built for JDK 1.6 (it contains some JDK 8 code)
You need to remove the extraneous JAR files from the root. The build is a Maven project and any required libraries should be maintained through that mechanism
We are not distributing modpoll - it is used purely for testing so should not be included in the main source tree

If you fix these issues, I'll take another look at merging it into development and then production. Thanks

NogginBops commented 6 years ago

I have now fixed the weird files and fixed so that the new code does not require Java 8. Weird that I even got those files in a commit, was pretty sure I was extra careful about that. Oh well.

steveohara commented 6 years ago

Your branch still has 1.8 classes in it e.g. BooleanSupplier