RSLogix 5000: Losing timer preset values in AOIs

DairyBoy

Member
Join Date
Jun 2007
Location
UK
Posts
393
Processor: 1769-L30ER; Logix 5000: v32.02

I have an AOI that's been used in previous applications without issue, and have added a TON instruction to the version of the AOI in the current application.

There are three other instances of TON instructions in the AOI. In all cases the preset value is written directly into the instruction on the rung, not by a MOV instruction etc. All four preset values can be seen in the master version in the local tags list.

When downloaded to the processor (in run or program mode) the new timer loses its preset value (shows "0"). The only way that it will retain it is if the preset is loaded via a MOV instruction. RA tech couldn't help, so I guess that it's not a version issue.

Has anyone had this and cured it? Thanks.
 
I've also seen that issue and have not seen a cure. I think I was able to type in the preset value into the individual AOI instances though to correct it.
 
If you change the timer preset of one of your instances online, save the program, and download again, does it retain its preset?

When you update an AOI for which there are existing instances, there is an option to "copy all default values of parameters and local tags whose values were modified to all tags of this instruction type". If the timer preset in your AOI instance has a default value of zero, and you updated the AOI with this option selected, all instances would be set to zero.

This would occur not when you downloaded, but when you clicked "OK" on the AOI definition editor. So if your issue is as you described it, this may be unrelated - but it's plausible that you edited an AOI and downloaded it, then noticed the issue, and mistakenly thought the issue occurred when you downloaded, not when you made the edit. If you perform the test above, that should confirm things one way or the other.

For what it's worth, I've never seen a download cause any such symptoms, but I've been caught out by the "copy default values" trick a few times!
 
ASF, I did see the copy all default values option but it remains greyed-out and unchecked when the timer presets are altered. As the local tags show the correct (non zero) value for all timer presets in the offline version, I'd interpret those values as being the defaults.

I just tried an offline edit to one of the previous existing timer presets but the instances don't show the change, although a logical edit is reflected in all instances.

I didn't know that fixed values could be edited in the instances; I'll have a look at that tomorrow- thanks.
 
ASF, I did see the copy all default values option but it remains greyed-out and unchecked when the timer presets are altered. As the local tags show the correct (non zero) value for all timer presets in the offline version, I'd interpret those values as being the defaults.

I just tried an offline edit to one of the previous existing timer presets but the instances don't show the change, although a logical edit is reflected in all instances.
For a timer, the default value is the value set in the definition. That is, if you:
- Have a local AOI parameter called "My_AOI_Timer"
- Within the AOI, put a TON/TOF/RTO on a rung
- Assign "My_AOI_Timer" to that TON/TOF/RTO
- Set a preset in that TON/TOF/RTO instruction
...then the preset you specified is the default for that AOI. Any new instances of that AOI you create after you adjust that preset will be created with the same timer preset as your definition. However, any instances that already existed will not be updated. This is good design practice of course - if you have 200 instances already in your code, and each of them has had their timer preset adjusted according to their application, having them all of a sudden set back to default just because you changed the definition would be a terrible outcome! But, at the same time, sometimes you do want all of your 200 instances to be updated with the new "default" value. That's where that checkbox comes in handy.

The reason it's greyed out is because you made the changes in the AOI's ladder logic, not in the parameter editor. Instead of changing the timer preset in the TON instruction, open the AOI definition dialog box and select the Local Tags tab. Find your timer in the list of local tags, and click the little arrow to expand out the data structure. The first item in the list is My_AOI_Timer.PRE, and you'll see its default value in the third column. You'll notice that it matches the timer preset in your AOI definition ladder logic. Change the default value in the Local Tags editor, and you'll see the "copy all default values" box become available. Check the box and hit apply, and now whatever value you put in that "default" column will be copied to all existing instances of your AOI's. You'll also note that the timer preset in your definition logic will update with the new preset, and all new instances that you create from this point on will likewise get the new default value.

Taking a step back into why this happened to start with - what I suspect has happened is that you've created the new timer in your AOI definition ladder logic, and then applied the change with a timer preset of zero. At that instant, the timer was created in all your existing instances, with a preset of zero. You then updated the preset in your definition, but as I have described above, this change will not push through to your existing instances unless you specifically request it to do so.

I didn't know that fixed values could be edited in the instances; I'll have a look at that tomorrow- thanks.
"Fixed values" is not really an AB term, but you are correct in that some values cannot be edited in the instances. Generally, this is limited to constant operands - e.g. if you have a math instruction that's multiplying Tag_A by 2 and storing the result in Tag_B. You can't change the value of the 2, in the same way that you can't change which tag you are storing the result of Tag_A*2 in - because that's a structural change to the logic. But a timer preset you can vary at any time. A general rule of thumb - if you can change a parameter value outside an AOI online without doing an online edit, you can do it online inside an AOI instance (but not the definition). You can change a timer preset online outside an AOI just by typing a new one in - you don't have to edit the rung, change the value, and accept edit - so you can likewise change a timer preset within an AOI instance online. After all, an AOI instance works just the same as any other piece of code, except that you can't do online edits to it.
 
For a timer, the default value is the value set in the definition. That is, if you:
- Have a local AOI parameter called "My_AOI_Timer"
- Within the AOI, put a TON/TOF/RTO on a rung
- Assign "My_AOI_Timer" to that TON/TOF/RTO
- Set a preset in that TON/TOF/RTO instruction
...then the preset you specified is the default for that AOI. Any new instances of that AOI you create after you adjust that preset will be created with the same timer preset as your definition. However, any instances that already existed will not be updated. This is good design practice of course - if you have 200 instances already in your code, and each of them has had their timer preset adjusted according to their application, having them all of a sudden set back to default just because you changed the definition would be a terrible outcome! But, at the same time, sometimes you do want all of your 200 instances to be updated with the new "default" value. That's where that checkbox comes in handy.

The reason it's greyed out is because you made the changes in the AOI's ladder logic, not in the parameter editor. Instead of changing the timer preset in the TON instruction, open the AOI definition dialog box and select the Local Tags tab. Find your timer in the list of local tags, and click the little arrow to expand out the data structure. The first item in the list is My_AOI_Timer.PRE, and you'll see its default value in the third column. You'll notice that it matches the timer preset in your AOI definition ladder logic. Change the default value in the Local Tags editor, and you'll see the "copy all default values" box become available. Check the box and hit apply, and now whatever value you put in that "default" column will be copied to all existing instances of your AOI's. You'll also note that the timer preset in your definition logic will update with the new preset, and all new instances that you create from this point on will likewise get the new default value.

Taking a step back into why this happened to start with - what I suspect has happened is that you've created the new timer in your AOI definition ladder logic, and then applied the change with a timer preset of zero. At that instant, the timer was created in all your existing instances, with a preset of zero. You then updated the preset in your definition, but as I have described above, this change will not push through to your existing instances unless you specifically request it to do so.


"Fixed values" is not really an AB term, but you are correct in that some values cannot be edited in the instances. Generally, this is limited to constant operands - e.g. if you have a math instruction that's multiplying Tag_A by 2 and storing the result in Tag_B. You can't change the value of the 2, in the same way that you can't change which tag you are storing the result of Tag_A*2 in - because that's a structural change to the logic. But a timer preset you can vary at any time. A general rule of thumb - if you can change a parameter value outside an AOI online without doing an online edit, you can do it online inside an AOI instance (but not the definition). You can change a timer preset online outside an AOI just by typing a new one in - you don't have to edit the rung, change the value, and accept edit - so you can likewise change a timer preset within an AOI instance online. After all, an AOI instance works just the same as any other piece of code, except that you can't do online edits to it.

Another candidate for a "sticky" - great post !
 
ASF, Thank you for taking the time to craft that reply. A very useful reference that has been added to my AB info file. I will apply your advice and hopefully be the wiser for the experience.
 
Last edited:

Similar Topics

Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
112
I am completely stuck on building a ladder program that requires a start button to be pressed 3 times to turn on motor 1. Then motor 2 starts...
Replies
20
Views
489
First off, I'm a hobbyist-level programmer, and this program isn't controlling anything anything that could even remotely be considered "life...
Replies
18
Views
497
Greetings ... someone sent me a request for some student handsouts that I developed ... turns out that I had this hosted on my business website...
Replies
0
Views
123
Back
Top Bottom