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(protocols/modbus): fix write requests for coils always set to false (#710) #711
fix(protocols/modbus): fix write requests for coils always set to false (#710) #711
Conversation
I think in this case it would then work for the coils, but break for the registers, as these are 16 bit units. I think a better solution would be to have either a dedicated DataIo for coil data (However this would have very few cases) or to not use the DataIo component for parsing the coil data, but to implement it manually (which shouldn't be much work) for this case (One could argue, that reading 8 coils and having that interpreted as a signed 8-bit integer would no longer be supported by that, but that's probably something I would be able to live with) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change will definitely break boolean support for registers.
What kind of solution did you have in mind and why would it break the functionality you're describing? |
Oh ... thought I had mentioned this on the main PR comment:
My prefered option would be the 3rd ... manually implementing the parsing of coils. |
Sorry, I wasn't clear. My comment was a response to your first comment. You said that manually implementing the parsing the coil data would break being able to interpret 8 coils as an signed 8-bit integer. I was wondering what kind of solution for manually implementing the parsing of the coil data you had in mind and how this would break that functionality. |
…ally implemented parsing of coil boolean instead (apache#710)
See my latest commit for what I had in mind. |
Hi, Yeah ... this should be a good solution. And it's way less complicated ... but happy you at least could have a look at the general concept of our code-generation ;-) Chris |
see issue-710