Checksum question

[fretwire]

Does a change in the program always equal a checksum change? For instance, if I change a timer preset from 10 to 15 does the checksum change? How about in a shift register, if the program is uploaded with the SR bit, say at position 5 and the next time position 10, does the checksum change? Sorry if this has already been posted but my search found nothing like this question. Thanks.

 

[Bit_Bucket_07]

Does a change in the program always equal a checksum change? For instance, if I change a timer preset from 10 to 15 does the checksum change? How about in a shift register, if the program is uploaded with the SR bit, say at position 5 and the next time position 10, does the checksum change? Sorry if this has already been posted but my search found nothing like this question. Thanks.

The various checksum algorithms have a very high probability of returning a different value if the slightest change occurs in the source file, but it is not absolutely impossible to make program changes that would not change the output value of a checksum calculation.

https://en.wikipedia.org/wiki/Checksum

 

[RussB]

But if a slight change is not flaged, one may as well not use a checksum. IMHO

 

[Bit_Bucket_07]

But if a slight change is not flaged, one may as well not use a checksum. IMHO

Slight changes are flagged, in almost every instance. That said, a significant change could conceivably return an unchanged result from the prior checksum.

That a file's checksum matches is still quite significant, in spite of the fact that the checksum result itself may not be an absolutely unique value. There is a very low overall probability of a false positive.

 

[RussB]

IMHO; Checksums are best used in communications for packet checking as there are better ways to verify file integrity.

 

[Geospark]

Does a change in the program always equal a checksum change? For instance, if I change a timer preset from 10 to 15 does the checksum change? How about in a shift register, if the program is uploaded with the SR bit, say at position 5 and the next time position 10, does the checksum change? Sorry if this has already been posted but my search found nothing like this question. Thanks.

Hi and welcome to the Forum!

If this is not a general inquiry, then it would be more helpful if you specified which PLC brand and platform you are referring to. It may make a difference.

For RockwellAutomation/Allen Bradley processors...

The project, or program checksum is changed whenever a change occurs to the ladder logic code, or other language code (Logix 5000), the Data Table file numbers, their sizes or types (Logix 500), tag addressing edits (Logix 5000), etc. But the checksum is not changed when Data Table address (Logix 500) or Tag (Logix 5000) values are changed.

Regards,
George

 

[Peter Nachtwey]

The checksum will change if only ONE byte is changed. It is possible to change a 16 number that adds one to the least significant byte and adds one to the most significant byte so the sum does not change. CRCs are better. I use 32 bit CRCs when I have an option.

 

[fretwire]

Thanks for everyone's replies. This question was about RS Logix 500 (SLC & Mircologix PLC's). The question arose from validated equipment we are transferring to our facility. The current owners assured me that no program changes were made since the controlled *.RSS files were uploaded to their server in 2008, and the checksum would prove this. Not sure I buy this verification process being 100% reliable. RS Logix has a compare utility though and this will tell the tale, but was curious about the checksum.

 

[mort81]

In your case, you could take a copy of the 2008 file and a copy of an upload and save of the current PLC. Then covert both of these *.rss copies to binary with your own known hash code and then compare the two files to each other. That way if the files are identical, then you know in fact the running PLC has the same source code. If not, then you can run the normal compare functions of the Rockwell compare tool and see if there are easily spotted differences that you would be concerned about.

I used this method in the past on some WW InTouch screens between two different servers that had different time stamps (time zones), so that I could track live changes vs. development. The same should apply for any type of file. In my InTouch case, normal compares flagged all the files all the time because of the time date stamp, but the binary of the file is the guts so to speak and would give me true results, regardless of time stamps or anything else external to the content itself.

The Rockwell compare tool is obviously faster, but if you want to be confident that it has not changed, this is what I would try for what it's worth.