Ascii Checksum In A Plc

[CGehlhausen 0]

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.

[BobNorway 0]

[panic mode 246]

Are you sure about this? For example part of sent string will be checksum itself. I don't think checksum characters would be taken into account when calculating checksum. Also what is the format of the checksum? Is this field also variable length?

[BobNorway 0]

This is totaly dependent on who you talk with. Not everyone defines the string length count the same way. You need a protocol description of the ascii string you are trying to decode or make. Either you've got a fixed length string or a variable length to loop through. For the variable type you have to count bytes between start and end. Often STX (start transmition) ETX (end transmition) characters are used. Example for 5 data bytes the STX ETX are not included: Byte___ascii___hex___dec 1______STX___ 02____ 2 2______ H____ 48____ 72 3______ E____ 45____ 69 4______ L____ 4C____ 76 5______ L____ 4C____ 76 6______ O____ 4F____ 79 7_____ ETX___ 03_____ 3 8_____ CHK___ 75____ 372-255=117 The check sum is a hex value. 255 is the largest possible 8 bit value. A longer string can include more individual variables and probably has a delimiter character between values. Depending on how things are set up you may need to send an AKN (06)character if the checksum is OK. or a NAK (15) if its not. http://www.lookuptables.com/ will give you the most common characters. CR (0D) and LF (0A) are for printers and are usually not in data transmition. A word of caution. There are two common types of string storage in the world ASCII and ASCIZ. ASCII has the string length as two bytes at the begining. ASCIZ has a NUL (0) as the last byte. S7 storage uses ASCII and needs the two bytes at the beginning. An S7 DB for 8 characters takes 10 bytes! Ignore the first two bytes of a DB string when doing the checksum. S7 can pad out strings with a NULL (00) character to get a correct length. A device like a PC often uses ASCIZ and if gets a NULL byte it will stop reading the string. (sorry my tabs and spaces don't get through correctly) Edited 21 Feb 2006 by BobNorway