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 =A9 1997 Rockwell Software Inc.

You might also find some answers in the "instruction set reference"

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.

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.

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.

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.

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.

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.