LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need help with CRC-16-IBM

Solved!
Go to solution
Highlighted

Hi All,

 

I have a servo-motor brand Ezi-Servo that operate by sending serial command to it.

The problem I have got is about CRC Checksum. I tried my best to do but the output was not the same as the example code they gave to me.

 

Please check my code and my VI  and  show me what I am wrong. I would appreciate so much.

 

Polynomial is x16+x15+x2+1

 

Here are the examples of right result of it's CRC16

 

6A 04 01 00   ----CRC16  = 0020

03 D9 00 00   ----CRC16  =01B0 

 

My VI is below,

Untitled.gif

0 Kudos
Message 1 of 11
(3,461 Views)
Highlighted

Does your C program even work for your instrument?  The polynomial doesn't look right at all.  And that code was made for a Watlow controller.

 

So either your given algorithm is wrong or your test sample is wrong.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 2 of 11
(3,407 Views)
Highlighted

Thank you so much, crossrulz

 

Yes the program that come with it is work. (the originated program is .cpp)

I give you the manual of it.  it has 2 code of CRC, one was i gave to you. another as I attached (using table)

 

More example :

 

0xAA 0xCC 0x00 0x35 0xE8 0x03 0x00 0x00 0xE8 0x03 0x00 0x00 ------  CRC Lo byte = 0xE2  Hi byte = 0x18

0xAA 0xCC 0x00 0x35 0x9F 0x5B 0x00 0x00 0x10 0x27 0x00 0x00  ------  CRC Lo byte = 0x0C Hi byte = 0x74

 

Please ask me if you need more information.

 

0 Kudos
Message 3 of 11
(3,373 Views)
Highlighted

It's time for you to give that manufacturer's tech support a call.  The code in that manual matches exactly with a Watlow CRC I have, but your test codes do not match at all.

 

0xAA 0xCC 0x00 0x35 0xE8 0x03 0x00 0x00 0xE8 0x03 0x00 0x00 -> 0x9E80

0xAA 0xCC 0x00 0x35 0x9F 0x5B 0x00 0x00 0x10 0x27 0x00 0x00 -> 0xF65A


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 4 of 11
(3,326 Views)
Highlighted

Cross what Polynom code are you using for your CRC16? I have a couple of different versions and when I set them up to use xA001 as the polynom code they don't result in the same outputs as yours, yet I have used  them effectively in several different projects.

 

My results are:

0xAA 0xCC 0x00 0x35 0xE8 0x03 0x00 0x00 0xE8 0x03 0x00 0x00 -> 0xAE97

0xAA 0xCC 0x00 0x35 0x9F 0x5B 0x00 0x00 0x10 0x27 0x00 0x00 -> 0x40FB

 

 

Message 5 of 11
(3,309 Views)
Highlighted

Ok, I must have mistyped something somewhere before.  But our result still isn't what the OP was expecting.

 

I just used the CRC VI from the Watlow modbus driver library.  No need to write my own if the work was already done for me.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 6 of 11
(3,300 Views)
Highlighted

I'm really not sure about those response values...

 

Assuming my CRC works correctly which it should, which is identically to the way that OPs should work, I ran some tests and found no Polynomial that produced the both of those results.

Message 7 of 11
(3,289 Views)
Highlighted

Thank you so much for all of your kind help.

I will contact to the product manufacture soonly to get the right crc calculation and will share you here the solution.

 

0 Kudos
Message 8 of 11
(3,278 Views)
Highlighted
Solution
Accepted by lovemachinez

Hi,

 

Regarding to our mismatch result comparing to the C-program. I have already talked with the product supporter.

The CRC algorithm is CRC-16 Modbus, same as we used.

 

The cause that we got wrong with the result is  they did not calculated CRC from the whole packet.  they cut some part of it out (example: header, address etc..) and calculate only the data part.

 

So I appreciate all of you guy for helping me solved the problem.

 

Thank you so much.

0 Kudos
Message 9 of 11
(3,238 Views)
Highlighted

lovemachinez wrote:

The cause that we got wrong with the result is  they did not calculated CRC from the whole packet.  they cut some part of it out (example: header, address etc..) and calculate only the data part.


Now that makes sense so me.  I've seen so many different kinds of CRC calculations that I've learned you have to be EXTREMELY specific on how the calculation is done.  Only doing the CRC on the data part of the message is a common thing.  Glad to hear you go it working.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 10 of 11
(3,219 Views)