Fix signedness handling for EL3XXX and EL4XXX terminals #67
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Both signed and unsigned representations behave like a signed 16-bit integer. In the case of unsigned, the value is limited to the range 0-32767, the former is limited to -32768-32767. As such, treating the values from the terminal as int16 (and thus sign extending them when assigning to RVAL) is the correct way of doing things. This does not handle the MSB representation properly however. That will require more work down the line if we ever decide to support it. For now, users will need to use the unsigned or signed representations for the data to be correctly read.
Merged
marciodo
approved these changes
Aug 1, 2024
|
Confirmed working in TMO. With the help of Tong, tested negative temperatures on EL3314 and pos/neg output on bipolar analog output terminals. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For analog input terminals, both signed and unsigned representations behave like a signed 16-bit integer. In the case of unsigned, the value is limited to the range 0-32767, the former is limited to -32768-32767. As such, treating the values from the device as int16 (and thus sign extending it when assigning to RVAL) is the correct way of doing things.
MSB representation is still not handled in this PR.
For analog output terminals, signed behaves as described above, but unsigned has the full range you would expect: 0-65k. To improve support for this, I've chosen a middle ground-- bipolar terminals will assume the PDO is signed and unipolar terminals will assume it is unsigned. Since unipolar terminals with the signed PDO can only have values 0-32k, it is safe to treat them as
uint16.The one drawback here is the unsigned PDO type will not behave correctly if it's set on a bipolar terminal. I suspect this is a rare use-case anyways, though.
More context on #45