PLC-5/250 Compute Expression

[cefisher15]

I've got a print-out of old code (PLC-5/250) that I am trying to decipher. I am hung up on an expression in one of the compute blocks. The block parameters are as follows:

COMPUTE
Dest: NUMST
Expression: I:013{07..00}+(I:013/16<<8)

Can anyone please help me understand what this expression is saying? I can take a picture of the rung if it will help, but that is all of the info from the block.

[daba]

Originally Posted by cefisher15

I've got a print-out of old code (PLC-5/250) that I am trying to decipher. I am hung up on an expression in one of the compute blocks. The block parameters are as follows:

COMPUTE
Dest: NUMST
Expression: I:013{07..00}+(I:013/16<<8)

Can anyone please help me understand what this expression is saying? I can take a picture of the rung if it will help, but that is all of the info from the block.

I think I have deciphered it, and to be fair it looks a strange one, but to be absolutely sure can you show the bit patterns of I:013 and NUMST after the compute has been executed.

[JaxGTO]

I remember the << is a bit shift left

[cefisher15]

Originally Posted by daba

I think I have deciphered it, and to be fair it looks a strange one, but to be absolutely sure can you show the bit patterns of I:013 and NUMST after the compute has been executed.

daba, Unfortunately all I have access to is a PDF file of the code. Attached is an image of the input rung and the compute block. I013 has 16 bits, as far as I can tell, this compute block is concerned with bits 0-7 and 16. It looks like NUMST is an int.

I'll dig through my PDF to see if there's any variable maps, but I seem to have lost access rights to it, so it might take a while... if its not one thing, its another, am I right?

[daba]

Originally Posted by cefisher15

daba, Unfortunately all I have access to is a PDF file of the code. Attached is an image of the input rung and the compute block. I013 has 16 bits, as far as I can tell, this compute block is concerned with bits 0-7 and 16. It looks like NUMST is an int.

I'll dig through my PDF to see if there's any variable maps, but I seem to have lost access rights to it, so it might take a while... if its not one thing, its another, am I right?

Working through it, bit by bit....

I:013{07..00} extracts the low 8 bits of the data in I:013, this seems to make sense going by the handwritten notes on the first picture - "Data"

I:013/16 will result in the data being "shifted" towards bit 0, by 4 bits (/2 will shift by one bit, /4 by 2, /8 by 3, and /16 by 5 bits). Then the <<8 will shift the above 8 bits to the left, putting what was labelled as "Index" into the upper 4 bits, bits 17..14, but it also duplicates the upper 4 bits of "Data" into bits 13..12, zeroes fill the lower 8 bits of this partial result.

After adding the partial results together, you get....

bits 17..14 = "Index"
bits 13..10 = upper 4 bits of "Data"
bits 07..04 = upper 4 bits of "Data"
bits 03..00 = lower 4 bits of "Data"

The picture shows the individual operations within the compute. You should look at this when you look at any other operations performed on CCO_NUMST

[daba]

I've just had the thought that the "/" in I:013/16 might be a bit address, not a "divide by".

It's been such a long since I looked at any PLC5/250 code that I can't remember... "Divide by" might be "|" (pipe).

PLC5/250 (Pyramid Integrator) was programmed using the very old 6200 software, I don't know if it ever made it into RSLogix5.

Anyway, if it is a bit designation, it looks like the latter part of the compute "pulls" bits 06..00 up to bits 16..10

Or, the "<<" bit shift might be circular within the destination, so it might be putting bit 16 only into bit 6 location

See if those ideas make any sense.....

[cefisher15]

Originally Posted by daba

I've just had the thought that the "/" in I:013/16 might be a bit address, not a "divide by".

It's been such a long since I looked at any PLC5/250 code that I can't remember... "Divide by" might be "|" (pipe).

PLC5/250 (Pyramid Integrator) was programmed using the very old 6200 software, I don't know if it ever made it into RSLogix5.

Anyway, if it is a bit designation, it looks like the latter part of the compute "pulls" bits 06..00 up to bits 16..10

Or, the "<<" bit shift might be circular within the destination, so it might be putting bit 16 only into bit 6 location

See if those ideas make any sense.....

Daba,

Thank you for your help! Looking at the other rungs of code, I agree that the"/" is a bit address. Taking into consideration your remarks, and what I know about the expected values of NUMST, I think the expression is basically concatenating bit 16 with bits 0-7 to make a 9-bit binary representation of a number, then storing the decimal equivalent in NUMST (see attached).

[daba]

Originally Posted by cefisher15

Daba,

Thank you for your help! Looking at the other rungs of code, I agree that the"/" is a bit address. Taking into consideration your remarks, and what I know about the expected values of NUMST, I think the expression is basically concatenating bit 16 with bits 0-7 to make a 9-bit binary representation of a number, then storing the decimal equivalent in NUMST (see attached).

Your attached image is what I was working towards with bit 16 being "rotated" left by 8 bits, but I think that it would end up in bit 6, not bit 10. In a 16-bit integer, with the bits octally addressed, bit 6 and 16 are 8 bits apart, whichever way you shift.

Perhaps the number constraints mean that it is creating a 7-bit number, with bit 6 being the sign bit ??? EDIT : I meant 7, not 9

Whatever way you look at it, it's a rare piece of programming, I'm sure there would be a better way to do, IF we could understand what it is trying to achieve !!