SLC 5/04 Fault Logic Issue

[MJC]

Thank You all for your help, greatly appreciated.
@dmargineau

I:2.1 is an analog input, probably a +/- 10 VDC analog input point; a malfunction of the circuitry or a polarity reversal might generate a negative decimal data image

Yes that is probably the case. What threw me off here is the value in I:2.1 and the value at N7:159, I thought that the value in I:2.1 should have been of negative value as well when the fault occurs. But that’s not the case, at some point that value is negative.

@Okie,

Without rtfm for analog input, are all 16 bits of the data word used? Is it configured to go max scale or min scale or other when out of range conditions occur?

I don’t see any configurations for the raw data coming in to input I:2.1, what you see on the snap shot in post 1 is all that there is.

Anything that writes to those timer registers needs to be calculated in a scratch location and qualified/clamped first.

Completely agree with you on this one.

@OZZE

On something like that I would normally
Les 0 N7:159 mov 0 N7:159
between the mov and div statements.

That is what my initial thoughts wore, but I thought I’d run the issue by the forum.
Thank You

 

[MJC]

@ Bit Bucket 07

The first thing you need to do is to add a rung at the end of your main program file that unconditionally unlatches bit S:5/0 so your processor will stop faulting on a math overflow every time you divide by zero. Then hire a programmer.

How can you look at that divide function on rung 12 and not see a divide by zero waiting to happen?

I don't need to read any fault codes to know that a divide by zero will eventually occur in that DIV function.

And what makes you so sure that a divide by zero will eventually occur in that DIV instruction?

 

[Eric Nelson]

What threw me off here is the value in I:2.1 and the value at N7:159, I thought that the value in I:2.1 should have been of negative value as well when the fault occurs. But that’s not the case, at some point that value is negative.

That's right... The value in N7:159 was -32768 at the exact point the fault occurred (Heck, it CAUSED the fault!... ). Since the program is no longer running, that value will not get changed. The value in I:2.1 is 'live' data, so it will show the current value.



-Eric

 

[Eric Nelson]

And what makes you so sure that a divide by zero will eventually occur in that DIV instruction?

I'm guessing the fact that since N7:160 is a variable, it is capable of being set to zero. Might never occur, but still capable of occurring. Can't hurt to add a 'N7:160 NEQ zero' ahead of the division (and maybe alarm on that condition, instead of faulting the PLC).



-Eric

 

[MJC]

I'm guessing the fact that since N7:160 is a variable, it is capable of being set to zero. Might never occur, but still capable of occurring. Can't hurt to add a 'N7:160 NEQ zero' ahead of the division (and maybe alarm on that condition, instead of faulting the PLC).

Right, I checked the logic and there is nothing else writing to N7:160, why did the original programmer choose to use a veriable instead of a constant is unknown, but all is know that the processor will not fault out on a math over flow, unless someone changes that value to 0.
Again thank you all for your help.

 

[Bit_Bucket_07]

@ Bit Bucket 07










And what makes you so sure that a divide by zero will eventually occur in that DIV instruction?

If something can happen, it eventually will.

 

[OkiePC]

@Okie,

I don’t see any configurations for the raw data coming in to input I:2.1, what you see on the snap shot in post 1 is all that there is.

What is the part number for the analog input card your are dealing with?

 

[MJC]

Okie its a 1746-NIO4V

 

[OkiePC]

You are right then, no out of range setup for that input. It did (can) go negative so you just need to limit check your DIV instructions. Sometimes you can switch to a MUL instruction to avoid the divide by zero issue, but overflow trapping is sometimes a necessary evil too.