PLC-5, GRT and integer Sign bit

[TheWaterboy]

in a PLC-5 the sign bit of an integer makes the GRT instruction think that -1 is greater than +1000.

I currently use bit 15 of the integer as a filter, but is there a better way to make GRT work like it really should?

 

[Mike_RH]

Could you post a screen capture of your logic? I don't have a PLC-5 handy - but the comparisons have always worked for me? What data types are you using?

 

[Lancie1]

For the PLC5, the comparison parameters can be entered as addresses, or one constant and one address. The address can be a different data type (integer, binary, hexadecimal, octal, floating-point). If the data types are different (comparing apples to oranges), the comparison may not be valid.

You can compare values of different data types, such as floating-point and integer. You should use BCD and ASCII values for display purposes. If you enter BCD or ASCII values, the processor treats those values as integers. For example, if the value at N7:2 is 10 (decimal) and the value at D9:3 is 10 (BCD), the comparison of N7:2 = D9:3 evaluates as false.

For example, 10 in BCD translates to: 0000 0000 0001 0000
and 10 in decimal translates to: 0000 0000 0000 1010

The parameters you enter are program constants or logical addresses of the values you want to compare.

Hexadecimal, binary, or octal numbers can be entered by typing the number and following with an "H" for hex, "B" for binary, or "O" for octal. For example, to enter hexadecimal A (decimal 10) the proper syntax would be AH.
© Rockwell Software Inc.

 

[Mike_RH]

Waterboy - check your data types. I was so curious I searched out a PLC-5 and tried it. Works fine for me.

 

[Mickey]

I currently use bit 15 of the integer as a filter

Can you explain this?

 

[TheWaterboy]

Here is the logic


Mickey - Bit 15 winds up being the sign bit of an integer, so when it is set I just zero the value. [I just noticed in this example I am using the wrong word, I should have used N11:4/15. Please pretend I did ]

The source datatype is integer (N11:4) and is from an AI module. The compared value (N100:46) is also an integer. You can see N11:4 is a negative number now.

N11:4 is scaled in the AI module 0-2000, and occaisionally the value goes below 0 when there is no flow and the instrument dips below 4ma.

 

[Mike_RH]

Waterboy, Your code without the branch around the LEQ works fine. You do not the branch with the XIC. If it is not working there is something else going on in the program.

 

[TConnolly]

If you have the addresses right then the compare should work just fine. GRT is a computer instruction. It does not know or care what other things you are doing with the address. See my sigline.

Incidentally, if this an enhanced PLC/5 then you can take advantage of the very handy INV instruction and make the rung simpler.

---+GRT----+-------+---------+MOV-------+-

   | N11:4 |       |         |    N11:4 |

   |     9 |       |         |  N100:46 |     

   +-------+       |         +----------+

                   |

                   +--[INV]--+CLR-------+- 

                             |   N100:46|

                             +----------+

Unless N100:46 is being operated on by some other instruction it will never be negative so the sign check is unnecessary.

 

[TheWaterboy]

Its a 5/20E - and I am almost certain that I have seen negative numbers in N10:46 after the GRT. It was explained to me that the GRT treats the register as unsigned, therefore when the MSB is a 1, thats a big number. Otherwise I would never have used Bit 15 to fix it.

Now having said that, the number of people saying I'm wrong have me questioning my sanity . . . But I'm as certain as I can be. And will test again whey I go back in the field.

Now this might be firmware revision related I suppose but this is a E so . . .

 

[TConnolly]

5/20E is an enhanced processor, so you can use the INV instruction if you want to simplify things.

The INV gives you the ELSE part of an IF-THEN-ELSE statement. It is the equivalent of

  IF (N11:4 > 9) THEN 

    N100:46 := N11:4

  ELSE 

    N100:46 := 0

  End If

 

[Lancie1]

It was explained to me that the GRT treats the register as unsigned, therefore when the MSB is a 1, thats a big number.

No, GRT treats an Integer number just like all othr instructions handle an integer. if the register has an integer number, it is always either positive or negative. A 1 in bit position 15 means a negative number, which can be a small negative number (-1), or a "large" negative number up to -32767 for a plain Integer type.

 

[daba]

...It was explained to me that the GRT treats the register as unsigned....

Receiving "education" from someone who clearly doesn't know what they are talking about is unwise ...

There are absolutely no caveats that can be applied to the numerical comparison instructions, in all platforms (Logix5, Logix500, Logix5000).

They do what they say they do, taking care of any differences in data-types (e.g. INT against FLOAT) as they process the instruction.

The code you posted shows that for input values less than 10, you assert that it becomes zero. Why ?

If the resulting value is being used as the PV for a PID instruction, this non-linearity at the bottom end could cause issues with control, e.g. integration of error.

 

[daba]

Here is the logic
View attachment 29448

Mickey - Bit 15 winds up being the sign bit of an integer, so when it is set I just zero the value. [I just noticed in this example I am using the wrong word, I should have used N11:4/15. Please pretend I did ]

The source datatype is integer (N11:4) and is from an AI module. The compared value (N100:46) is also an integer. You can see N11:4 is a negative number now.

N11:4 is scaled in the AI module 0-2000, and occaisionally the value goes below 0 when there is no flow and the instrument dips below 4ma.

There is an error in your code !

Take the scenario that the station flowrate N11:4 suddenly drops from, say, +87 to +6.

The top line will not move the 6 to the output N100:46, but the bottom branch will not zero it, so N100:46 stays at 87.

I would handle this limit checking differently.

Unconditional MOV of N11:4 to N100:46.

Next rung (or branch on the same rung) : LES N100:46 10 CLR N100:46

 

[TheWaterboy]

Daba. Why would it not work? I can envision a scenario where the AI updated its register async to the scan, then maybe, for one scan, but thats not a problem.

I chose 9 randomly, value is nominally 450 and up and I didn't like seeing, 1,3,4,6 etc on the display as noise. This filters this out.

And as I said, I have seen it, I know I have, or I wouldn't have put in that bit. I just need to reproduce it now. I wont be back there until next week.
.

 

[daba]

Daba. Why would it not work? I can envision a scenario where the AI updated its register async to the scan, then maybe, for one scan, but thats not a problem.

I chose 9 randomly, value is nominally 450 and up and I didn't like seeing, 1,3,4,6 etc on the display as noise. This filters this out.

And as I said, I have seen it, I know I have, or I wouldn't have put in that bit. I just need to reproduce it now. I wont be back there until next week.
.

My bad, forget I made that post - I had misread the Source A of the LEQ to be N100:46. Apologies...