CTU reset question

ceilingwalker

Lifetime Supporting Member
Join Date
Mar 2010
Location
Phoenix, AZ
Posts
1,586
I haven't come across this before. I am trying to understand why the counter doesn't reset to 0, when the .dn is true? It immediately puts a 1 in the .acc instead of the desired 0. I am assuming it has to do with the asynch scan and triggering the counter at the same time that .dn goes true is what is doing this?

Capture.PNG
 
I bet it put a zero, but it most likely incremented again. Place a rung after the reset to catch the ACC, if ACC = 0 then latch a test bit. You could place a one shot after the input or only allow reset when the input is low/off.
 
The RES does reset the counter to 0. It just also resets the .CU bit of the counter.

As such the counter does not 'remember' that it already counted, and, since the input is still true, it counts up to 1 when it scans on the next scan cycle. Nothing to do with the asynchronous scan, that could only be relevant if we are looking at the input being referenced in multiple locations.

You can prevent this from happening by putting your own one-shot after the input, separate from the counter's internal one-shot (the CU/CD bits)
 
The RES does reset the counter to 0. It just also resets the .CU bit of the counter.

As such the counter does not 'remember' that it already counted, and, since the input is still true, it counts up to 1 when it scans on the next scan cycle. Nothing to do with the asynchronous scan, that could only be relevant if we are looking at the input being referenced in multiple locations.

You can prevent this from happening by putting your own one-shot after the input, separate from the counter's internal one-shot (the CU/CD bits)

I tried the OSR, didn't help since it is triggering again. When I place a test bit to trigger the RES manually, it does reset the .acc to 0.
 
exactly. See this link and this link to understand what is happening; pay particular attention to .CU, which is one of the status bits affected by the RESet instructions.

Other approaches:

  • Write 0 to the .ACC value, instead of doing the reset
  • Add an [XIO AveragPkgCTU.CU] or [XIO Local:3:i.Data[0]] on the reset rung, so it won't reset until the trigger of the last count is removed.
    • N.B. this will delay when the TOF starts timing, and may affect the other logic at the end of that rung.
 
Last edited:
I tried the OSR, didn't help since it is triggering again. When I place a test bit to trigger the RES manually, it does reset the .acc to 0.

Then you are not using the one-shot correctly. The counter goes to 1 because the input to the counter is still true when the RES is triggered, a oneshot immediately prior to the counter prevents this. The fact that your manual trigger resets the counter to 0 proves this unless you triggered it while the input was high.

EDIT: My apologies, by 'one-shot' I meant ONS not OSR. OSR would work but would require additional logic.

See this technote: ONS is Rockwell's recommended solution to the issue.
 
Last edited:
I'm pretty sure that if the logic preceding the counter is true when the reset occurs, it will count to 1

Exactly. I don't have RSL500 nearby to play with but I wonder something similar to this would work with that s-ware, since the scan is synchronous (last rung wins)?
 
Exactly. I don't have RSL500 nearby to play with but I wonder something similar to this would work with that s-ware, since the scan is synchronous (last rung wins)?

As has already been stated, this has nothing to do with the scan being synchronous or asynchronous. This issue occurs across all AB software (5, 500 & 5000) using CTU/CTD counters and is an effect of the RES resetting the counter's internal oneshot.
 
My head is still spinning from being bitten off the time I suggested that this issue is a persistent 'bug' with multiple AB CPUs - so I won't dream of suggesting it again. I think I was chewed on for a couple of days by the AB faithful.

The reset instruction resets the bit that is used as a history for rising edge detection of the counter input. The next scan after the reset is interpreted as a new rising edge.

Apparently it's not a bug - it's a feature. You paid for it.
 

Similar Topics

Hi all, I'm newbie here to plctalk! I writing a PLC programm in ladder where I put an output bit to zero during 9s and the same output bit to one...
Replies
13
Views
6,710
Hi, I need to use my CV value from my CTU. if CV = 1 : Red light turns ons if CV = 2 : Green light turns ons, but red goed out if CV = 3 ...
Replies
2
Views
281
Hi, I am confused regarding TIA portal and counters. I use CTU. I wish to have one counter counting 0-10. When it reaches 10 is shall increase...
Replies
23
Views
3,073
This counter is counting when bits_from_traypacker is true (messaging from other machine, this is the servo cycle). After counting 3 it should...
Replies
8
Views
3,255
For a week now, my coworker and I have been troubleshooting a machine which has been displaying some crazy behavior. HMI values were changing on...
Replies
19
Views
4,235
Back
Top Bottom