Ascii Checksum In A PLC ?

Has anyone ever had to program a checksum subroutine in a PLC?

I have to communicate with a proprietary Viscometer using RS-232 ASCII, basically like sending a CSV file with commas and alpha-numeric characters.

I'm guessing that I'll need to program a lookup table to associate all of the ASCII characters with their values, then run through a routine of adding each individual integer together for each character of the string, including commas.

If anyone has done anything like this, any direction or samples woud be greatly appreciated!


RS-232 serial COM port settings:
9600 baud.
8 data bits.
No parity.
1 stop bit.
No flow control.
Carriage return is used as the End character.

The commas are sent as part of the response and are necessary to know the length of the data fields, since they are variable.

All data coming from the Viscometer are formatted as text strings – that is to say that they are not in HEX or Octal. As an example, the value 2.25 would not come across as a 32-bit FLOAT value, but are rather sent as the text equivalent: the number 2 followed by a decimal followed by another 2 and a 5.

Checksum will be an integer value, also in text format, that will be the sum of all characters sent, but not including the End character (Carriage Return).

Here’s a basic overview of the RS232 requirements for the device that needs the checksum:

General Legend:
<ST> : status byte
<CR> : carriage return
<CS> : checksum
NOTES:
-The brackets are not actually sent and received. They are used here strictly for readability.
-The status byte is sent as 3 ASCII characters representing the decimal value of the status byte.
-The checksum is always sent by the transmitting side. It is the sum of the ASCII values of each character in the sent string, including the status byte but not the carriage return.
Example: gpk

Sample Command
Name: Get Status Values
Command: GSV,<CS>,<CR>
Response: GSV, speed, %torque, motor error, srate,
sstress, viscosity, <ST>,<CS>,<CR>
Function: Retrieves current value of raw parameters.
Legend: GSV - command mnemonic
speed - motor speed (rpm)
%torque - torque (0-100%)
motor error - latched motor error code
srate - shear rate(1/s)
sstress - shear stress (lb-f/100ft^2)
viscosity - viscosity (cP)

Status Byte (ST) Description
Bit 7 6 5 4 3 2 1 0

Invalid Speed 1 0 0 0 0 0 0 0
Test Start
Received with
No Test Loaded 0 1 0 0 0 0 0 0
Invalid Command
Received 0 0 1 0 0 0 0 0
Test Executing 0 0 0 1 0 0 0 0
General Error 0 0 0 0 1 0 0 0
Future Use 0 0 0 0 0 0 0 0
Future Use 0 0 0 0 0 0 0 0
Motor Error 0 0 0 0 0 0 0 1


NOTES:
1)Bit 7 (invalid speed) – set in response to a TSP test
step command if the speed is outside of the limits set
via the SSL command.
2)Bit 6 (test start rcv’d with no test) – Set in response
to a TST (mode 1) if no test steps have been loaded into
memory and/or no test configuration name has been set.
3)Bit 5 (invalid command) – set in response to any unknown
command.
4)Bit 4 (test executing) – any responses from the
controller while the test is executing will have this bit
set.
5)Bit 3 – this bit is reserved for general errors.
6)Bits 1 to 2 – reserved for future use.
7)Bit 0 – set in response to a motor error (use the GSV
{Get Status Values} command and read the motor error
parameter to determine the actual error.
8)Multiple errors may be present at the same time.

“A thousand miles can be so many ways: just to know who is driving, what a help it would be.”*

Which PLC? This will influence how the checksum is generated and how the data gets into and out of the PLC. Each brand has instructions more or less capable of doing what you want.

Fr'instance, in a PLC-5 you wouldn't need a lookup table if all you're after is a simple sum. The FAL instruction could scan through the whole string and add all the character values - if the string is on a one-character-per-word basis - in one fell swoop. Other PLCs with different instructions would probably use a similar approach.

Enter "checksum algorithms" in a search engine and see what turns up.


* -- from “I’m Just a Singer (in a Rock and Roll Band)” by The Moody Blues

Siemens S7-312C-2 PtP. They don't seem to have any built-in functionality, so I'm having to do it myself. Hence the question of how to go about it.

Good thought, though.

Maybe I am not understanding the problem here but surely the data in the PLC consists of the ASCII values which you need to calculate the checksum. These are only displayed as characters on your PC. I have never tried to do this on a Siemens PLC but have done it on a number of others and I think you might be worried unnecessarily about a relatively simple task.

You simply have to program a checksum generating sets of rungs.

So youll have 3 definite sets of rungs

1.To input the data to be sent in the checksum

2. To format your ASCII string including the sum

3. To SEND the string through the serial port.

This not being any time critical you can test them and modify individually.

Be carefull of what the word Checksum really means. There is a lot of $hit on the net about the algorythms and how they behave. Get the specs from the devices manufacturers.

4. Don't forget the Receiving part, you must check if the device has accepted your string.

Perhaps you will have to re-send the string a few times.

I have done ASCII checksum checking in an S5, I have never had to do it in an S7, I assume it wouldn't be much different, you just might have to 'pad out' the bytes with zero's to turn them into words for the +I function.


In S5 it was as follows (cut down a bit as our ASCII messages are 48 bytes long and the algorithm is also a bit long)

 

C DB100 //open the datablock where ASCII message is stored

L DL1 //load Byte 3 (DW0 contained zeros for spacing out message)

L DR1 //load byte 4

+F //fixed point addition

T DW100 // store the result in DW100

L DL2 //load Byte 5

L DR2 //load byte 6

+F //add them together

T DW101 //Store the result in DW101

L DW100 //load previous result

+F //add them together

T DW101 //Store the result in DW101 (this is now the running total)

L DL3 //load byte 7

L DR3 //load byte 8

+F //add them together

T DW100 //store the result in DW100

L DW101 //load the running total

+F // add the result of DL3 + DL4 to the running total

T DW101 // Store the result back to DW101

So on and so forth, until all the bytes have been added together.

Is that any help?

Paul

P.S In case you are interested the algorithm I had to duplicate in the PLC was as follows (taken from our series six ASCII/basic module program:-

CS%=0 : FOR I = 1 TO 43: MID$=MSAGE$[I,1]:CS%=CS%+ASC%(MID$):NEXT I
CS%=0(CS%+((CS% AND 192)/64)) AND 63
CHK2$=CHR$(CS% + 32)

There are various ways that people calculate checksums, and the main thing is to do it the same way the other guy is doing it. The last time I had to do a checksum calc was on a message that varied in length every time. So, I had to loop through the message byte by byte with the loop command. It was accumulated in a dint, and then I did a MOD on the result. Here's a snippet: