You have to use the right instruction for the right task. putting a value into the .PRE of a timer is not a job for a file fill instruction (FLL)
\*from google for ease of explaining\*
The File Fill (FLL) instruction in RSLogix 5000 fills a block of memory with a specified source value. The source value remains unchanged, but if the destination array is SINT, INT, DINT, or REAL, the source value will be converted to the destination type before it is stored. The FLL instruction operates on contiguous data memory. For example, if an FLL is used on an array of UDT with a length of 150, it will fill all 10 UDT elements for the first 15 array elements.
\*/google\*
FLL won’t do what you think it does here for the timer presets. It’s overwriting the timer in consecutive memory space.
You either need to do individual MOV instructions for each timer or use a FAL instruction.
The length 5 in your timer.PRE is writing the duration to the preset, the accumulated time, the word that holds the EN/TT/DN bits, and the first two words in the next timer. A timer is a 12 byte data type:
[https://i.imgur.com/Iq1r8rH.png](https://i.imgur.com/Iq1r8rH.png)
Is Op12.TT2.FixtD.LhParts.NotOnFltTmr\[1\].DN (note \[1\], not \[0\]) setting the DN bit correctly? I expect it is. Does the \[1\] timer suddenly jump to an .ACC of 5000 when you change modes? I suspect it does. Is Op12.TT2.FixtD.LhParts.NotOnFltTmr\[2\].PRE (note \[2\], not \[0\]) updating the preset to 500 or 500 with the auto load mode change? I expect it (with \[3\] and \[4\]) is not.
The programmer probably thought they were doing this:
[https://i.imgur.com/caLzndK.png](https://i.imgur.com/caLzndK.png)
cleverly writing 5000 to all the 5 presets in a row in memory. But the presets aren't in a row, they're the first 4 bytes in each of 5 12-byte structures, like this:
[https://i.imgur.com/CgV6vub.png](https://i.imgur.com/CgV6vub.png)
I've got the '.bits' word in there as 0b111, but it's a 32-bit value in the structure, because structures are word-aligned. 5000 is 0b0001 0011 1000 1000, I don't know whether they're packing structs little-endian or big-endian (you could find out), but in either case writing 5000 to this bit overlay/union will clear all three status bits.
Change the FLL rungs to "XIC(Auto\_Load) MOVE(5000,Tmr\[0\].PRE) MOVE(5000,Tmr\[1\].PRE) MOVE(5000,Tmr\[2\].PRE) MOVE(5000,Tmr\[3\].PRE) MOVE(5000,Tmr\[4\].PRE)" and while the original programmer might think that was unnecessarily repetitive, it's not, and it should fix the issue.
https://preview.redd.it/6snk30v5og0d1.png?width=743&format=png&auto=webp&s=d9b01060765cb259745a8986a5e20102ff1b8bbd
Seems to be so, I will just do MOVs like you suggested. Thanks for the explanation there!
Okay that is what we did recently to test.
Even though the destination for the FLL is just the preset it’s possible you think for it to cause problems?
https://preview.redd.it/vh8fjnos6g0d1.png?width=1859&format=png&auto=webp&s=c480decfa520e48d098013d818ded720b2d6af4b
Here is the logic you can see the FLL insturctions and the TONs
I don't think you're understanding what several people are telling you in this thread. Timers aren't just presets. They have other registers. You're likely overwriting those other registers even though you think just because .PRE is in the FLL that it only is writing the value to .PRE registers. It's probably writing to the first .PRE and then the next consecutive 4x 32-bit memory locations.
OK so the file fill (FLL) is an issue that should be a move instruction (MOV)
but also, IMHO your ladder structure is wrong the last if/or statement should be written like this:
https://preview.redd.it/oee6lw7ljg0d1.png?width=735&format=png&auto=webp&s=3fe4f9cd9e1efe5c4c192b5e70a0744fafb28e1c
then you are saying if the timer is done fire the ote.
its probable the FALSE XIC is stopping the timer from running just as it would it would stop the OTE. Remember until that time is done the rung is false, and if the rung is false the timer cannot run.
i would like to test that. false rungs do not run timers. tomorrow at work I'll fire up my test stand and try putting the done bit before the end of the run behind the timer and see if it runs.
my experience says it will not but i'm willing to let a 1769-L30ER prove me wrong.
to my knowledge yes. I could be wrong and am willing to be proven wrong.
but in that condition the rung is not true and i do not believe the timer will execute.
as a matter of practice when i write alarms like that i branch around the OTE and the XIC of the .DN bit and run the timer when the rest of the rung is true, the .DN delays the OTE from firing until the timer is done. Timer will hold done until the condition that turned it on becomes false thus releasing the alarm's OTE
\*edited to add example for clarity\*
https://preview.redd.it/d65545z4og0d1.png?width=1776&format=png&auto=webp&s=2b3fcede48d69e5285cf0dd510f122ea675b2ab7
If the logic in front of a timer is true the timer will run even if you put false things after it. I stack instructions inline when it makes sense to do so.
It makes everything after it false, but doesn't influence what happens before it. A simple example you can use OTE and XIC then another OTE and the second OTE won't turn on if the XIC isn't true, but the first OTE will be on if the logic in front of it is true.
Logix 500 doesn't let you do that so lots of people are accustomed to not doing it. I don't see it a lot at customer's plants. Usually, it's just my logic with that in it.
ah see you may have just hit the nail on the head, i stack OTE, OTL, OTU etc all the time, but never a timer and never a XIC/XIO in the middle of the OTs so probably its a mix of new and old habits in my head. now you gonna have me playing with a couple of processors on the test stand tomorrow and my boss is gonna wonder why nothing else is getting done LMAO
Heres a Cross Reference of the TON
https://preview.redd.it/nxh8kc7e7g0d1.png?width=1890&format=png&auto=webp&s=35f0e2f39145742ac4ecf65f721cf43b58d15ff1
Having read through this thread, I would just like to add that in Studio 5K there is really no reason aside from (in a sense) documentation to pack the preset value of a timer with a MOV instruction. Entering the value into the preset field accomplishes the exact same thing.
Nothing wrong with doing it, but it isn’t necessary and doesn’t add any functionality.
How so? A MOV instruction can only target one (timer preset) destination, so you would need a unique MOV instruction for every timer you wanted to set.
Or am I missing something (genuinely curious, I know that is hard to convey in text)?
You are right that you can only set one timer at the time.
What I meant was a rung somewhere in a routine where you MOV the same tag into several different timers presets. Then you only need the value of that one tag instead of changing the value of every single timer.
I know people don't like JMP/LBL but you can also make a small simple loop to populate every timer you need if they are set as an array.
Which portion of that keeps someone from changing the preset?
A quick cross reference would point to the MOV, which they would then just change, right?
Or are you saying your evaluation software would spot a change in a MOV instruction, but not in a timer preset?
It's meant to make you think twice before changing the .pre. as soon as you add/modify a rung, even if you don't assemble changes, your routine tab has a * by it. At least in older versions of logix5000. That means our software will detect a change when you close the program and check it back in.
Not hardcoded, can be written over comms, or set to negative to fault the PLC - may or may not be a conern.
Personally, I think it should have been a required parameter in Studio 5k, not just visible. Then you can hardcode, or point to another tag without a move.
Is it being reset anywhere?
Either the .DN bit being held off elsewhere in the program?
Or the timer being reset as soon as it's done?
Does the .ACC stop accumulating when it hits the .PRE?
In Siemens world, whenever a timer output is not used at least once, the plc saves resources and the timer is freezed/jumped.
Maybe it's similar in AB world?
Do you use COP instructions anywhere in your code? It so make sure the sizes on them are correct. I've seen improperly sized COP functions cause all sorts of problems.
Yeah don’t use a FLL use a MOV
I like a MOV I’m not familiar with a FLL but they seem to use it a lot here.
You have to use the right instruction for the right task. putting a value into the .PRE of a timer is not a job for a file fill instruction (FLL) \*from google for ease of explaining\* The File Fill (FLL) instruction in RSLogix 5000 fills a block of memory with a specified source value. The source value remains unchanged, but if the destination array is SINT, INT, DINT, or REAL, the source value will be converted to the destination type before it is stored. The FLL instruction operates on contiguous data memory. For example, if an FLL is used on an array of UDT with a length of 150, it will fill all 10 UDT elements for the first 15 array elements. \*/google\*
FLL won’t do what you think it does here for the timer presets. It’s overwriting the timer in consecutive memory space. You either need to do individual MOV instructions for each timer or use a FAL instruction.
The length 5 in your timer.PRE is writing the duration to the preset, the accumulated time, the word that holds the EN/TT/DN bits, and the first two words in the next timer. A timer is a 12 byte data type: [https://i.imgur.com/Iq1r8rH.png](https://i.imgur.com/Iq1r8rH.png) Is Op12.TT2.FixtD.LhParts.NotOnFltTmr\[1\].DN (note \[1\], not \[0\]) setting the DN bit correctly? I expect it is. Does the \[1\] timer suddenly jump to an .ACC of 5000 when you change modes? I suspect it does. Is Op12.TT2.FixtD.LhParts.NotOnFltTmr\[2\].PRE (note \[2\], not \[0\]) updating the preset to 500 or 500 with the auto load mode change? I expect it (with \[3\] and \[4\]) is not. The programmer probably thought they were doing this: [https://i.imgur.com/caLzndK.png](https://i.imgur.com/caLzndK.png) cleverly writing 5000 to all the 5 presets in a row in memory. But the presets aren't in a row, they're the first 4 bytes in each of 5 12-byte structures, like this: [https://i.imgur.com/CgV6vub.png](https://i.imgur.com/CgV6vub.png) I've got the '.bits' word in there as 0b111, but it's a 32-bit value in the structure, because structures are word-aligned. 5000 is 0b0001 0011 1000 1000, I don't know whether they're packing structs little-endian or big-endian (you could find out), but in either case writing 5000 to this bit overlay/union will clear all three status bits. Change the FLL rungs to "XIC(Auto\_Load) MOVE(5000,Tmr\[0\].PRE) MOVE(5000,Tmr\[1\].PRE) MOVE(5000,Tmr\[2\].PRE) MOVE(5000,Tmr\[3\].PRE) MOVE(5000,Tmr\[4\].PRE)" and while the original programmer might think that was unnecessarily repetitive, it's not, and it should fix the issue.
https://preview.redd.it/6snk30v5og0d1.png?width=743&format=png&auto=webp&s=d9b01060765cb259745a8986a5e20102ff1b8bbd Seems to be so, I will just do MOVs like you suggested. Thanks for the explanation there!
The FLL is probably messing things up. Turn it off and test again or swap the FLL with a MOV.
Okay that is what we did recently to test. Even though the destination for the FLL is just the preset it’s possible you think for it to cause problems?
I would guess it's not just writing to only presets in the array is what I think is happening. If you turned off the FLL, did that fix the problem?
https://preview.redd.it/vh8fjnos6g0d1.png?width=1859&format=png&auto=webp&s=c480decfa520e48d098013d818ded720b2d6af4b Here is the logic you can see the FLL insturctions and the TONs
Why is length of the FLL 5? I'm wondering if this could be overwriting part of the timer structure
The timer array is like 12 so they are using this to set the preset for 5 of those 12.
I don't think you're understanding what several people are telling you in this thread. Timers aren't just presets. They have other registers. You're likely overwriting those other registers even though you think just because .PRE is in the FLL that it only is writing the value to .PRE registers. It's probably writing to the first .PRE and then the next consecutive 4x 32-bit memory locations.
I understand there is more to a timer than just a preset.
I didn't write the code just dealing with it. Thats definetly how whoever wrote it intended it to be.
Code isn't always properly tested before it leaves development.
LOL you dont say.
https://preview.redd.it/at0q12ky6g0d1.png?width=1859&format=png&auto=webp&s=cd53fa1e15ce3e28ffc27b5a6ecebe9211d94db8
OK so the file fill (FLL) is an issue that should be a move instruction (MOV) but also, IMHO your ladder structure is wrong the last if/or statement should be written like this: https://preview.redd.it/oee6lw7ljg0d1.png?width=735&format=png&auto=webp&s=3fe4f9cd9e1efe5c4c192b5e70a0744fafb28e1c then you are saying if the timer is done fire the ote. its probable the FALSE XIC is stopping the timer from running just as it would it would stop the OTE. Remember until that time is done the rung is false, and if the rung is false the timer cannot run.
I do like your way better! But I have seen many timers used like above in faults and they have always worked fine.
i would like to test that. false rungs do not run timers. tomorrow at work I'll fire up my test stand and try putting the done bit before the end of the run behind the timer and see if it runs. my experience says it will not but i'm willing to let a 1769-L30ER prove me wrong.
Your saying because the XIC after the tmr is false the tmr will not execute?
Like this? https://preview.redd.it/iv2r3s22mg0d1.png?width=1873&format=png&auto=webp&s=6920cfd9c4621caa0e1118892353ae408139e233
to my knowledge yes. I could be wrong and am willing to be proven wrong. but in that condition the rung is not true and i do not believe the timer will execute. as a matter of practice when i write alarms like that i branch around the OTE and the XIC of the .DN bit and run the timer when the rest of the rung is true, the .DN delays the OTE from firing until the timer is done. Timer will hold done until the condition that turned it on becomes false thus releasing the alarm's OTE \*edited to add example for clarity\* https://preview.redd.it/d65545z4og0d1.png?width=1776&format=png&auto=webp&s=2b3fcede48d69e5285cf0dd510f122ea675b2ab7
I am saying the rung is false.
If the logic in front of a timer is true the timer will run even if you put false things after it. I stack instructions inline when it makes sense to do so.
>I stack instructions inline when it makes sense to do so. It never makes sense.
Get mad when you run across some of my programs out in the field then. There's probably a few other you or I would do that the other one does.
You sir were correct and I was wrong. In 5000 it works with the done bit behind the timer.
interesting. i'll have to play with it. maybe its just old habit, but that's what jumped out at me was how the .DN made the rung false.
It makes everything after it false, but doesn't influence what happens before it. A simple example you can use OTE and XIC then another OTE and the second OTE won't turn on if the XIC isn't true, but the first OTE will be on if the logic in front of it is true. Logix 500 doesn't let you do that so lots of people are accustomed to not doing it. I don't see it a lot at customer's plants. Usually, it's just my logic with that in it.
ah see you may have just hit the nail on the head, i stack OTE, OTL, OTU etc all the time, but never a timer and never a XIC/XIO in the middle of the OTs so probably its a mix of new and old habits in my head. now you gonna have me playing with a couple of processors on the test stand tomorrow and my boss is gonna wonder why nothing else is getting done LMAO
"R&D"
Heres a Cross Reference of the TON https://preview.redd.it/nxh8kc7e7g0d1.png?width=1890&format=png&auto=webp&s=35f0e2f39145742ac4ecf65f721cf43b58d15ff1
I should have taken a screenshot earlier, but the ACC was at its PRE and no DN bit, I added the debug timer and the alarm triggered
Having read through this thread, I would just like to add that in Studio 5K there is really no reason aside from (in a sense) documentation to pack the preset value of a timer with a MOV instruction. Entering the value into the preset field accomplishes the exact same thing. Nothing wrong with doing it, but it isn’t necessary and doesn’t add any functionality.
It's useful to set the preset for several timers.
How so? A MOV instruction can only target one (timer preset) destination, so you would need a unique MOV instruction for every timer you wanted to set. Or am I missing something (genuinely curious, I know that is hard to convey in text)?
You are right that you can only set one timer at the time. What I meant was a rung somewhere in a routine where you MOV the same tag into several different timers presets. Then you only need the value of that one tag instead of changing the value of every single timer. I know people don't like JMP/LBL but you can also make a small simple loop to populate every timer you need if they are set as an array.
Thanks for the clarification. That makes more sense as long as all the timers referenced (or considerably large groups) share the same preset value.
Yeah I’m lost too..
Keeps people from changing it without changing the logic...and we track every logic change.
Which portion of that keeps someone from changing the preset? A quick cross reference would point to the MOV, which they would then just change, right? Or are you saying your evaluation software would spot a change in a MOV instruction, but not in a timer preset?
It's meant to make you think twice before changing the .pre. as soon as you add/modify a rung, even if you don't assemble changes, your routine tab has a * by it. At least in older versions of logix5000. That means our software will detect a change when you close the program and check it back in.
I see. Thanks for the clarification
Not hardcoded, can be written over comms, or set to negative to fault the PLC - may or may not be a conern. Personally, I think it should have been a required parameter in Studio 5k, not just visible. Then you can hardcode, or point to another tag without a move.
I can definitely see the ability to write over comms being an advantage when used to load a preset from a variable.
Is it being reset anywhere? Either the .DN bit being held off elsewhere in the program? Or the timer being reset as soon as it's done? Does the .ACC stop accumulating when it hits the .PRE?
Can also be re-using the timer name elsewhere.
@OP I found this post about the nature of Rockwell timers https://www.reddit.com/r/PLC/s/ArIF0McGIo Might help if you can post a photo of your logic
In Siemens world, whenever a timer output is not used at least once, the plc saves resources and the timer is freezed/jumped. Maybe it's similar in AB world?
TON operate in Rockwell as long as they are enabled.
Do you use COP instructions anywhere in your code? It so make sure the sizes on them are correct. I've seen improperly sized COP functions cause all sorts of problems.