I’m taking a big “stab in the dark” here but is it possible that the logic is stuck in a sub routine? Try saving the logic (in RSLogix) with a different name (so you don’t lose your work) and delete all of the sub routines or just create a new very simple program where it’s only file 2 and see if it work (create a timer that runs when you set a bit). I ran into this once (a long time ago) and I think I remember it to be that I had the program jump to a sub routine but not return so when I’d look at the main logic (file 2) nothing was running. Again, that was a long time ago and I don’t clearly remember what I did wrong (I might have just started over). I also think that you can’t have the same item running in two routines (the same timer, T4:0, for example). If you do that I think it won’t run at all in either routine.
With all of that said, when I’d get into trouble I’d just call up Ken so he may look at this post and say I’m way off which is a possibility.
That explanation cannot be the case....
The controller has a "watchdog" time setting that guards against the logic "getting stuck".
In your context, "Getting Stuck" means that the scan of the program doesn't finish within the allotted watchdog time. Reaching the end of program file 2 resets the watchdog, since all of the user code has been scanned.
Nothing stops the user code getting scanned, there are no instructions that the controller will wait for completion. Anything that takes a time (e.g. a MSG (Message) instruction), will have control bits that the controller will look at on each scan to decide how to proceed.
Having said that, there are Program Control Instructions that can prevent the scan getting completed, such as a JMP to a LBL in front of the JMP. If that JMP is enabled too long, program file 2 will not complete within the watchdog time, and the controller will major-fault.
snyderej, assuming your original controller isn't just "faulty" and the fault is bypassing all of its internal integrity checks, a very rare situation!!, then look for any one of the following causes of the symptoms you have described, all have been written on the basis that you said that timers in file 2 are "frozen" .....
1. MCR Zone - MCR (Master Control Reset) Instructions are used in pairs, you will have a conditional MCR to "start" an MCR Zone, and an un-conditional MCR to "end" the zone. If the rung containing the conditional MCR instruction is false, then the following logic is scanned with all rungs starting as false (the programming software still shows a highlighted green power-rail). Because the rungs start as false, all non-retentive outputs within the MCR Zone will be turned off, and timers will not run, etc.
2. JMP / LBL - a JMP instruction will instruct the controller to continue program scan at the rung containing the corresponding LBL instruction. The logic that is "jumped" is not scanned at all, so nothing will happen, outputs won't turn on and off, and timers will not get enabled.
3. TND - a "Temporary End" instruction will terminate the scan of the current program file, so any following logic doesn't get scanned, and can appear to be "frozen".
4. Duplicate references to the same timers somewhere else in the program (eg another program file). If the same timers are "used again", then the rungs with the duplicates on may be false, thus resetting the timers so they don't appear to be running.
If you could post your (zipped) RSS file, there are many people on here who could tell you straight-off if you have a logic (code) problem.
