# How to calculate CRC? GX Works 3 / FX5

## 25 posts in this topic

Hi,

I'm trying to use RFID reader connected to FX5 via RS485, but it needs CRC to it's transmission protocol.  I know that GX Works 3 has CRC instruction, but the problem is that it uses CRC-16 and I need CRC-CCITT. Polynomials are CRC-16 "X16 + X15 + X2 + 1" vs "X16 + X12 + X5 + 1" for CRC-CCITT.

Any idea if there is a easy / efficient way to implement this, or would it be easier to generate a table for CRCs? I think I will have something like 50-100 different messages... Thanks!

##### Share on other sites

Hi,

There is a quite simple way to calculate CRC, that is represented by any polynom, without a table. In general terms:
After XOR the following byte with the current (or initial CRC) to execute a SWAP instruction then to analyze sequentally the active status of each bit in the most byte of CRC, starting from its least bit, and if it's active to execute XOR with the appropriate word constant. The constants are individual for each bit, their values are produced basing on the appropriate polynom,  shifted for one bit for each operation.

1 person likes this

##### Share on other sites

Thanks!

It seems that I need CRC16-XMODEM, really didn't know that there is so many of different algorithms. :)

Have to dig a little deeper, seems that it's easiest to use ST-language.

##### Share on other sites
1 hour ago, Ekke said:

Thanks!

It seems that I need CRC16-XMODEM, really didn't know that there is so many of different algorithms. :)

Have to dig a little deeper, seems that it's easiest to use ST-language.

Well. Then little tips:
1. XMODEM uses the CCITT method for CRC16 calculation.
2. The traditional algorithms of CRC calculation like a bit shifting or a table are not effective for implementation in PLCs and MCUs, because they devours a scan time (shifting) or a memory (table).
3. The ST language gives a worst result than the LD/FBD, because the first language uses an universal compiler, written by a PC programmer that even did not understand that the computing resourses are important to save.

When I will have a free time I could help you with effective PLC code...

1 person likes this

##### Share on other sites
On 02/07/2019 at 9:35 AM, Inntele said:

Well. Then little tips:
1. XMODEM uses the CCITT method for CRC16 calculation.
2. The traditional algorithms of CRC calculation like a bit shifting or a table are not effective for implementation in PLCs and MCUs, because they devours a scan time (shifting) or a memory (table).
3. The ST language gives a worst result than the LD/FBD, because the first language uses an universal compiler, written by a PC programmer that even did not understand that the computing resourses are important to save.

When I will have a free time I could help you with effective PLC code...

Hmm.. I have mainly used FBD but not for this kind of calculations. Not sure how that would be more effective to do without bit shifting since I think all examples I found have been done that way. :)

I got those RFID readers today and configured them to RS485 bus so I can start testing. Well, not really releated to CRC-calculation but anyway.. :D

##### Share on other sites

Below you can find a five minutes code sample of Modbus CRC16 calculation, written in GX Developer and suitable for FX2N and above PLC models (including FX5, if to replace M8000 with SM8000 and CJ P63 to GOEND), that supports SWAP instruction.

Modbus_CRC16_calculation_sample.zip

1 person likes this

##### Share on other sites
On 7/4/2019 at 3:45 AM, Inntele said:

Below you can find a five minutes code sample of Modbus CRC16 calculation, written in GX Developer and suitable for FX2N and above PLC models (including FX5, if to replace M8000 with SM8000 and CJ P63 to GOEND), that supports SWAP instruction.

Modbus_CRC16_calculation_sample.zip

It seems that I don't have GX Developer nor license to it, could you print that project to pdf or take screenshots from it? :)

##### Share on other sites

Well, found a demo and transfered your project to GX Works 3. Now if I input D1 = H0012 and D0 = 1, I get K4M0 = H4D3F running in FX5.

And https://crccalc.com/ gives 0x4D3F for CRC-16/MODBUS when input is 12 / Hex.

But didn't get any right results with anything above 1 for D0. Maybe I will figure it out some day, this was just a quick test. Thanks! :)

##### Share on other sites
29 minutes ago, Ekke said:

Well, found a demo and transfered your project to GX Works 3. Now if I input D1 = H0012 and D0 = 1, I get K4M0 = H4D3F running in FX5.

And https://crccalc.com/ gives 0x4D3F for CRC-16/MODBUS when input is 12 / Hex.

But didn't get any right results with anything above 1 for D0. Maybe I will figure it out some day, this was just a quick test. Thanks! :)

The sample, I shared for you, is restricted for CRC calculation in 8-bit mode, i.e. for low-byte data...

1 hour ago, Ekke said:

It seems that I don't have GX Developer nor license to it, could you print that project to pdf or take screenshots from it? :)

It sounds strange, because if you have a GX Works3, you have both GX Works2 and GX Developer in complect too.

##### Share on other sites

Ok, so D0 = 2 and D1 = H0012 & D2 = H0034 gives me K4M0 HC70C.

And that crccalc.com gives  1234 = 0xC70C

Seems to work, so maybe just need to figure out how to change that polynom.. :)

##### Share on other sites
3 minutes ago, Ekke said:

Ok, so D0 = 2 and D1 = H0012 & D2 = H0034 gives me K4M0 HC70C.

