Checksum

Checking on you!

Tim,
Try this and see if it matches with what your data is telling you. I think it is pretty simple but there may be other ways of calculating a checksum. In any event, the outcome is the same.
 
If you can point me to a url where I can download the manual. I'll give it a shot. Either that, or just copy the text from your manual and post it here.

Sometimes the checksum is simply the XOR of the bytes that make up the command. To calculate that, render each byte of the command in binary format, and calculate;

Checksum = (Zero XOR Byte 1)
Checksum = (Checksum XOR Byte 2)
Checksum = (Checksum XOR Byte 3)
.
.
.
Checksum = (Checksum XOR last Byte)

Then append the character code of Checksum to the command.
 
Sort of

Thanks Randy,

In fact, I'm having trouble with the particular checksum scheme used in the BRU.

As I understand it, in any given command, there is a delimiter ":", then the drive number "dd", command, "ccc", any data, and the checksum value last.

:ddccc...ck

For instance, to reset drive 0 :

:001200D

Where drive is 00, command is 120, no data, and checksum is 0D. End of text is carriage return.

Now, according to the manual, the checksum is the difference of the sum of ascii values of each character in every field, except delimeters, from 0. In other words, the checksum is part of the checksum which must total 0.

Confused?

Yeh, me too.

TM
 
There is no one method for calculating a checksum. Common methods include LRC (Linear Redundcancy Check) and CRC (Cyclic Redndancy Check) but there are others. Most checksums consist of two digits, and may be the last two digits of the sum of the ASCII character codes or any of a number of other ways of manipulating the ASCII values. Sometimes command and addresses are excluded from the checksum, sometimes not.

The manual for the specific protocol should give example checksums and the method, and many manufacturers have BASIC or C++ code for the algorithm. If you call them and beg and whine, the manufacturer will probably give you some help.
 
Steve :

Quote follows...



Command Protocol Description


The drive command protocol is similar to others in the industry. It is a master - slave protocol where the host computer is the master and the servo drive is the slave.
The command format is shown below:

Start Address Function Data Checksum End
: a a f f f d ... d c c <cr>
Each letter represents a single ASCII character. In the address, function, data, and checksum fields, the characters should all be ASCII hex values, i.e., they
should be in the range "0" through "9" and "A" through "F" (upper case only).

All commands begin with a colon (3A hex), and terminate with a carriage return (0D hex).

Host Command Description

The Address field is made up of two characters. These characters supply the address of the drive that the command is intended for. (As an example, a host
addressing drive #2 would have "02") The address field allows drive addresses from "00" through "FE", or 255 individual drives.
The Function field specifies the function number that is being commanded. Function numbers can range from "000" through "7FF", or 2048 possible functions.
The Data field provides any data necessary for the drive to implement the command, and can have a variable number of characters. When strings are used in the
data field, the ASCII character is represented by two ASCII hex characters. (For example, the "#" character is represented by "23".) For some commands, the data
field is not used.
The Checksum field contains an ASCII hex version of the 8-bit checksum of the Address, Function, and Data fields. The sum of the Address, Function, Data, and
Checksum field should result in a value of zero. When computing the sum, the characters of the Address, Function, and Data fields are summed with the 8-bit value
represented by the characters of the checksum field.

Drive Response Description

If the drive receives the host's command with a communication error (parity or checksum errors, for example), the drive does not respond. The host should assume
a communication error occurred if a response from the drive does not occur within a time-out period.
If the drive receives the command without a communication error, the response is in the same format as the host command.
The Address field contains the drive address, so the host can verify the proper drive responded.
The Function field of the response is the same as the command, unless the drive is unable to execute the command, in which case it generates an exception
function code. (Examples of exception causes are invalid function number, illegal data, etc.). An exception function code is generated from the command function
code by setting the most significant bit of the function code field. (Equivalently, it is generated by adding 800 hex to the command function code.)

The Data field contains data requested from the drive, if any. If an exception occurred, the data field is made up of two characters, which identify the type of
exception.
The Checksum field is generated in the same manner as in the host command, with the sum of the Address, Function, Data, and Checksum field set equal to zero.

Copyright © 1994-1999 Reliance Motion Control, Inc.


 
Tim, from your example string ':001200D';

ASCII code for 0 is 48, for 1 is 49, for 2 is 50
You don't include the ':' in the calculation, so:

48 + 48 + 49 + 50 + 48 = 243

256 - 243 = 13 = 0D hex

Why 256, you ask? You're dealing with bytes here, groups of 8 bits. The value 255 represents all 8 bits set. 256 means the ninth bit is set and all the rest cleared, but since we're only dealing with a group of 8 bits, you get the same result as the 'difference from zero'.

The checksum bytes are not included in the calculation.
 
Last edited:
Dear Steve,
although my device is not Electrocraft BRU servo drive, but your explaination inspired me to get the formula of my PLC, thank you very much! :) God bless you.
 

Similar Topics

Hello all, I'm trying to recreate the following checksum calculation in the PLC. The example is written in C++ of which I am not very familiar...
Replies
8
Views
3,032
PLC is Automation Direct P2000. Destination device is a servo drive. Pacific Scientific SC755 with a custom program in BASIC. I have a copy of the...
Replies
2
Views
3,974
I have a PLC connected to a modem. I can tap into the modem via ethernet and read the Modbus messages coming in. So I use Modbus Poll. I'm...
Replies
10
Views
8,071
Does a change in the program always equal a checksum change? For instance, if I change a timer preset from 10 to 15 does the checksum change...
Replies
8
Views
3,451
HI, I have doubt in allen bradely plc , am using udp communication. My aim is to find the checksum of received message. what is my problem is...
Replies
1
Views
1,628
Back
Top Bottom