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

fix two modbus rtu problems #79

Merged
merged 7 commits into from
Sep 7, 2022
Merged

fix two modbus rtu problems #79

merged 7 commits into from
Sep 7, 2022

Conversation

LukasKarel
Copy link
Contributor

When a ModbusRtuRequestHandler is Disposed it closes the SerialPort before the CancellationTokenSource of the base class is cancelled. Therefor the InBuffer of SerialPort should be cleared even if the serialport is already closed.
Secondly on a timeout exception the UnitIdentifier should be reset otherwise an exception is thrown.

@LukasKarel LukasKarel changed the title fix two modbus serial problems fix two modbus rtu problems Aug 25, 2022
@LukasKarel
Copy link
Contributor Author

Added a new commit, which adds a virtual stop method to the ModbusServer base class. This helps to add both servers in the same container and perform cleanup on them.

@Apollo3zehn
Copy link
Owner

Thank you! I will go through it next week as I need to finish another project right now.

@Apollo3zehn
Copy link
Owner

Apollo3zehn commented Sep 6, 2022

You wrote "Therefor the InBuffer of SerialPort should be cleared even if the serialport is already closed." but your PR does the opposite: Is clears the buffer only when the serial port is already closed. I am a little bit confused.

What happens if the serial port is already closed and we try to clear the buffer? Will it throw an exception?

Edit: I have tested it and it throws an exception. So I agree to this change (only discarding buffer when port is open).

@Apollo3zehn
Copy link
Owner

Where does the exception occur, if the UnitIdentifier is not reset? To be honest I think there is another bug in the ModbusRtuRequestHandler method InternalReceiveRequestAsync because the return value is never used. I think I need to change error handling in general in InternalReceiveRequestAsync (both for Modbus TCP and RTU) because when a TimeoutException occurs no frame should be processed at all. It should simply continue looping.

@Apollo3zehn Apollo3zehn changed the base branch from master to dev September 7, 2022 11:11
@Apollo3zehn Apollo3zehn changed the base branch from dev to master September 7, 2022 11:43
@Apollo3zehn Apollo3zehn changed the base branch from master to dev September 7, 2022 11:43
@Apollo3zehn Apollo3zehn merged commit 2617eff into Apollo3zehn:dev Sep 7, 2022
@Apollo3zehn
Copy link
Owner

I have removed the Line UnitIdentifier = 255 because I do not understand why it is required. However I will now work on a better error handling in that method so hopefully your issue are solved anyway.

@LukasKarel LukasKarel deleted the hotfix/serial branch September 9, 2022 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants