# Counter not incrementing?



## mpetro (Jan 6, 2016)

Hey guys

Working on a PLC program at a hydro station (CompactLogix, RSLogix 5000), trying to commission to get the station back online. Our program is working except for a single counter instruction. It is (supposed to be) incremented every second for 30 seconds, using a 1-second resetting T4 timer bit. There are two separate instances of this logic (one for each bearing on the turbine shaft), and the other instance (programmed identically, just using different addresses) works perfectly.

The 1-second timer (T4[8]) is always running, using its own .DN bit set to XIO to reset itself once it reaches 1000ms. The .DN bit is then used in another line of logic following two XIC commands (one is a hand switch, the other is a timer that goes true five minutes after the turbine goes offline) which indicate that they are true (screenshots below). The output of this line is a counter, C5a[13], that should increment when the T4[8].DN bit goes true, but on several tests has shown different results such as not incrementing at all or incrementing very slowly and very sporadically (0-1, 30 seconds later 2-3-4 very rapidly, etc). Normally I would assume it's a simple error made in addressing or using the wrong bit instruction, but this logic is an exact copy of another segment of program, aside from addresses obviously, for the other bearing, which works perfectly.

I've brought this to the attention of both my boss and my father, who are both very well-versed in PLCs, and they can't figure out why it's happening either. Any help would be greatly appreciated.

Attached are pictures of the timer rung and the counter rung which is supposed to be incremented using it. The identical logic that is working is the same except the timer is T4[7] and the counter is C5a[12].


----------



## ScooterMcGavin (Jan 24, 2011)

Did you do a cross reference on the timer and make sure it's not being reset inadvertently somewhere else in the logic? You could also try putting a test bit and branch around the counter logic and see if the bit will toggle the counter. You could also try using a different counter address to see if it will increment using the current timer logic. I have had rare instances where a timer won't work right and the done bit never gets set the only way I could fix it is making a new timer.


----------



## mpetro (Jan 6, 2016)

scameron81 said:


> Did you do a cross reference on the timer and make sure it's not being reset inadvertently somewhere else in the logic? You could also try putting a test bit and branch around the counter logic and see if the bit will toggle the counter. You could also try using a different counter address to see if it will increment using the current timer logic. I have had rare instances where a timer won't work right and the done bit never gets set the only way I could fix it is making a new timer.


We did a cross reference on both the counter and timer addresses with no conflicts, but one of the tests I'm going to do is try putting another counter underneath the existing one and see if that one gets incremented, and then try the same thing (as you said) with another timer bit parallel to the existing timer to see which is causing the issue.


----------



## psgama (Oct 26, 2015)

What routine did you build your timer in? Is this routine being called frequently? You may have built your timer inside a routine that is not constantly running. That is my best guess.

Create a new subroutine for timed pulses.
Create any pulses that you need within this new subroutine.
Make sure this subroutine is called every scan of your main routine.


----------



## mpetro (Jan 6, 2016)

psgama said:


> What routine did you build your timer in? Is this routine being called frequently? You may have built your timer inside a routine that is not constantly running. That is my best guess.
> 
> Create a new subroutine for timed pulses.
> Create any pulses that you need within this new subroutine.
> Make sure this subroutine is called every scan of your main routine.


It's the top rung of a subroutine that is called every scan. Your idea about a subroutine for pulses and timers is a good idea though.


----------



## scaledwithparameters (Sep 15, 2015)

What happens after the counter increments to 30? Are you doing comparisons in the program with any counter value other than 30? If not, why not just let the timer run until 30s and commence whatever action takes place after this period...


----------



## mpetro (Jan 6, 2016)

scaledwithparameters said:


> What happens after the counter increments to 30? Are you doing comparisons in the program with any counter value other than 30? If not, why not just let the timer run until 30s and commence whatever action takes place after this period...


The counter is used to average oil levels in a turbine bearing pot over 30 seconds, and after it reaches 30 seconds we use a MOV instruction to change the preset to 15 seconds. This is then the interval for averaging the oil levels. I didn't actually write the program, so I feel like I may have gone about it a different way, but the logic works perfectly in the routine for the other bearing.


----------



## scaledwithparameters (Sep 15, 2015)

I've seen these un-explainable bugs before in control logix and also in RS500...

Like someone mentioned previously, I'd just start by swapping the addressing to an unused counter and see if it acts correctly..

Very interesting though, look forward to an explanation if you come up with one. For me it's always been troubleshooting. Get it working after someone else had their hands in the pot, and move on to the next problem. Unfortunately, never looked back.


----------



## mpetro (Jan 6, 2016)

scaledwithparameters said:


> I've seen these un-explainable bugs before in control logix and also in RS500...
> 
> Like someone mentioned previously, I'd just start by swapping the addressing to an unused counter and see if it acts correctly..
> 
> Very interesting though, look forward to an explanation if you come up with one. For me it's always been troubleshooting. Get it working after someone else had their hands in the pot, and move on to the next problem. Unfortunately, never looked back.


Will do, heading to the station to finish commissioning tomorrow. It's a 3 hour drive so I can't exactly hop on down whenever, but I should be able to iron out the kinks tomorrow. Thanks!


----------



## Chrismcd (Apr 9, 2014)

Why not use a master timer and use a lim function to set off the function much better way of doing the logic less scan time 

Sent from my LG-D852 using Tapatalk


----------



## mpetro (Jan 6, 2016)

Well this is embarrassing...

Turns out there were two instances of the subroutine being called by JSR commands in the main routine of the program, which caused problems with the counter incrementing. I knew it was something simple I was missing. 

Thanks for the input everyone!


----------



## psgama (Oct 26, 2015)

Yep. That would do it. Good catch. Glad you found it.


----------



## ScooterMcGavin (Jan 24, 2011)

Thanks for the update and don't feel bad. I couldn't tell you how many times I have forgotten to call my routines and wondered why it wasn't working.


----------



## mpetro (Jan 6, 2016)

scameron81 said:


> Thanks for the update and don't feel bad. I couldn't tell you how many times I have forgotten to call my routines and wondered why it wasn't working.


It's a pretty complex program so we thought it was being caused by something obscure. Just goes to show that you should check over the basics before looking into the more difficult stuff.


----------

