SLC5/03 Counter Anomoly

Aabeck

Member
Join Date
Feb 2013
Location
Detroit
Posts
1,860
I have a SLC5/03 that suddenly started faulting. It has been running for 2 years without issue, and I tracked the problem to a math error (underflow?)

just for me I put in a subroutine to count how many scans per second the PLC is doing, and calculate it every minute. I count every other scan, at :01 seconds I move the counter.ACC, at :02 I move the counter.ACC, subtract for the number of counts, multiply by 2 for the scans value and reset the counter.

The odd part is even though the counter is reset every minute it somehow got to the negative count of -28465 and tried to SUB -28554, faulting the CPU.

I have watched this before and the count never went over 3000 until it was reset, the JSR to this is unconditional and processed every scan, so it's not getting bypassed, the OSR's are unique and not used elsewhere in the program.

What concerns me is I have this subroutine in almost every SLC, and a few other brands of PLC, I put in to see how the PLC performs, and is still in many machines.

For this one I added a latch bit on the first MOV, and perform a RES on the counter if the seconds are over :03 or the counter.ACC is over 12000 - see the second picture

Scans.jpg Scans2.jpg
 
Last edited:
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.
 
What is puzzling is the machine was running without problems for two years without issues. Something must have changed to cause the underflow. Weird problem.
 
Code doesn't change by itself!
someone has to have cone into the program and changed something.
I would do a file comparison of the program (new versus older copy) to see where the change is.
other thought,
was there a cpu change?
I/o change?

regards,
james
 
I went online with the copy of the program I had - it didn't make me upload a usage file as if there had been a change in the program since I commissioned it. The CPU & I/O are still original.

If it was a scan time issue with the CPU I don't see how it could let the counter loop like that, and the CPU would have faulted.

The OneShot bits, counter and integers are only used once in the entire program, so it couldn't be written to somewhere else, and the counter and integers are not written to by the HMI - it only reads the one final value on a PLC status screen.

It just strikes me odd that a counter that is reset every minute counted for what had to be minutes until it came around to almost -28000

I did add the OTU S:5/0 on the last line of ladder 2 as a precaution. Maybe I will have to start putting this in every SLC.

I also added a GRT compare and am logging the highest value the counter reaches and added that in the corner of the HMI's main screen, and asked the customer to call me if the number ever went over 10000.
 
Since the code looks reasonable and data usage within the program was checked, it seems like time to think about "fringe" explanations. I've got two: (1) there is something externally manipulating the clock such that it can go minutes without the seconds transitioning to the value 2. For example, some network time service correcting drift in this unusual way, or (2) some network connection that is manipulating the counter values.

I know, these are really a stretch, short of blaming it on a hardware failure.
 
Can you post your RSS file (Zip it first, forum rule...)

It looks to me like all the code is doing is calculating a "scans per second" value ?

Can I ask why you need that figure, is it any relevance to the process it is controlling ?

You can get this scans per second easily from the status file S:23, which is average scan time in either 1mS or 10mS units (you choose the timebase). Either divide 1000 or 100 by this value, and you have your scans per second.
 
I've just thought of something I came across years ago.... some variants of SLC didn't increment the "Seconds" in the RTC every second, but jumped 2 seconds, so it counted 0, 2, 4, 6 [EDIT : every 2 seconds]

Can you put a trap bit in to see if seconds/0 is ever on ??
 
Last edited:
I have a SLC5/03 that suddenly started faulting. It has been running for 2 years without issue, and I tracked the problem to a math error (underflow?)

just for me I put in a subroutine to count how many scans per second the PLC is doing, and calculate it every minute.....

Confusion here, was the SLC faulting BEFORE you put the subroutine in, or after.

If the former, take it out, and investigate the cause of the original fault, it can't be your subroutine.

If the latter, then it is your subroutine that is causing the faulting, so take it out.
 
Daba,

While watching this online the seconds incremented 1 every second, and it has been accurately calculating about 190 scans per second since I started it. All this subroutine does is calculate the scans per second, and it is only for my information to see how fast it was scanning - it's not used in the process, so if it is a problem again I will delete it - but I am wondering how this happened, and if it could be a problem in any other operation of any SLC operation.

Mispeld,

This PLC has no network connection, just a 5/03 with AdvancedHMI on a serial DF1 driver, and the PC does not send the time to the PLC.
 
Are you sure the rungs you posted are the source of the underflow? I've only worked with a few SLCs, so I'm nowhere close to being proficient with it, but the screen shot shows the correct answer. -28465 - (-28554) = 89
Could anything else be writing to S:42 to prevent its value from incrementing?
 
.....just for me I put in a subroutine to count how many scans per second the PLC is doing

if it is "just for you", then use the average scan time from S:23 and calculate like I said - you can't do any damage that way....
 
Daba,

This routine has been in since I started testing the program years ago, not something I just added. It has been in the running machine for over 2 years without any problem, so suddenly the counter stopped resetting or something changed a value in the counter or an integer.
 
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.
 

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
604
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