Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations pierreick on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Issues With RTO In RSLogix 5000

Status
Not open for further replies.

Eliteautomation1101

Electrical
Aug 1, 2014
2
All,
I wrote a recipe based program that has been running flawless for about 8 months now. All of a sudden this week, the RTO's are starting to act flaky. The sub-routines are all recipe dependent and I'm using a separate RTO in each recipe. These timers are only reset once throughout each sub-routine, but now, it's like they are resetting on their own. As soon as the DN bit sets the timer starts over and the rung containing the (res) is NOT true, holding the program in its current step. I do have the TT bit set as a push button indicator on the HMI. Could this have anything to do with it? Is it possible for the DN bit and TT bit to go high simultaneously depending on the scan times? This has been working fine since the install, so it's got me stumped. Any help is appreciated!

Elite Automation
elite.automation11010@gmail.com
 
Replies continue below

Recommended for you

I have had problems where a FLL or where a COP statements are used to clear or set data, where the source address is longer then the destination. This would have an unknown type of condition, where the overlapping source would clear or write some value into some tag in memory. Since contrologix is a tag based memory and memory is managed by the plc in the firmware, this would give you the results you have now.

I would look at any code that was added from the time this happened. Look for a FLL/COP source that is bigger than the destination address.

Also, look for rungs where you do some input statements, then output statements, then more input statements, then output statements (flowing from right to left in order). If the res was done in this type of rung and it was a one scan condition at beginning of rung, some times or 95% of the time the output statements at the end would not get executed for 5% of the time.

I have done these two above and cleaned up more of this type of sloppy logic in sites before. It was a painful memeory.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor