Time for my NOT training

[boardmaker 0]

I'll just tell the whole story. I have an encoder(BEI 256/Rev) connected to a 1746-ig-16-ttl input card with a 1747-L-514 5/01 processor. Oh by the way, I've never written a program with an encoder. I'm learning though. Anyways, the encoder count is taken and put as the source on a not function. At my home or starting position I have a count of 224. After it is NOT, the destination is -225. I'm assumming the count of zero is added hence the -225. So in binary 224 is 11100000. And it's inverse in binary then is 00011111. But thats not -225 in decimal. Right? Really that is my first question. I told everything about the encoder because I'm probably going to have more questions later. Although, without seeing the logic it might be hard for you to answer this, but why would you want to invert. I'm pretty sure all the other encoder logic I've seen uses the count straight. Just asking? I need to go work on something, but this is where I'll start.

[TConnolly 13]

Negative numbers are stored in twos complement form. Bitwise Not-ing a number does not negate the number. http://en.wikipedia.org/wiki/Two's_complement Edited 9 Jun 2006 by Alaric

[Spedley 0]

I think the encoder is probably wired as NPN rather than PNP, i.e. a 1 is represented by a low voltage - I've found this common with Japanese components (I'm no electrician but I think it allows several different voltages to be connected to one sink card and is also more reliable for testing faulty circuits) If this is so then the input 11100000 would need to be NOT'ed to convert it to to it's true value of 00011111 or decimal 63. If it is 8-bits then it's unlikely it is using negative numbers.

[Money4Nothing 0]

Alaric is correct. To find the binary negative of a number in two's complement form that is n bits long, you subtract it from 2^n. So if you have a 15 bit number, and you want its negative, subtract it from 1000 0000 0000 0000. The twos compliment of binary 0000 through 1111 can be found by doing a bitwise NOT, but beyond that you should use proper binary arithmetic. $

[boardmaker 0]

All of this I totally agree with. That is my question. I have a source from I:1.0 of 224. In binary, that would equal 11100000. So far so good. Now my destination is n7:3 and it says -225. That there is my question. Why does it say -225 when that is not true. It just not's the binary. Which is 00011111. I've followed the logic and that is what I have. So really I would not have a question if it did not say -225 in my destination. The binary is correct which is really all I should care about but I still have to know.

[Steve Bailey 118]

You're not looking at all 16 bits. Your binary from I:1.0 is actually 0000 0000 1110 0000. The inverse of that is 1111 1111 0001 1111 which equates to -225.

[Gerry 13]

I don't think so. The two's complement of zero is zero. Using one's complement, you get +/- zero.

[BobLfoot 301]

Points to you Steve for "seeing" what the rest of us , myself included, missed and that was the entire number not just the significant digits.

[Spedley 0]

Also, XOR I:1.0 255 N7:3 performs the same function as NOT the bottom 8-bits. and if you want to invert a number then subtract it from zero. There is no need to do logic unless you are working in electronics - if there is then try changing your program.

[Money4Nothing 0]

My mistake, I got a little ahead of myself. You are right. If you want the negative of a number in two's compliment from 1 to 16 (in decimal), subtract 1 and do a Bitwise NOT. $ Edited 10 Jun 2006 by Money4Nothing