And that crccalc.com gives  1234 = 0xC70C

Seems to work, so maybe just need to figure out how to change that polynom.. :)

Not only. The algorithm of CRC16-XMODEM calculation is reversed to MODBUS.

##### Share on other sites
5 minutes ago, Inntele said:

Not only. The algorithm of CRC16-XMODEM calculation is reversed to MODBUS.

Heh.. And since I don't have a clue how that works and why it uses H2001 and those other hexanumbes, I might just do it in ST.. :D

##### Share on other sites
10 minutes ago, Ekke said:

Heh.. And since I don't have a clue how that works and why it uses H2001 and those other hexanumbes, I might just do it in ST.. :D

I've described it very detailed in the article  https://habr.com/ru/post/359146/ . If you know Russian, you can read.

1 person likes this

##### Share on other sites
4 minutes ago, Inntele said:

I've described it very detailed in the article  https://habr.com/ru/post/359146/ . If you know Russian, you can read.

Sadly I can't and Google Translate didn't help that much either.. XMODEM didn't seem to be that much harder to you. :D

Any change you could share that/those example(s) too? ;)

##### Share on other sites
Just now, Ekke said:

Any change you could share that/those example(s) too? ;)

@Ekke

I'd like:
2. In order for you to understand thoroughly, using the example, given to you, exactly how it works.
3. To spend time studying the principles of calculating the checksum, and not to search for ready-made solutions in Internet !

I managed to understand the principle of calculating the CRC16-XMODEM and realize your task, because:
1. I've not only optimized the algorithm of CRC calculation for PLC, but, most importantly, I understand how to calculate checksums.
2. Found on the Internet a description of the shift algorithm for calculating the required checksum.
3. I achieved the result, that is desired for you, by method of probes and mistakes.

And:
1. With my help you could got the same result for the same time, if spent you time for learning the issue.
2  I dare to remind you:

On 27.06.2019 at 11:36 AM, Ekke said:

Any idea if there is a easy / efficient way to implement this, or would it be easier to generate a table for CRCs?

1 person likes this

##### Share on other sites
2 minutes ago, Inntele said:

@Ekke

I'd like:
2. In order for you to understand thoroughly, using the example, given to you, exactly how it works.
3. To spend time studying the principles of calculating the checksum, and not to search for ready-made solutions in Internet !

I managed to understand the principle of calculating the CRC16-XMODEM and realize your task, because:
1. I've not only optimized the algorithm of CRC calculation for PLC, but, most importantly, I understand how to calculate checksums.
2. Found on the Internet a description of the shift algorithm for calculating the required checksum.
3. I achieved the result, that is desired for you, by method of probes and mistakes.

And:
1. With my help you could got the same result for the same time, if spent you time for learning the issue.
2  I dare to remind you:

Ok. thanks for the help! I will figure it out someday. :)

CRC isn't that much in my interest, just have to calculate it since these RFIDs uses it. I think I could live without it in this project, but there isn't any way to turn it off..

##### Share on other sites

Posted (edited)

34 minutes ago, Ekke said:

Ok. thanks for the help! I will figure it out someday. :)

CRC isn't that much in my interest, just have to calculate it since these RFIDs uses it. I think I could live without it in this project, but there isn't any way to turn it off..

It sounds like the RFID is the last project in your engineering life and then you will become a pensioner  ;D

Edited by Inntele

##### Share on other sites
2 minutes ago, Inntele said:

It sounds like the RFID is the last project in you engineering life and then you will become a pensioner  ;D

That would be nice ;)

1 person likes this

##### Share on other sites

Read some info from there and decided to replicate that table routine with FB...

Seems to be working at least some values:

Seems to take some ms to run, but at least it works. :)

##### Share on other sites
16 minutes ago, Ekke said:

Seems to take some ms to run, but at least it works. :)

The key problem is in this. At present you are processing only very short messages. When the length of messages will increase, the scan time will stretch, that may affect (will effect) to control processes. Despite on it's just a one of sources of input data for control process...

##### Share on other sites
7 minutes ago, Inntele said:

The key problem is in this. At present you are processing only very short messages. When the length of messages will increase, the scan time will stretch, that may affect (will effect) to control processes. Despite on it's just a one of sources of input data for control process...

I understand that it's slower than your method, but don't have the knowledge to get it to work with xmodem. I tried, but gave up since there was a simpler option. :)

It seemed that I kinda got hang of it how it works on CRC16-modbus, how that "1001" bit sequence is "moved" with one position in all those M8-M15 with different hex-values (240-9000 and 2001)...

##### Share on other sites
31 minutes ago, Ekke said:

It seemed that I kinda got hang of it how it works on CRC16-modbus, how that "1001" bit sequence is "moved" with one position in all those M8-M15 with different hex-values (240-9000 and 2001)...

OK

On 05.07.2019 at 0:52 PM, Inntele said:

Not only. The algorithm of CRC16-XMODEM calculation is reversed to MODBUS.

Differences between Modbus CRC16 and XModem CRC16:

Modbus:
XOR the data byte with low byte of CRC
Right shifting

XModem
XOR the data byte with high byte of CRC
Left shifting