How can I improve my counter's accuracy?

[nathanb]

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!

 

[Phrog30]

You will need to use a continuous task or a periodic task with faster and higher priority.

 

[Ken Moore]

Is the count coming via an encoder? Are you using a high speed input for the count.
Since you mention periodic task and not OB, I assume this is a Rockwell product, which one?

 

[cardosocea]

I found (though never tested), that the high speed counter card in the 5069 and I believe 1769 have outputs that you can program to activate depending on the counter reading. I assume Control Logix high speed counters to be able to do the same.
I think that's going to be the fastest you'll find as it removes the control from the user program to a dedicated "device".

Is this for a batching operation? Positioning operation?

 

[Bit_Bucket_07]

I don't know if it would help in your situation, but I have improved the accuracy of timed operations by calling a subroutine multiple times each sweep, rather than merely once per sweep. In that way, I was more likely to accurately trigger an event based upon the timer accumulator value being greater than the timer preset, since I got more opportunities to examine the accumulator value.

Of course, the trade-off was in increasing the overall sweep time, although that didn't cause a problem for the particular application in which I employed the patch.

If you are attempting to examine 1000 counts within a 500 ms window, then the application may be beyond the capability of most PLCs.

 

[Ken Roach]

Welcome to the PLCTalk forum community, and thanks for your post ! It's a mix of theory and practice and I'm going to ask a few questions to gain background info.

Tell us more about the source and function of the counter signal. Is it coming from an encoder, or a pulse-wheel, or a flowmeter, or a discrete signal like a photo-eye or proximity sensor ?

What are the outputs operating ? An indicator, or a motor, or a valve, or something else ?

Tell us more about the hardware and logic of the counting function in the PLC.

What make and model of PLC are you using ?

Do you have a specialized high-speed counter or encoder input module, or are you using conventional I/O modules ?

Is the "Counter" function an ordinary CTU or similar general purpose counter, or do you have a special purpose counting or accumulatorutput range configured ?

In the Allen0-Bradley world, the "HSC" and "VHSC" modules generally are the best way to turn on a local output during a small window of encoder pulses. They use very fast local embedded hardware and software to do that sort of small and specific function where ordinary I/O systems and software routines are not fast enough.

 

[drbitboy]

What is the application? What is the meaning of that specific counter e.g. what is the relative significance of a counter value of 123 vs. a counter value of 627? Is it counting actual events (e.g. proximity sensor triggers), or is it simply counting out time?

Is there a unique combination of output states triggered at specific states e.g. at count 0 all output off, at count 123 output 0 is on all others off, at count 234 outputs 1 and 8 on all others off, etc.?

If this counter runs from 0 to 1000 over half a second, then the only way to be perfectly accurate (act on a target count before that count plus 1) is to ensure the scan is always less than 500μs. This is tough enough on its own, but if this is also on a PLC where I/O scan is asynchronous with the continuous program scan, you also have to ensure the I/O scan executes in that same timeframe or better (or have an immediate output instruction). This may be a code golf type problem.

