Control Logix 5000 Arithmetic Overflow

Hello gents,

I have a Control Logix processor with a few Flex IO nodes and I keep getting minor faults saying that it's a type 04 Program Fault Code 04 Arithmetic Overflow and can't for the life of me understand how to solve them.

The faults happen on a move instruction where a REAL value within 0 and 65535 is being written to a Flex IO analog output module configured for 4-20 mA (0 to 65535).
Looking at the tag created by RS Logix, it is an INT which I assume is signed and would explain the error being triggered.

However, I can't seem to be able to change the data type to DINT as it is automatically generated and there is no instruction that I can use to convert from REAL to an integer format as there seems to be none available.

Have any of you guys had this problem before? How did you fix it?

MOV the real to an INT and then use that in your Analogue Out.

The overflow minor fault makes sense: ifa value greater than what can be represented by an INT (15 bits + sign) tag is moved into that INT tag, there's going to be an overflow.

Take a bit of a step back. Are you using the 1794-OE4 analog output module ?

That's a 12-bit resolution module, but the data is packed in an unusual way: it's "left justified", so the lower 3 bits have no effect. Have a look at Appendix C in the user manual for a decent table of hex values versus actual output mA.

You might have an unusual bit of logic if you're calculating a REAL in order to drive a 1794-OE4.

A quick and dirty way to avoid the overflow is to use a MOV to convert the REAL into a DINT, then use a COP to copy the first 16 bits from the DINT into an INT.

But I'm not sure how that's going to work when your logic is creating a REAL in the 65535 range anyhow; you'll lose that 16th bit. I think it's worthwhile to go back and examine the logic feeding this output.

If the logic is working the way you want to, one option is to move the REAL value into a DINT, and then bitwise AND the DINT into an INT using 16#FFFF as the mask.

Ken Roach said:

Take a bit of a step back. Are you using the 1794-OE4 analog output module ?

Click to expand...

It's a 1797-OE8.

What confuses me is that the channel setup is done to use a range from 0 - 65535, but the tag created for the data is an INT, which although it has 32 bits, is signed and that is what confuses the processor into thinking that there is an overflow as it cannot put 65000 in 16 bits (in the positive side).

If you look into this document http://literature.rockwellautomation.com/idc/groups/literature/documents/in/1797-in003_-en-p.pdf

On page 18, my setup is the number 7.

I'll have a go on the REAL TO DINT, but am not sure how the DINT to INT will work out.

Thanks for the help.


Edit: I just realized that 65535 fits in 16 bits so the REAL to DINT and to INT should work fine.

Thank you for that update; the 1797-OE8 is a very different module from the classic 1794-OE4. It's actually made by Pepperl+Fuchs and was designed for the Logix family of controllers.

Don't worry about the sign bit in this case: just MOV the value from the REAL to a DINT and the 16th bit will be an ordinary data bit.

Then COP the DINT intermediate tag to the INT that's part of the module output image. Make the Length of the COP instruction "1", because you only want to copy enough data to fill one of the target elements (in this case, a 16-bit INT tag).

If it were me, I'd actually use the Masked Move instruction (MVM) with a mask of "16#FFFF" to copy the bits from the DINT to the INT, because that makes it very explicit to somebody reading it later that you're moving only 16 bits.

Thanks Ken. I've been hearing that Pepperl and Fuchs are taking over the replacement parts for these (as they are to be discontinued at the end of the year), but wasn't aware that they actually made these.

Looking a bit deeper into the program, the REAL value that is MOV'd into the output comes from a Compute Block. For some reason, the people that wrote this piece of software either done it before AOI's were a thing (which is very likely) or didn't feel like it would be useful.
So given time, I think I will write an AOI for the Analog Output where the engineering value is converted to DINT or even INT and the rest of the mapping calculation will be done in the correct variable type.

Thanks for the help.
Also, seen as you seem to know a bit more about the AB platform, you wouldn't have an idea of what could be happening with the problem on this thread?

http://www.plctalk.net/qanda/showthread.php?t=110977

I've looked in most places for what could be going on here, but haven't quite figured out what could be the problem and it was when trying to see what appeared in the fault description that I found these programming errors.

Would the SCP AOI not do this for you, and use it to replace the CPT block?

janner_10 said:

Would the SCP AOI not do this for you, and use it to replace the CPT block?

Click to expand...

Quite possibly there is something already made by Rockwell for this. I believe in RSLogix500 there was a SCALE instruction. However, I'm most proficient in Siemens stuff and have only really now started looking into the Rockwell product line.

Is the SCP available from Rockwell's website? My RSLogix5k version is really old (something like 20.01 or so).

One is built into the FB editor but Rockwell have done on for ladder which you can download. I have attached it for you.

Here is a pic of using it.

I have set up my Analogue Out for % output in this instance, rest is as you would expect.

That's precisely what I was thinking and is good enough. I was already looking into how to automatically configure the output limits from the card configuration, but it would be overengineering for now.

Thanks.

cardosocea said:

That's precisely what I was thinking and is good enough. I was already looking into how to automatically configure the output limits from the card configuration, but it would be overengineering for now.

Thanks.

Click to expand...

The SCP AOI will not limit the output to the Min and Max values presented as parameters.

The math it uses is straight-line scaling, the 4 parameters just define the slope and intercept (offset). So if you had input 0-10, output 0-100, and you gave it an input of -30, the output would be -300.

Once you have the AOI, you can easily add output limiting to it if you want to. Just change the name so people don't think its a standard SCP. You could use SCPL (Scale with Parameters Limited), for instance

daba said:

The SCP AOI will not limit the output to the Min and Max values presented as parameters.

The math it uses is straight-line scaling, the 4 parameters just define the slope and intercept (offset). So if you had input 0-10, output 0-100, and you gave it an input of -30, the output would be -300.

Once you have the AOI, you can easily add output limiting to it if you want to. Just change the name so people don't think its a standard SCP. You could use SCPL (Scale with Parameters Limited), for instance

Click to expand...

Thanks for that. I wrote a similar one for Siemens with a switch to enable or disable limits, so that should be no issue.