SLC5/03 Counter Anomoly

The value of 89 is the correct result of subtracting negative 28554 from negative 28465. If the screen capture was of the scan that caused the underflow, neither of the one-shots were true in that scan since the value of S:42 was zero. Unless something in ladder logic wrote zero to S:42 between those rungs and the end of the program.
 
Steve,

I think the 89 is the value from the last good subtraction, and somehow when it hit these specific values the SUB resulted in a value out of the integers range and that caused the fault.

If you see any negative numbers in the counter's accumulator, then it has OVERFLOWED, it is a CTU, not a CTD.

That means you have counted more than 32,767 times before it has been reset.

I think the subroutine is missing the "Seconds = 2" which performs the reset.

What is the AVERAGE scan time of the program, and the MAX scan time, from status registers S:23 and S:22 respectively. If your scan time is very high (and I've seen some good ones!), the subroutine could potentially miss the "=2"

One thing you need to be absolutely certain of - is it overflow on this counter that causes the faulting... Remove the unconditional OTU S:5/0 I got you to put as the last rung, and relocate it to just after the CTU, but make it conditional on Counter.OV You don't need to worry about Counter.UN because it is a CTU instruction. And while you are at it, cross-reference the counter and make sure it is not being used elsewhere.

If the SLC still faults, there's an overflow, or underflow, somewhere else, and we may be looking in the wrong place.
 
Last edited:
Daba,

I will try moving the OTU, and just to see if that does happen add a OTL of an unused bit to see if that latches. But since I added a RES if the second is greater than :03 (in the second screenshot) I might remove that to test this.

I do know when the CTU has a negative number it went from 32767 to -32768 & then counted up to -28465. And the scans per second has always been near 200, so to miss :02 seconds it would have to do that for almost 200 scans in a row, and then repeat that for a few minutes to get where it was. Unless something happened and the CPU clock stopped timing? (But when I went online it was close to the right time.)
 
Daba,

I will try moving the OTU, and just to see if that does happen add a OTL of an unused bit to see if that latches. But since I added a RES if the second is greater than :03 (in the second screenshot) I might remove that to test this.

I do know when the CTU has a negative number it went from 32767 to -32768 & then counted up to -28465. And the scans per second has always been near 200, so to miss :02 seconds it would have to do that for almost 200 scans in a row, and then repeat that for a few minutes to get where it was. Unless something happened and the CPU clock stopped timing? (But when I went online it was close to the right time.)

Could probably help you better if you can post the application file....
 
Here is the zipped file. It is after I cleared out the negative numbers and before I added anything
 
It looks like it fails, not when the values in N7:253 and N7:254 are both negative as shown in your screen capture, but when the value in N7:253 is negative and the value in N7:254 is positive. That would happen if the counter accumulator rolls over from positive to negative between the two samples.
I just set up similar logic on a Micrologix 1000 that I have to see what values generate a fault.
The simplest fix might be to only allow counting in C5:0 when S:42 is between zero and three. That should keep the .ACC value below 32000.
 
Last edited:
Steve,

I did exactly that - I added a LEQ S:42 3 in the counter line, and I added a line at the end for GRT S:42 3 RES C5:0 so the counter.ACC would be 0 any second after :03

As a precaution I am going to remove this from all my programs, and PLC's I get back to in the field, and compute from the scan time register as suggested.
 
Very nearly every Logix500 program I have ever seen has an unconditional OTU S:5/0 as the last rung.

This will stop the faulting on overflow and underflow.

I don't know why they built this "feature" into the 500 series, it's pretty useless, as you don't know where the overflow/underflow occurred for you ti fix it.

I'll second that
 
Here is the zipped file. It is after I cleared out the negative numbers and before I added anything
I just had time to look at your application and noticed that you had used counter C5:0 in File 3 and in File 10. I was using Emulate500 and every time C5:0 reached 31 due to counting up in File 10, rung 1 it would fault with "Indexed address reference is beyond specific referenced data file."
Might be something, not 100% sure since I don't have a real SLC 5/03.
 
mhammer,

I will double check that when I get back, but I did a Find All and thought I checked every counter, bit and integer for any duplications.
 
That's a common error on them it will only fault when the program rolls over for the last line and restarts the first line. I have run into it a few times.
The thing is you can never know just when it will happen.

The way to prevent it from faulting the processor id in very last line of the ladder code unlatch the math overflow bit.
Or you can at every line in the ladder that dos a math function the next line should be to unlatch the math overflow bit.
 
......The way to prevent it from faulting the processor id in very last line of the ladder code unlatch the math overflow bit.
Or you can at every line in the ladder that dos a math function the next line should be to unlatch the math overflow bit.

It is the Math Overflow Trap bit you have to unlatch S:5/0, not the Math Overflow Status bit, S:0/1.

Unlatching it after every instruction that affects the math status bits is a bit overkill, IMHO, and will probably "break" most projects I've seen in terms of extended scan times, and the additional memory required.

Although it a cheap and nasty "trick", there's always a potential that the overflow trap bit could get set again in an STI or DII that fires off at precisely the wrong moment (just after the OTU and before the END rung). And do not get confused with the STI and DII "Overflow" bits, these are badly named - I would prefer they were called "Overlap" bits.

My best advice is to find what causes the overflow (or underflow), and fix the real problem, not just mask it.
 

Similar Topics

I have wasted a week trying to figure out how to connect an SLC5/03 with my laptop. I do not have and can not Buy the 1747 UIC and PC3 cables. I...
Replies
14
Views
2,477
I am trying to connect to SLC5/03 using an FTDI usb to rs232 with female to female converter at 1 end... however I can not connect to it ... the...
Replies
8
Views
1,182
Good evening. I am in serious need of help. I am trying to connect a Panelview Plus 7 Standard to a SLC5/03(1741-L531) using a Moxa MGate...
Replies
3
Views
602
Hi. I am having trouble establishing comms between an slc5/04 and panel view plus 7 via a PLX51-net-eni. The set up is: 5/04 Channel 0 DF1...
Replies
8
Views
869
Hi All, I have programmed some MSG instruction in SLC5/05 64k CPU series D FW 13 brand new cpu. 2 of the MSG instructions are direct IP to other...
Replies
3
Views
962
Back
Top Bottom