[basically extending @Ken Roach's queries]

 

[nathanb]

Additional Information:

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.

 

[nathanb]

Is the count coming via an encoder? Are you using a high speed input for the count.
Since you mention periodic task and not OB, I assume this is a Rockwell product, which one?

I am using an allen bradley plc (5069 l306erms2). I just now added more information about how the counter works its purpose in the comments.

 

[nathanb]

I found (though never tested), that the high speed counter card in the 5069 and I believe 1769 have outputs that you can program to activate depending on the counter reading. I assume Control Logix high speed counters to be able to do the same.
I think that's going to be the fastest you'll find as it removes the control from the user program to a dedicated "device".

Is this for a batching operation? Positioning operation?

Thank you, I am using a 5069 PLC so maybe I can find something useful. I'll look into this.
I'm not familiar with those term, but I believe batching (its for a packaging machine)

 

[nathanb]

I don't know if it would help in your situation, but I have improved the accuracy of timed operations by calling a subroutine multiple times each sweep, rather than merely once per sweep. In that way, I was more likely to accurately trigger an event based upon the timer accumulator value being greater than the timer preset, since I got more opportunities to examine the accumulator value.

Of course, the trade-off was in increasing the overall sweep time, although that didn't cause a problem for the particular application in which I employed the patch.

If you are attempting to examine 1000 counts within a 500 ms window, then the application may be beyond the capability of most PLCs.

That's a great idea. I will try this for sure, thank you.

 

[nathanb]

Welcome to the PLCTalk forum community, and thanks for your post ! It's a mix of theory and practice and I'm going to ask a few questions to gain background info.

Tell us more about the source and function of the counter signal. Is it coming from an encoder, or a pulse-wheel, or a flowmeter, or a discrete signal like a photo-eye or proximity sensor ?

What are the outputs operating ? An indicator, or a motor, or a valve, or something else ?

Tell us more about the hardware and logic of the counting function in the PLC.

What make and model of PLC are you using ?

Do you have a specialized high-speed counter or encoder input module, or are you using conventional I/O modules ?

Is the "Counter" function an ordinary CTU or similar general purpose counter, or do you have a special purpose counting or accumulatorutput range configured ?

In the Allen0-Bradley world, the "HSC" and "VHSC" modules generally are the best way to turn on a local output during a small window of encoder pulses. They use very fast local embedded hardware and software to do that sort of small and specific function where ordinary I/O systems and software routines are not fast enough.

I added more information on comment 8 hopefully that helps. As for the other not answered in that comment:
The outputs are operating motors and eventually some air valves.
The PLC is an allen bradley 5069 l306erms2, the driver is a Kinetix 5500s2.
I don't have a counter module but my supervisor will get one if needed. I have one standard input and output module.
I haven't heard of HSC or VHSC modules but I will look into them, thank you.

 

[Bit_Bucket_07]

I added more information on comment 8 hopefully that helps. As for the other not answered in that comment:
The outputs are operating motors and eventually some air valves.
The PLC is an allen bradley 5069 l306erms2, the driver is a Kinetix 5500s2.
I don't have a counter module but my supervisor will get one if needed. I have one standard input and output module.
I haven't heard of HSC or VHSC modules but I will look into them, thank you.

An "HSC" is a High Speed Counter module. It is used to count pulses that are too fast to be processed by the PLC's standard IO system.

As pointed out earlier by drbitboy, processing high speed pulses (whether generated internally or externally to the PLC program logic) is also limited by the CPU sweep time and inherent latency in IO updates.

 

[nathanb]

What is the application? What is the meaning of that specific counter e.g. what is the relative significance of a counter value of 123 vs. a counter value of 627? Is it counting actual events (e.g. proximity sensor triggers), or is it simply counting out time?

Is there a unique combination of output states triggered at specific states e.g. at count 0 all output off, at count 123 output 0 is on all others off, at count 234 outputs 1 and 8 on all others off, etc.?

If this counter runs from 0 to 1000 over half a second, then the only way to be perfectly accurate (act on a target count before that count plus 1) is to ensure the scan is always less than 500μs. This is tough enough on its own, but if this is also on a PLC where I/O scan is asynchronous with the continuous program scan, you also have to ensure the I/O scan executes in that same timeframe or better (or have an immediate output instruction). This may be a code golf type problem.

[basically extending @Ken Roach's queries]

I posted more information that answers these on comment #8, hopefully that provides enough info.
I thought it may just be a rounding issue with how I set up the counter, but after I set the counter to a continuous task, it runs very accurately and will register the counter value within a range of 1 or 2 (by using a LIM instruction). It's the periodic tasks that have trouble keeping up with the counter, even when set to highest priority.

 

[Ken Roach]

Take a step back and describe the physical parts of the packaging machine that you are controlling.

Is it a packaging machine that your company is building, or do you have a control system built by the packaging machine OEM ?

Because you're using a servo motion controller (a Kinetix servo drive), there are very probably ways to do what you want based on the position of the servo axis, rather than trying to implement a timer + counter + accumulator to attempt to track or emulate that axis position.

In the Kinetix programming manuals, look up "Axis Watch Arm" and "Motion Axis Output Cam" instructions.

You mention that the outputs are "motors"; what kind of mechanisms do the motors control, and what type of motor controls (servo, VFD, across-the-line, clutch+brake, etc) do they use ?