2s complement of a string

[crelf]

So I need to suffix a string with a CRC, and the manual that I'm working with is very sparse on details:

Checksum must be formed and added to each command. The checksum is the two’s complement. The checksum itself is in BYTE format and thus it may rotate over the max value upon calculation.

Yep, that's really about all I know

So, for the following ASCII string example:

PLPARM0001:05:0004=00000032

the manual tells me that the 2s complement is 0x2E.

So I know how to do a 2s complement of numbers, and I can think of several ways to do it to a string (or, at least, representations of that string), but does anyone out there know the "right" way to do this before I try to brute force it?

[todd]

How about this?

[jcarmody]

That made me smile. I just had to try it.

[asbo]

OT: Does the Code Capture Tool let you grab control/indicators from the front panel too, or did you edit that in?

[Darin]

Of course if you append the checksum to the string and run it through the same code you'll see it's purpose. To save the trouble in this case you only have to figure out what x XOR x is.

[crelf]

How about this?

Nice work todd - that's exactly what I needed! Nothin' like LAVA to feel humbled

OT: Does the Code Capture Tool let you grab control/indicators from the front panel too, or did you edit that in?

It lets you grab FP nodes too, but with some property exceptions.

[Yair]

OT: Does the Code Capture Tool let you grab control/indicators from the front panel too, or did you edit that in?

Like Chris said, the CCT does allow that, as well as all kinds of options (such as the placement). There are some videos about the CCT here if you want to see the various features - http://www.screencast.com/t/ZmQ1YjIxNj

[Phillip Brooks]

8.2!

[crelf]

8.2!

Old skool!

[hooovahh]

Like Chris said...

You may want to address him as crelf only because there is more than one person in this thread, with a real life name of Chris.

[asbo]

You may want to address him as crelf only because there is more than one person in this thread, with a real life name of Chris.

I was just going to let him give me credit for it...

[jcarmody]

8.2!

Use the GetSnippet RCF plugin to extract snippets in LabVIEW 8.2 and above

[crelf]

You may want to address him as crelf only because there is more than one person in this thread, with a real life name of Chris.

There are?!?

[ShaunR]

As an aside.......

2's compliment as a CRC really sucks. For example, just try entering the string

PLPARM01:0500000000:0400=32

[/CODE]

[crelf]

As an aside.......

2's compliment as a CRC really sucks. For example, just try entering the string

PLPARM01:0500000000:0400=32

[/CODE]
Well, one could argue that any CRC sucks, as there aren't completely mutually-exclusive signatures for all possible permutations of a string input.  I'm not saying it's the best CRC, but it's better than nothing in most practical cases, and it's what the COTS hardware manufacturer chose, so I'm stuck with it.

[hooovahh]

Well, one could argue that any CRC sucks, as there aren't completely mutually-exclusive signatures for all possible permutations of a string input.

This is an important thing to remember. Any CRC/checksum method will have multiple messages generate the same result. There are an infinite number of strings that will return the same MD5Sum for example. The likelihood of having two random strings generate the same MD5Sum is 1 in 340,000,000,000,000,000,000,000,000,000,000,000,000 (rounded down). Similar things can be said for GUIDs.

There have been several attempts to break MD5 in a systematic way and I believe someone was able to but I can't seem to find the example at the moment. The example was a EXE that when ran would say "Hello Wold". Then there was a second EXE with the same MD5 and when it was ran it would say something else.

[ShaunR]

Well, one could argue that any CRC sucks, as there aren't completely mutually-exclusive signatures for all possible permutations of a string input. I'm not saying it's the best CRC, but it's better than nothing in most practical cases, and it's what the COTS hardware manufacturer chose, so I'm stuck with it.

Well. Some are better than others. But a single byte (max 256 permutations) coupled with 2's compliment yields many more collisions than is useful.

[crelf]

Some are better than others.

Agreed.

But a single byte (max 256 permutations) coupled with 2's compliment yields many more collisions than is useful.

Not agreed - it's certainly very weak, but that doesn't mean that it isn't useful as a really gross check. The data that I'm sending/receiving has type checks on either side, so coupled with that, this CRC method is okay as a gross indicator step of a multi-step check. I certainly wouldn't suggest it for important or deterministic streams, especially if it's the only check used.

Anyway, if I'd designed the system I wouldn't have chosen it, but I'm not going to call up the hardware vendor and tell them I refuse to use their hardware just because their CRC isn't up to snuff.

[crelf]

A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944).

btw: love it!

[patleb]

good Todd

pat

[Phillip Brooks]

A weak CRC is better than NO CRC over an unreliable transport.

Remember that for many years (decades) most devices RECEIVING the message were classically very resource or processor limited and simple bitwise checks on the receiver are low overhead.

If the device in question is using anything other than RS232/485 then I'm guessing somebody wrapped a dinosaur in a box, hid a "XYZ to RS232" converter in it and called the product "New and improved" with a price tag disproportionate to the cost.

I can make such a statement only because I've been an unwilling contributor to such a thing.