CLX Maths Overflow Problem

Hi Everyone,

I got a problem of "Maths overflow" and it logs the minor fault for everyscan. The instruction used is SUB with Source A and Source B values are encoder values (integers) that should stay in between +-32767. While Encoders are in running mode, these values are overflowing a bit OR roll over a few more increment which is creating this Maths overflow problem. The sequence is working fine but this error code is bothering me a lot. Within few cycles, minor fault logs thousands of times. It does show me rung where the problem is located but do not know how to fix it.

Is there any way or any instruction I can use to eliminate this fault. S:Minor or GSV did not help, it still recors minor fault.

Thanks
Dhillon

Sounds like your destination tag is an INT, change the destination to a DINT type tag.

Already tried with DINT at destintion but don't work. The problem arising from source values which are INT and unfortuntly i can not change those to DINT as it result it give wrong calculation in my other paet of program. so i am restricted to use INT in SUB instruction.

Ken Moore said:

Sounds like your destination tag is an INT, change the destination to a DINT type tag.

Click to expand...

Can you post an image of your calculation rung, a picture tells a thousand words........
_________

I thought the ControlLogix platform automatically converted the different data types when using math instructions?

So if you subtracted two INT data types, and made the result a DINT, wouldn't the value still be correct, just stored in a DINT?

I can open the program at my work only. But all I can tell that the over flow problem shows because of source values that exceeds 32767. I know that values execcds because of our application type. Overflow problem do not come due to DEST or calculation value with the existing data type.

My question is: if this overflow occurs, how can i prevent it to record as a minor fault?

I appreciate your reply and help.

First off let me respond to your direct question:
there is no way to block overflow faults, every time S:V goes from OFF to ON it will generate minor fault. You can add fault routine and reset it using SSV instruction. See publication 1756-PM014 for details.
But I would strongly recommend not to do it as SSV instruction and call for fault routine will significantly increase scan time.


Second, I never heard that overflow will happen with SUB instruction with INT sources and and DINT destination.

source values that exceeds 32767.

Click to expand...

How Interger tag can be larger 32767? - this can't happen at all.

If you can't post a screenshot of one instruction (why?) when give us values to try. What version is you project? I just tested multiple values in V13 and V16 and don't see this at all.

But I easily made it happen with ADD instruction and INT destination, same values will not generate overflow if destination is DINT.

Third:
What you should be looking is how to prevent overflow situations.
There is a simple way to do it.
I assume your counters are 16-bit and counting from 0 to 65535
Before using math use BTD instruction to move your INT counter values to internal DINT tags. (Clear DINT before BTD).
This will allow you to use DINT instructions that should not generate any overflow problems.

I really like to send you those instruction but I am trying to copy paste those rungs but it is not accepting paste here. I do not know what is the reason. If you have your e mail I can send you an attachment. But here if i add attachment it says file is too big. It only allows 300 KB. Perhaps I am doing some mistake somewhere.


The integer values (source values)go only upto -32768 to + 32767 beacuse last bit is used as a sighned bit in a 16 bit word. If it is unsigned then it will go from 0 to 65535. Those source are coming from the motor encoder Via frequency drives to PLC. Thats why it could overflow.

I like your idea of BTD instruction and i will try it today but not sure how exactly how it works!

secondly if I have write a fault routine, could you please give an example by using SSV instruction so I will copy it and see if Scan time works for me.

Regards,
dhillon

Contr_Conn said:

First off let me respond to your direct question:
there is no way to block overflow faults, every time S:V goes from OFF to ON it will generate minor fault. You can add fault routine and reset it using SSV instruction. See publication 1756-PM014 for details.
But I would strongly recommend not to do it as SSV instruction and call for fault routine will significantly increase scan time.


Second, I never heard that overflow will happen with SUB instruction with INT sources and and DINT destination.
How Interger tag can be larger 32767? - this can't happen at all.

If you can't post a screenshot of one instruction (why?) when give us values to try. What version is you project? I just tested multiple values in V13 and V16 and don't see this at all.

But I easily made it happen with ADD instruction and INT destination, same values will not generate overflow if destination is DINT.

Third:
What you should be looking is how to prevent overflow situations.
There is a simple way to do it.
I assume your counters are 16-bit and counting from 0 to 65535
Before using math use BTD instruction to move your INT counter values to internal DINT tags. (Clear DINT before BTD).
This will allow you to use DINT instructions that should not generate any overflow problems.

Click to expand...

I really like to send you those instruction but I am trying to copy paste those rungs but it is not accepting paste here.

Click to expand...

Open your program, hit Alt-PrtScn on your keyboard, this will copy screen to hte clipboard. Paste to Photoeditor or MS Paint, save as JPG and post here.

The integer values (source values)go only upto -32768 to + 32767 beacuse last bit is used as a sighned bit in a 16 bit word. If it is unsigned then it will go from 0 to 65535. Those source are coming from the motor encoder Via frequency drives to PLC. Thats why it could overflow.

Click to expand...

again, source can't overflow only destination can. source is a series 16 of bits, no matter what is inside it will be treated as Signed Integer(INT).

secondly if I have write a fault routine, could you please give an example by using SSV instruction so I will copy it and see if Scan time works for me.

Click to expand...

