10-16-2018 09:58 AM
10-16-2018 09:58 AM
@RTSLVU wrote:
BTW: I know mine works as I have used it with more than one device that required a CRC-16
It works for your situation. As I have stated many times, there are many, many ways to do a CRC. Even my generic CRC VI has to be altered for some of the CRC algorithms I have come across on these forums.
10-16-2018 10:02 AM - edited 10-16-2018 10:03 AM
Good point as it is Modbus CRC-16 and you are right there are a few different ways to calculate a CRC-16
But my last reply still stands, unless the OP is willing to abandon the DLL, this is not really a LabVIEW question.
10-16-2018 10:04 AM - edited 10-16-2018 10:19 AM
According to (http://reveng.sourceforge.net/crc-catalogue/16.htm), ITU-t uses the X-25 Protocol
EDIT: I may be wrong on this assumption!!
X-25
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e residue=0xf0b8 name="X-25"
Here is a VI that implements this configuration (CRC for "123456789" is 0x906e). You didn't include any examples of the data that worked, along with the ones that didn't work. If you could provide some examples WITH the correct CRC values.
Mark_Yedinak beat me to it with a LUT method. If the ITU does use a the X-25 protocol, then I don't think his method reverses the final bits (refout=true) and does not do a xorout=0xffff (but I may be mistaken). However, it would be an easy addition to his code. Won't know if either method works without any examples from the OP.
10-16-2018 10:21 AM
Thanks for the suggestions, I haven't had time to implement any as of yet.
Here are some examples attached...
The message being sent is highlighted in yellow and the crc is calculated with the first 2 bytes omitted (the start byte and slave address) and the last 2 bytes are the checksum expected to be generated.
Hope this helps
10-16-2018 02:27 PM
Here is a modified version of my earlier code that works for your examples.
The initial value should be 0x0000, the polynomial should be 0x1021 and the value is the CRC-16 value, not the augmented value. The table in your previous documentation does not match the polynomial in the document. However, the above code works correctly for the examples you posted.
10-16-2018 03:05 PM
I did some experimentation on how efficient the two methods were and if your data size is about 60 bytes or less, jamiva's method is more efficient. Once the data size gets larger, the lookup table method I posted is much more efficient. Here are some averages I calculated.
Data size = 10, LUT avg = 0.0000207s, Calculation method avg = 0.0000111s
Data size = 100, LUT avg = 0.0000251s, Calculation method avg = 0.0000361s
Data size = 1000, LUT avg = 0.0000581s, Calculation method avg = 0.0003332s
Data size = 10000, LUT avg = 0.0002564s, Calculation method avg = 0.0028020s
Data size = 100000, LUT avg = 0.0012553s, Calculation method avg = 0.0153443s
10-17-2018 03:22 AM
Thanks for the help, I just need to now take what you have all posted and try it out for myself.
@Mark_Yedinak could you possibly send the vi for what you have created ?
Thanks.
10-17-2018 09:04 AM
@CCloggie wrote:
Thanks for the help, I just need to now take what you have all posted and try it out for myself.
@Mark_Yedinak could you possibly send the vi for what you have created ?
Thanks.
Here is Mark Yedinak's code (I don't want to take credit for his work. Give him the Kudos). I just stripped it down to the bare minimum for your particular application. Mark's snippet didn't contain the subVI to generate the Lookup Table, so I just inserted an array constant instead.
BTW, the VI in my previous post doesn't give the correct CRC with your data. I didn't bother debugging it since Mark's code works well.
10-17-2018 09:26 AM
@jamiva wrote:Here is Mark Yedinak's code (I don't want to take credit for his work. Give him the Kudos). I just stripped it down to the bare minimum for your particular application. Mark's snippet didn't contain the subVI to generate the Lookup Table, so I just inserted an array constant instead.
And I just cleaned it up a little bit more (removed the AND 0xFF and replaced with a To Unsigned Byte, which also removed the need for the To Unsigned Word).