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

Modify functionality of any single unit special case #98

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

ChrisProto
Copy link

@ChrisProto ChrisProto commented Sep 7, 2023

This is related to Issue #97 (which was also related to Issue #93)

This is the code that I implemented to solve the problem we had, which I described first in issue 93.

This allows special functionality when we have a single unit. It doesn't matter what the Unit Identifier of the unit is.

For TCP messages, the incoming Unit Identifier is ignored, and the spec recommends using the "insignificant" identifier, 0xFF. This means that there is a difference between the incoming Unit Identifier and the actual Unit Identifier of the defined single unit. For example, we might have defined Unit 1, but it must respond to an incoming message with Unit Identifier 1 or 0xFF. In addition, we might want to accept messages with Unit Identifier 0, which is used for broadcast. Also, we might want to accept messages from any Unit Identifier, since for TCP they can be ignored. In these cases, the incoming Unit Identifier can be several different values, but the internal unit we want to work with has an actual Unit Identifier of 1.

You will see code changes that keep track of the incoming and actual Unit Identifiers. In all cases, the Unit Identifier in the response is whatever the incoming Unit Identifier was in the request.

Miscellaneous Change: I needed to build this in a .net6 environment, so I added NET5_0_OR_GREATER to the conditional compilation lines in the ModbusTcpClient and ModbusUtils files.

Chris Protopapas added 8 commits July 18, 2023 13:52
…Identifier, or zero, or 0xFF. Optionally, allow it to ignore all incoming Unit Identifiers, which means that it will respond to all incoming messages. The Unit Identifier in the response matches the request Unit Identifier.
…receive an incoming message. Simplify the Find method as Apollo3zehn suggested.
… register so it shows up on WireShark captures.
…net5 and above. I did not modify the targets in the csproj.
…his branch. These changes include some of my changes from an earlier attempt, described in Issue Apollo3zehn#93 (single unit zero special case).  I'll need to undo some of these for my latest approach in this branch, which I'll do in the next commit.
@Apollo3zehn
Copy link
Owner

Hi, I was able to work yesterday and today on merging some merge request and closing some issues. However, this merge request is not yet being worked on because I thinks it needs some time for me to understand all code changes. Also I need to understand how this is connected to #103 where I stumbled over the problem of how to distinguish broadcast messages and normal messages, both addressed to unit 0.

I see in your commits that you have added a boolean option to explicitly enable broadcast responses, which is great and might solve the problem I encountered.

However I need to understand everything better first, before I can merge it. What I am wondering about is, if the default unit identifier of the server should be "0x00" or better "0xff" to avoid trouble with the broadcast address. And if so, it will be a new major release (v6.0.0) as this is a breaking change.

I hope I will find the time soon to also work on this merge request. Thanks for your patience.

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