Closed martijnthe closed 6 years ago
Thanks @martijnthe for your contribution. You are right, you do not need to cover all fcs in the rtu server tests.
I'll review your code on the weekend :-)
Thanks.
I just noticed the 16-bit CRCs are written in little endian order, while the rest of the protocol seems to be using big endian order. This was already the case before I started touching the code, but it seems incorrect to me.
I'll been testing with a real device soon, so I'll know soon what it's supposed to be...
Oh, just reading the spec -- oddly, the CRC does seem to be LE (!?):
The CRC field is appended to the message as the last field in the message. When this is done, the low–order byte of the field is appended first, followed by the high–order byte. The CRC high–order byte is the last byte to be sent in the message.
Yes the crc swap bytes! Did you test your code with a real device?
@stefanpoeter yes, this branch is working for me with a real device.
@martijnthe I've reviewed your code, thanks a lot.
Since this introduces RTU Server this should be version 3.1.0, can you add this to the package.json. I'll rename the branch after the merge, will then test it a bit and then publish it after I've setup a new virtual server for long-term testing.
👍
See branch v3.1.0-dev
Hi @stefanpoeter ,
I added RTU server support in this PR. I tried to re-use the existing code as much as possible by making the various TCP classes generic/common to both TCP and RTU.
The tests I added are basically a copy of the ones in
tcp-server.test.js
, which the exception that CRCs are of course part of the payloads. I also added a test case there for a bad CRC / corrupt data. I'm not sure if there's much value in "duplicating" more of the test cases. It looks liketcp-server.test.js
already covers all already.I've only tested using the unit tests. I'll be testing with actual hardware today. Fingers crossed ;)
"Fixes" #201