ASCII Checksum in a PLC

[CGehlhausen]

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.

 

[NWBeaver]

Looks like you are on the right track.

I've done some programs dealing with ASCII devices before, although in my case the messages I was sending were "canned" such that I only had to determine the checksums once for each string to be sent to the device.

I used the same approach that you have suggested, passing the data received from the device through a subroutine which converted the ASCII values and returned a binary value.

If I read this correctly, it sounds like your application has variable length messages being both transmitted and received, so your program just needs to be able to detect the beginning and ending characters, as well as the delimiting commas.

Sorry I don't have the programs I wrote available, but will give what help I can if needed.

 

[msward]

It depends on which PLC you are using. If it was a SLC500 I would add a basic module which makes ASCII handing operations very easy.

Regards Mike

 

[Skogsgurra]

Regardless of PLC make, the possibility of adding a little C, Basic or FORTH programmable unit seems to be the simplest way of doing it. PLCs are not good at these things. There are boards with parallel I/O for the PLC and RS232 or 485 for the communication side. Boards that can be very easily taught to do what ever your needs are.

Examples are the "stamps" from NewMicro or Parallax. They may need level buffers for your application. There are also boards with the needed 12 or 24 V I/O, but the supplier escapes me right now.


Gunnar Englund

http://www.gke.org