Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to implement a bus monitor #179

Open
hellow554 opened this issue Apr 1, 2023 · 3 comments
Open

How to implement a bus monitor #179

hellow554 opened this issue Apr 1, 2023 · 3 comments
Labels

Comments

@hellow554
Copy link

I have a modbus device that I'm trying to understand, because there's no public documentation available.

My current approach is to have a Server and dump all requests that it is receiving and returning future::ready(Ok(None)) to not send an answer.

First question: Is that the right approach to not send any data back?

Second question: How do I receive responses on the bus?

Thanks for your help!

@cdbennett
Copy link
Contributor

So let me see if I understand correctly, you have a Modbus client device which is undocumented, and you want to see what kind of Modbus requests that client device makes to a server?

@hellow554
Copy link
Author

Yes, exactly.
I want to monitor both, the communication from the RTU to the device in question and back.

@cdbennett
Copy link
Contributor

You could implement a Modbus server using tokio-modbus, and in response to any Read/Write register commands you could just return zero bytes or whatever data you want to make up. If you want the client device to send you other requests you probably don't want to "not send any data back".

Actually I want to clarify. At first It thought you only had the client device and you didn't have a corresponding server device it was talking to.

But, are you saying you already have both a "client" (master) and a "server" (slave) device, that are communicating correctly using some unknown protocol? And you want to monitor their communications and inspect the messages? Because that would suggest a different solution than if there were only one side of the pipe already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants