Calculating CRC Checksum

[bockdoug]

Please forgive me for the vagueness of this question, I don't know better...

I am programming a power supply via RS485. The manufacturer of the power supply has provided me with a manual for communicating with the device. I need to send ASCII strings (messages) via the RS485. At the end of each message I need to attach a CRC to verify the message. This is where it gets vague:

"The CRC field is two bytes unsigned char hex data in ASCII.
The CRC value is calculated by the transmitting device, which appends the CRC to the message.

The CRC is calculated by subtracting together successive eight-bit bytes of the message, discarding any carries/borrows. It is performed on the ASCII message field contents excluding 'K' at the end of the message."

So for example my initial message is "S12" (which turns on a heater connected to the power supply). On this initial message I need to calculate the CRC, attach it to the message and then end the message with an ASCII "K".
What is your interpretation of how to calculate the CRC, and how would you do that in LabView?

I have attempted this with pen and paper by "succesivley subtracting together without carries" the bytes S,1,2 and converting the outcome to Hex. Doing this I got  hex40, which would mean my message is "S1240K".

Any advice is appreciated.
Thanks
Doug

[billko]

so... did you actually try to send your message?  that's the best way of seeing if you got it right.  🙂

[billko]

Send it manually like that first.  if it worked, then you can think about calculating the crc automatically.  🙂

[bockdoug]

Tried communication yesterday. Didn't work. Not necesarily because of the CRC, though. There are some other caveats with this machine...

[billko]

This is the toughest - but sometimes the most fun - part of learning how to communicate with an instrument that you are not familiar with.

Right now I am trying to communicate with a product that whose communications protocol hasn't yet been completely defined, so no one really knows who is right and who is wrong yet.  😉

[deceased]

Is there any other information about the device that we could take a look at. The description of the process required does not sound like a CRC, in that CRCs usually involve bit shifting and conditional XORs.

It sounds more like an LRC to me, but the info is way to vague to guess what is being calculated.

[crossrulz]

---

@bockdoug wrote:

I have attempted this with pen and paper by "succesivley subtracting together without carries" the bytes S,1,2 and converting the outcome to Hex. Doing this I got  hex40, which would mean my message is "S1240K".

---

I am getting 0xF0.

[RTSLVU]

Here is a CRC vi I picked up a long time ago. It worked for me last time I needed to generate a CRC.

[deceased]

---

@RTSLVU wrote:

Here is a CRC vi I picked up a long time ago. It worked for me last time I needed to generate a CRC.

---

This is the CRC-16-IBM as used in modbus. There are loads of other variations around this theme. The usual thing that catches people out is the endianness of the CRC when appended to the message.

[bockdoug]

After sending them another email asking for a detailed example, I have arrived at what they meant:

Their reply was: 

If the message is S3C516467K

S3C5164 – checked part

67 – CRC

K – End of message

1. You take the checked part and transfer it from ASCII to HEX

    S      3       C        5       1        6       4         =>

0x53 0x33 0x43 0x35 0x31 0x36 0x34

1. You do the CRC calculation (in HEX):

0 – 53 – 33 – 43 – 35 – 31 - 36 – 34 = 0xFFFFFE67 = > 0x67

0 – part of the algorithm for the calculation

FFFFFE – carries/borrows

1. Transfer the result from HEX to ASCII

0x67 => 6 and 7 => S3C516467K

I followed this and came up with the attached algorithm.
This spits out 4A for my message of "S12" and also gives the correct CRC as in the example above.
Many thanks for all your input.