CTU reset question

[ceilingwalker]

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

[Jlandwerlen]

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.

[plvlce]

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)

[ceilingwalker]

Originally Posted by plvlce

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.

[dmroeder]

I'm pretty sure that if the logic preceding the counter is true when the reset occurs, it will count to 1

[drbitboy]

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.

[plvlce]

Originally Posted by ceilingwalker

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.

[ceilingwalker]

Originally Posted by dmroeder

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)?

[plvlce]

Originally Posted by ceilingwalker

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.

[ceilingwalker]

Originally Posted by drbitboy

[*]Write 0 to the .ACC value, instead of doing the reset

Tried this also......same result.

[ceilingwalker]

Originally Posted by plvlce

See this technote: ONS is Rockwell's recommended solution to the issue.

Exactly what I was thinking was happening, thank you for the link. I am not sure why I was thinking scan type would affect this.

[Corsair]

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.

[ceilingwalker]

Originally Posted by plvlce

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

No need to apologize, I am the one that didn't follow directions.

It works! Thank you.

[drbitboy]

Originally Posted by ceilingwalker

Tried this also......same result.

Interesting, because that has worked for me in the past (i.e. [MOV 0 blah.ACC]).

[gas]

Do a search. Ron, as always, has a great post about this.