Wrong received checksums in meta data

[nicostudt]

Moin,

We currently have the issue that the checksums(both app_checksum and overall_checksum) do appear to use the opposite endianness for our Sick nanoScan3 I/O . As mentioned in #126 by @YannickdeHoop the checksums are received using big endian, but neither do I see that specified in the technical specs nor in the actual meta data of the scanners.

[lenpuc]

Thanks for opening this, I will check this, since I am sure, there was a reason why it was read the other way. I will have a look into it

[chr-wurm]

Do you use theconfig_metadata service I added in https://github.com/SICKAG/sick_safetyscanners/pull/93/files? It swaps the bytes, as I did not fix the root cause in the parsing - that was done here, which I did not notice : https://github.com/SICKAG/sick_safetyscanners/pull/126/files#diff-6c2b82f3b1044e6d9084c96415d2740a466b2f2d8756c9bf9722d69859efc7e5 - both PRs were merged rather at the same time. I think we should rather change that back to non-swapping.

[nicostudt]

Do you use theconfig_metadata service I added in https://github.com/SICKAG/sick_safetyscanners/pull/93/files?

Yes, I do. The double swap is indeed unfortunate. ^^
Apart from that, I would like to know if the technical spec actually specifies the endianness like that. Maybe one of you could give me a hint with the passage in the document.

[lenpuc]

Hi, sorry for the late reply; just to clarify things now, what exactly is the issue now? Is there a double change of the order now? And the PR #142 is still necessary? Or are at different points in the Code appearing different outcomes due to multiple changes?

[nicostudt]

Hey, no problem.
I can only say that since we use the version from #142, we have no longer observed any issues with wrongly reported checksums.