Disregard OD variable description in SdoClient.upload() #592
Conversation
When an OD entry is found in SdoClient.upload(), the truncation is currently skipped only for those types explicitly listed as variable length data (domain, strings). That causes unknown types to be truncated to whatever their length indicates, which is usually one byte. Invert the condition to check all types with an explicitly known size, a.k.a. those listed in STRUCT_TYPES where the required length can be deduced from the structure format. Re-enable the unit tests which were skipped based on the previously buggy behavior.
The upload method should behave as a raw producer of byte data. Interpretation of the returned data based on the Object Dictionary is the responsibility of the SdoVariable class, which delegates to the generic ODVariable decoding functions. Move the data truncation to the method SdoVariable.get_data(), where access to the ODVariable is certain. The only truncation that still happens is based on the response size specified by the server, which might be smaller for e.g. expedited upload. Extend the upload() function docstring to clarify the changed behavior. Adjust the test case for expedited upload with unspecified size in the response, which is the only incompatible change.
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
The existing test response is actually wrong, since the standard mandates four bytes "data" regardless of the other flags.
|
Alright, this is ready for prime time with now complete test coverage. Would still like to postpone it past the next release, as it significantly changes the return value of |
| if response_size and response_size < len(data): | ||
| data = data[:response_size] |
There was a problem hiding this comment.
I'm a little conflicted on what takes precedence: The actual amount of data transferred in the SDO, or the data size indicated by the size fields. Does the 301 standard mention this at all?
There was a problem hiding this comment.
I haven't found any solution to this dilemma in the standard. My interpretation is that specifying the size in advance is the definitive answer. I doubt it will ever make a difference, as that would be a pretty awful server implementation.
In the end, what counts is the receiver's (client's) understanding of the data. And for that, the OD is needed anyway. If someone needs the full data in addition to the indicated size (to check for differences), they can just use the .open() API directly, without this mid-level convenience API.
There was a problem hiding this comment.
When making protocol one should hope for the best and plan for the worst and not just expect happy path. So I believe its just to figure out how to resolve when a remote server replies with odd responses.
There are datatypes which is variable, such as string (which happens to be used in the test for this PR), so the OD cannot resolve them all.
Many times I'd wished that the protocol test suite from CiA would be public so we could see how they resolve it.
There was a problem hiding this comment.
Well, one almost sound reason I could see for sending extra data would be string termination. For convenience, the size might indicate the string length, but the data could be extended to include a NUL terminator byte. Which kind of makes sense in a C-based implementation.
Anyway, since there is already an alternative API in this library (file stream), let's wait and see if anybody comes back complaining about this change. I doubt many people are even using this API directly.
|
Anyway, this is v3.0.0 stuff by the way. #594 has higher priority on my agenda, then getting out the release. |
The upload method should behave as a raw producer of byte data.
Interpretation of the returned data based on the Object Dictionary is
the responsibility of the
SdoVariableclass, which delegates to thegeneric
ODVariabledecoding functions.Move the data truncation to the method
SdoVariable.get_data(), whereaccess to the
ODVariableis certain.The only truncation that still happens is based on the response size
specified by the server, which might be smaller for e.g. expedited
upload. Extend the
upload()function docstring to clarify the changedbehavior. Adjust the test case for expedited upload with unspecified
size in the response, which is the only incompatible change.
This is based on, and includes the changes of, #591.