SLC 5/04 Fault Logic Issue

[MJC]

o all, I have a SLC 5/04 1747-L543 that faulted out twice this week. Attached is the reason for the fault.
Analog input for I:2.1 is a 10 K pot that adjusts a delayer for triggering a cycle.
Rung 11 is the timer with the preset of -11.
Rung 12 I:2.1 is the actual input from the potentiometer.
Question, how did N7:159 end up with -32768. I don’t see anything else writing to its value.
Any 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.
I'd suggest to MOV the I:2.1 value within an unused integer and then ABSolute the value of the chosen buffer before MOVing it to wherever I:2.1 is being used; this way you are avoiding generating of negative Counter or Timer Presets.

 

[Eric Nelson]

I agree with dmargineau about how it might occur, but I don't think I would just ABS the value. Since the negative values shouldn't be seen, I would ignore them, not try to make them positive. I would stick a LIM instruction after the NEQ to allow the MOV and DIV only when the analog input value is within expected values.



-Eric

 

[cornbread]

I thought a neg preset was a no no?

 

[Eric Nelson]

I thought a neg preset was a no no?

It is. That's why the processor is faulting.



-Eric

 

[OZEE]

On something like that I would normally

Les 0 N7:159 mov 0 N7:159

between the mov and div statements.

Same kind of thing if there's a max.

 

[OkiePC]

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

Without rtfm for analong 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?

 

[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.

 

[dmargineau]

CLR S:5/0 is useful for various ladder logic computations math overflow conditions, unfortunately, this is not one of them...
Counter and Timer instructions are not defined but for Presets strictly >0...
As a general rule of thumb, as OkiePC states, any Counter/Timer Presets should be "ladder logic qualified" prior to be "placed" within the instruction since the failure of doing so combined with a logic generated negative value will invariably cause a CPU Major Fault.

 

[Bit_Bucket_07]

CLR S:5/0 is useful for various ladder logic computations math overflow conditions, unfortunately, this is not one of them...

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

But, yeah... The timer preset is also a problem created by this divide function sans range testing the operands. As for a differential analog input returning negative numbers, that is normal and to be expected.

 

[dmargineau]

You are foreseing the "future"... Unfortunately, the CPU won't make it there...It will hard fault as soon as the negative value is "placed" within the T4:13 Preset by the DIV instruction you have mentioned.
Again, Timer instructions are not defined for negative Presets; the CPUs, literally, "don't know what to do!" when encountering a negative Preset and promptly "give up" running the application and declaring themselves "Major Faulted".

 

[Bit_Bucket_07]

Foreseeing the future is the very essence of programming. Not foreseeing the future is precisely what has led to this PLC faulting.

 

[dmargineau]

Probably, as soon as someone manages to patent a functional Time Machine, the automation manufacturers will allow users to use negative Presets timers...

 

[dmargineau]

Foreseeing the future is the very essence of programming. Not foreseeing the future is precisely what has led to this PLC faulting.

Not quite...The reason for the Major Fault is depicted (and spelled!) within Post #1 of this thread...Had it been a "Math Overflow" condition, the user would've been prompted and informed so..." A Math Overflow has occured...etc!"...

 

[Bit_Bucket_07]

Don't get so hung up on this single incident. I don't need to read any fault codes to know that a divide by zero will eventually occur in that DIV function. One could range check the result prior to moving the value to the timer preset, but that bandaid wouldn't correct the logical error that generates the negative numbers to begin with. I am assuming that the timer in question actually requires a valid preset value in order to function properly. Hence the recommendation to hire a programmer.