You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

Reply
 
Thread Tools Display Modes
Old January 15th, 2022, 12:37 PM   #1
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
CTU reset question

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
  Reply With Quote
Old January 15th, 2022, 12:52 PM   #2
Jlandwerlen
Member
United States

Jlandwerlen is offline
 
Join Date: Jan 2022
Location: Atlanta
Posts: 57
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.
  Reply With Quote
Old January 15th, 2022, 12:52 PM   #3
plvlce
Lifetime Supporting Member
United States

plvlce is offline
 
Join Date: May 2017
Location: Michigan
Posts: 521
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)
  Reply With Quote
Old January 15th, 2022, 01:00 PM   #4
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
Quote:
Originally Posted by plvlce View Post
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.
  Reply With Quote
Old January 15th, 2022, 01:03 PM   #5
dmroeder
Lifetime Supporting Member
United States

dmroeder is offline
 
dmroeder's Avatar
 
Join Date: Apr 2006
Location: Vancouver, WA
Posts: 3,151
I'm pretty sure that if the logic preceding the counter is true when the reset occurs, it will count to 1
  Reply With Quote
Old January 15th, 2022, 01:05 PM   #6
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 4,974
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.
__________________
i) Take care of the bits, and the bytes will take care of themselves.
ii) There is no software problem that cannot be solved with another layer of indirection.
iii) Measurement is hard.
iv) I solemnly swear that I am up to no good

Last edited by drbitboy; January 15th, 2022 at 01:12 PM.
  Reply With Quote
Old January 15th, 2022, 01:09 PM   #7
plvlce
Lifetime Supporting Member
United States

plvlce is offline
 
Join Date: May 2017
Location: Michigan
Posts: 521
Quote:
Originally Posted by ceilingwalker View Post
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 by plvlce; January 15th, 2022 at 01:14 PM.
  Reply With Quote
Old January 15th, 2022, 01:14 PM   #8
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
Quote:
Originally Posted by dmroeder View Post
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)?
  Reply With Quote
Old January 15th, 2022, 01:16 PM   #9
plvlce
Lifetime Supporting Member
United States

plvlce is offline
 
Join Date: May 2017
Location: Michigan
Posts: 521
Quote:
Originally Posted by ceilingwalker View Post
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.
  Reply With Quote
Old January 15th, 2022, 01:16 PM   #10
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
Quote:
Originally Posted by drbitboy View Post
[*]Write 0 to the .ACC value, instead of doing the reset
Tried this also......same result.
  Reply With Quote
Old January 15th, 2022, 01:23 PM   #11
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
Quote:
Originally Posted by plvlce View Post
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.
  Reply With Quote
Old January 15th, 2022, 01:32 PM   #12
Corsair
Lifetime Supporting Member
United States

Corsair is offline
 
Join Date: Dec 2020
Location: Missouri
Posts: 137
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.
  Reply With Quote
Old January 15th, 2022, 01:36 PM   #13
ceilingwalker
Lifetime Supporting Member
United States

ceilingwalker is offline
 
ceilingwalker's Avatar
 
Join Date: Mar 2010
Location: Phoenix, AZ
Posts: 1,449
Quote:
Originally Posted by plvlce View Post
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.
  Reply With Quote
Old January 15th, 2022, 02:40 PM   #14
drbitboy
Lifetime Supporting Member
United States

drbitboy is offline
 
drbitboy's Avatar
 
Join Date: Dec 2019
Location: Rochester, NY
Posts: 4,974
Quote:
Originally Posted by ceilingwalker View Post
Tried this also......same result.
Interesting, because that has worked for me in the past (i.e. [MOV 0 blah.ACC]).
__________________
i) Take care of the bits, and the bytes will take care of themselves.
ii) There is no software problem that cannot be solved with another layer of indirection.
iii) Measurement is hard.
iv) I solemnly swear that I am up to no good

Last edited by drbitboy; January 15th, 2022 at 02:40 PM. Reason: Fix typo
  Reply With Quote
Old January 15th, 2022, 03:00 PM   #15
gas
Member
United States

gas is offline
 
Join Date: Nov 2005
Location: Buffalo, NY
Posts: 523
Do a search. Ron, as always, has a great post about this.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Micro 850 Accumulator reset Jody Collins LIVE PLC Questions And Answers 0 February 8th, 2017 10:20 AM
Mitsubishi Beginners question - System Reset DecrepitDragon LIVE PLC Questions And Answers 4 June 1st, 2015 10:06 AM
Mitsubishi F1 series counter question. Tharon LIVE PLC Questions And Answers 4 March 5th, 2015 04:48 PM
Manual vs. Automatic Reset jrexrode LIVE PLC Questions And Answers 14 January 20th, 2015 05:49 PM
RSLinx and yellow question marks. johnmac LIVE PLC Questions And Answers 2 October 14th, 2014 12:32 PM


All times are GMT -4. The time now is 03:32 AM.


.