How can I improve my counter's accuracy?

[Nathanb 0]

So I have a plc program where most of the outputs are based on a counter that goes from 0 to 1000. The counter speed is adjustable and is generally set to run through a full cycle (count from 0 to 1000) anywhere between 0.5 to 2 seconds. The problem is, when I try to energize an output by using an EQU instruction, it will almost always skip the count because the scan time is not fast enough. I've been using a LIM instruction which has been working, but its not quite as accurate as it needs to be.
I switched the counter logic to be continuous to try to make it faster which made it almost perfectly accurate... But only in the continuous task; it made the other periodic task significantly less accurate.
I was curious if any of you had any tips on how to remedy this or just general help.
I am still relatively new to PLCs and ladder logic so any advice would be awesome, Thanks in advance!

Edit:

The purpose of the counter is to cycle through from 0 to 1000 over and over again. My outputs actuate during a certain interval within this cycle (For example I would say actuate from 300 to 800 and it would stop and end once it hit those values via an EQU or LIM instruction). I wrote the logic as follows: First I calculate how many cycles per minute I want to perform, using that value I calculate how many times I want to increment my counter per millisecond. Then a timer is given a preset of the total cycle time. While that timer is running I continuously multiply the timer's accumulated value by the "cycle count per millisecond" that I calculated earlier; the resulting value is the current count that all my outputs are based on... Hopefully that makes sense, I know it's not the best but I could not figure out a better way of doing it and I know rounding is certainly making the accuracy worse.

My hardware is: Allen Bradely PLC (5069 l306erms2), 5069-ob16, 5069-ib16, and a Kinetix 5500s2 Driver for my motor(s)

Edited 27 May 2021 by Nathanb

[Joe E. 259]

Is this just a free-running counter that counts 0-1000 based on time? Does it use a timer instruction to trigger a CTU instruction?

If so, and if accuracy is super important, You might try using high priority periodic task with a time base that's short enough to be accurate enough but no shorter. If you want it to go from 0-1000 in 500ms, and if each count of the counter is important for accuracy, your task interval would be 0.5ms. You can use an SSV instruction to adjust the task interval as needed.The first instruction would be an ADD that adds 1 to the accumulator tag. Then you do what you need to with the counter value inside the periodic task. The periodic task will interrupt the continuous task as needed, so you want to be careful or you can cause a watchdog fault of the continuous task if it's interrupted too often. If you use the continuous task to control the outputs, the timing will be off by a scan or so plus the RPI of the output module plus the output's response time. What's your current scan time for the continuous task?

What exactly are you trying to accomplish? There may be a better way.

[BobLfoot 301]

@Nathanb  -- @Joe E. makes some valid points.  If accuracy is really critical you may want to use counter cards with dedicated outputs on the card.  The decision to fire the output then does not depend on the scan of the plc or the period of the task.  Of course you didn't say what PLC you were using and how many outputs you needed.

[ElectronGuru 81]

Counting from 0 - 1000 in 500ms is pretty quick when related back to changing the state of an output. Any compare instruction (EQU, LIM, etc) will only remain true for the period of time the .ACC is either equal to, or within the limit of the instruction, which is this case is likely just a few milliseconds. 

When I've come across similar challenges I've had pretty good luck using an OTL as the output instruction. Even if the EQU is true for only 1ms during the scan, that's enough to latch the output regardless of whether it's in a continuous, periodic, or event task. The drawback is, of course, you will now also need an OTU to unlatch the output at some later point.

As mentioned above, more info about your controller, version of Studio, and process would be helpful.

[Joe E. 259]

So, I just pulled up a CompactLogix program I have running on a 1769-L33ER on my desk. The shortest RPI (Requested Packet Interval) for a standard 16-point 24VDC output module is 0.5ms. This is the FASTEST the output module could possibly get updated information from the CPU. It may be longer than that depending on backplane traffic (and probably other factors as well). The 1769-OB16's delays are 0.1ms to turn the output on and 1.0ms to turn it off. The -OB16P (with protected output channels) is slower at 1.0ms on delay and 2.0ms off delay. This is an older manual, but should give you an idea. You'd have to find the specifications of the exact module you're using. In my example, if your periodic task is running every 0.5ms, it will be up to another 0.5ms (RPI) plus 0.1ms before the standard output turns on and another 0.5ms plus 1.0ms to turn off. The RPI is "requested" and may take longer. It's also asynchronous to the program execution and may occur sooner after the periodic scan updates the output table than the RPI. It's unpredictable.