MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About CGehlhausen

  • Rank
    Hi, I am New!

Profile Information

  • Country United States
  1. File Name: PDF: String Parsing File Submitter: CGehlhausen File Submitted: 15 Sep 2006 File Category: PLC Sample Code Sample code for Parsing Strings - in this case taking incoming comma separated variable strings and breaking them apart. Click here to download this file
  2. PDF: String Parsing



    Sample code for Parsing Strings - in this case taking incoming comma separated variable strings and breaking them apart.
  3. 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.