Did you look at the manual I posted above?
Probably not, because it has example right there.
Do you want me to post a page from it?
Again - DON'T do it, correct the cause of the problem, not result.

I like your idea of BTD instruction and i will try it today but not sure how exactly how it works!

Click to expand...

This is insane

There will be overflows. Overflows are normal when programming with encoders because they roll over all the time. An overflow should not be a error or fault. Most CPUs just set a flag that can be ignored if desired.

Too many threads have been wasted on this overflow problem.

Contr_Conn, I don't see the need for the two CLR instructions. Won't the BTD convert the INTs to DINTs and fill the whole 32 bit destination? Why don't the BTD instructions indicate the destination length is 32 bits? So what happens when the the current counts is 32767 and the previous count is previous count is -32768. The correct difference is -1 but if you sign extend -32768 and 32767 the difference is 65535. What does dhillon do now?

One of the things that hasn't been discussed on this forum in a significant way is the proper way to handle CPU status flags such as the carry, overflow and sign status flags.

I don't see the need for the two CLR instructions. Won't the BTD convert the INTs to DINTs and fill the whole 32 bit destination?

Click to expand...

No, you must have CLR.
BTD is "Bit distribute", it changes only bits specified in this case 0-15, leaving 16-31 intact, so if DINT has any bits 16 or higer set, they will remain set.

Why don't the BTD instructions indicate the destination length is 32 bits?

Click to expand...

you can't, bits 16-31 will be copied from undefined memory location and will have a random value. Len must be 16. CLR is very fast command and makes no sence to take a chance.

So what happens when the the current counts is 32767 and the previous count is previous count is -32768. The correct difference is -1 but if you sign extend -32768 and 32767 the difference is 65535.

Click to expand...

That is why I am using BTD and not a MOV.
-32768(INT) -> BTD -> 32768(DINT)
32767 (INT) -> BTD -> 32767(DINT)
32768(DINT)- 32767(DINT) = 1(DINT)

or same thing in HEX for easy understanfing

-32768(INT)= 16#8000 -> BTD -> 16#0000_8000(DINT)
32767 (INT)= 16#7fff -> BTD -> 16#0000_7fff(DINT)

One of the things that hasn't been discussed on this forum in a significant way is the proper way to handle CPU status flags such as the carry, overflow and sign status flags.

Click to expand...

I agree, This was always a grey area.

Still not good enough

Contr_Conn said:

No, you must have CLR.
BTD is "Bit distribute", it changes only bits specified in this case 0-15, leaving 16-31 intact, so if DINT has any bits 16 or higer set, they will remain set.
you can't, bits 16-31 will be copied from undefined memory location and will have a random value. Len must be 16. CLR is very fast command and makes no sence to take a chance.

Click to expand...

I see. I didn't understand what BTD did.

That is why I am using BTD and not a MOV.
-32768(INT) -> BTD -> 32768(DINT)
32767 (INT) -> BTD -> 32767(DINT)
32768(DINT)- 32767(DINT) = 1(DINT)

or same thing in HEX for easy understanfing

-32768(INT)= 16#8000 -> BTD -> 16#0000_8000(DINT)
32767 (INT)= 16#7fff -> BTD -> 16#0000_7fff(DINT)

Click to expand...

That doesn't answer the question. What if the current count is 0 and the previous count is 65535 then the difference is -65535 when the true difference is 1.

What if the current count is 0 and the previous count is 65535 then the difference is -65535 when the true difference is 1.

Click to expand...

I see your point Peter, CLX simply does not have unsigned math or Unsigned INT (UINT).

UINT is always in range 0-65536, so with DINT you simply have to define that your SUB result is always positive 0-65535 - the same way you would have in with UINT and do compare
if RESULT < 0 then RESULT=RESULT+65536.

I add screen shot as attachment if it works.

Thanks Cont_conn and Peter: I like the ideas from you but here I am a bit confused using BTD instruction.


There will be overflows. Overflows are normal when programming with encoders because they roll over all the time. An overflow should not be a error or fault. Most CPUs just set a flag that can be ignored if desired.

Peter: Could you please shed some more light on how can I set a flag that can be ignored. Is it an check mark option in CLX Properties or I have write a fault routine. I have tried GSV/SSV but does't work.

Cont_ctr: I went through the document link you sent for writing fault routine but i hardly understand that. If anyone can see attachment, I am getting overflow in R 110 and please add some logic to get rid of this overflow problem. I will try tomorrow this CLR and BTD instruction too. I am not verymuch user of CLX that's why I am getting hard time to understand BTD.

Appreciate everyone's help.
Dhillon

Contr_Conn said:

I see your point Peter, CLX simply does not have unsigned math or Unsigned INT (UINT).

UINT is always in range 0-65536, so with DINT you simply have to define that your SUB result is always positive 0-65535 - the same way you would have in with UINT and do compare
if RESULT < 0 then RESULT=RESULT+65536.

Click to expand...

Originally Posted by Contr_Conn
I see your point Peter, CLX simply does not have unsigned math or Unsigned INT (UINT).

UINT is always in range 0-65536, so with DINT you simply have to define that your SUB result is always positive 0-65535 - the same way you would have in with UINT and do compare
if RESULT < 0 then RESULT=RESULT+65536

Cont conn:

Because we are using signed integer, which could be negative values too so SUB result could be positive or could be negatice in our application.
dhillon