ASCII string validation with SLC 5/04

Am I trying to do something that is already done for me?

We are setting up communications between a SLC 5/04 and an Opto 22 Brain using serial communications.
The basic premis is the transmission of an ASCII string to and from the PLC which shares the data needed.

My concern comes in the error proofing of this string between the 2 controllers. Do I need to create a check sum routine inside the Ladder logic to validate the string?
Does the CRC option for the channel 1 port allready do this for me?

Does anyone have any ideas or insight into this issue?

Thanks in advance,

Tim

Channel 1 on the SLC 5/04 is DH+, so the Opto 22 brain board would need to support this protocol.

Channel 0 on the SLC 5/04 has ASCII support and would be, I would imagine, the port you would need to use. If you are using raw ASCII strings back and forth, you would need to perform your own checksum. The CRC selection you see on the Channel 0 port configuration is for the DF1 protocol. You may want to also see if Opto 22 supports DF1. This would be more robust than your own serial strings going back and forth.

Please excuse the mistake...

Channel 0 is what we are trying to use.
Thanks for the quick response.
Does anyone have a ladder that runs a checksum. I have built one that does a character count but I was wanting something with a little more reliablility in the check.

Thanks
Tim

CRC

Generating CRC check sum within the ladder logic is
going to be a challenge. I am not saying that it can't be done but it's going to be a challenge.
I have done CRC in assembly, c, and VB but never in ladder.
It would seem that the PLC has all instructions that would be needed.
Namely bit shifting (BSR) and XOR.
BCC check sum is much simpler, that shouldn't be that bad.
Both BCC and CRC come in different flavors. Allen Bradley's DF1
manual has examples of how to implement algorithms for both BCC and CRC. www.Modbus.ORG also lists CRC algorithm used in the Modbus protocol.
I would think that a simple BCC calculation is the way to go.
You should also think about including a rudimentary timeout.