PLC real value calculations

Do you want a list of instructions, or do you need to know what happens
internally?

Here's the list of math instructions, from the RSLogix5 help menu:

If you want to:    Use this instruction:
Add two values                ADD
Evaluate an expression            CPT
Divide two values                DIV
Convert from BCD to integer        FRD
Multiply two values            MUL
Take the opposite sign of a value    NEG
Take the square root of a value        SQR
Subtract two values            SUB
Convert from integer to             BCD    TOD
© 1997 Rockwell Software Inc.

You might also find some answers in the "instruction set reference"
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm=
/1785-rm001_-en-p.pdf

Look in chapter 4.

Integration?  Are you referring to the PID instruction?  You should not
be using REAL data in the PID instruction.  P191 of the referenced
manual gives you a good detail of the PID instruction.

If you want detail as to the internal workings, well, as you might
guess, that's proprietary.

Do you think you have discovered some anomolous behaviour in one of the
the math instructions?
I'd surely like to hear about if that's the case, especially if there's
a reproducible anomaly.

On Tue, 14 Mar 2006 19:57:11 +0800, "bruce varley"


Probably could, but I am not sure I understand the question. You
should also specifiy the specific PLC-5 in question, there were two
major flavors (Classic and Enhanced) and a mess of sub-varieties.

Are you asking how the math is handled internally, or how to use the
various instructions, or??

Sorry, it is a bit vague. Situation is DCS-literate people who may have to
assist a team to implement 'control' type calculations on a PLC5 (not sure
what type). I'd just like to find something that explains 'how it's done',
eg. how the calc block are specified in the dev environment, how you specify
the inputs and outputs, how you link the internal connections. Nearly all
the stuff I've pulled up explains how to do discrete stuff such as
interlocks in ladder, which isn't relevant in this case.

Hmmm...
PLC5s don't program in "blocks" like you'd use in a DCS.  Rockwell
programmable automation controllers do support "function block
diagrams", but I those aren't PLCs; they're Automation Controllers.

I've found the best thing for new guys in the field is to review the
instruction set reference.  A copy of the code is nice, and quick
run-through of where things are--what is OK to edit and what's verboten
to touch.  Then they pretty much have to get their hands on it and sink
or swim.

"Interlocks in ladder are not relevant in this case."  That's kinda
strange.  Are you SURE it's a PLC5?  PLC5 is all ladder & nothing but
ladder (Yes, there's SFC & ST, but that compiles internally to ladder).
 A lot of folks call any controller a "PLC", even if it's something
else.

A review of the code they'll be working with (or at least having a copy
on their laptop) will be helpful.  I assume your guys are bringing
their own laptops & have the correct software installed.  Are you going
to use the Customer's workstations?  It would then be an excellent idea
to find out what software and version they're using.  There are still
people out there using 6200 (yes, really) and AI.

On Wed, 15 Mar 2006 19:04:49 +0800, "bruce varley"


Sounds like you've never looked at a PLC-5 program!

Most people program them in ladder, and there is really no magic to
the math. You just use the instruction as it says; the ADD instruction
adds, etc. All the math instructions handle either integer or floating
point values. All I/O is memory mapped, but look out!!! I/O memory is
addrtessed in OCTAL, all other memory is addressed in decimal! The
math functions are all predefined, nothing is "specified." Linking is
accomplished by shared memory addresses. The PLC-5 supports indexed
and indirect addressing.

If you really want you can program them in "Structured Text," which is
really a prehistoric version of Pascal.

What software are you using? If you want I can send you some PLC-5
programs, or write some examples to your specs, but they won't mean
much unless you have the software to open them.

If you are expecting them to program similarly to  DCS systems of
comparable vintage,  you are in for a big surprise!

You will probably find the math to be easy, the tedious part is
usually getting the data in and out of the processor. Network
capability of the PLC-5 ranges from virtually none to mediocre. If you
are using non-native networks you can expect some complications about
permitted data types.  

Feel free to contact me off-list if you want to get into more detail.

Thanks, guys, that's gven me a good summary. It sounds like it'll be an
interesting challenge.

This is a good NG, there are some really good people out there.

Please be careful if you have to implement floating point math in a PLC5.
It's not well documented, but if you have to add a very small float value to
a very large float value in 5 there is a chance that the value won't
increment, the processor ignores it. The ADD instruction won't add a
fractional value to a number that is very large . This one bit me on the ass
while trying to totalize flow from a very old Foxboro flowmeter that only
had a analog output. Had to segment the flow into 24 hour periods and then
add it. Customer wanted to see monthly flow totals. Other than that you
should take the advice of our Supreme Court Justice, Thrugood Marshall, and
follow the link to the instruction set reference manual.

This problem is not specific to the PLC5 family, but applies to floating
point
math in general. I once had the same problem in a Bailey Loop Command
controller when a running total stopped growing and a time average derived
from that total started to fall in inverse proportion to time. Any
controllers with
floating point math that I've used implemented the IEEE standard format
32-bit
floating point numbers. IIRC, this divides into a 24-bit mantissa and an
8-bit
exponent, resulting in only 7 decimal digits precision. In addition and
subtraction,
both numbers must have equal exponents. As the total grows, the input value
must have the exponent increased and the mantissa shifted to the right by
the
same number of bits. Eventually, all of the mantissa bits are shifted out of
the
input, its value becomes zero and the total stops growing.

For long running totals, I prefer to use 32-bit unsigned integers if
available.
As long as I can get three or four significant digits in the input value,
the error
will remain small.

Mike

Thanks Mike. I thought it was a bug that was specific to the only processor
I saw it happen on. If I ever have to totalize data like that on other
controllers I'll be sure to watch out for it.