Best practices using ONS in an AOI - RSLogix 5000

[TJMC]

Hi All,

I'm working on an AOI that needs a ONS incorporated into the logic. Every time I run the instruction the ONS gets stuck on even when the rung is clearly false. I tried a few variations in case there was some sort of problem in how the AOI's logic is evaluated. I've tried using an OSR instruction instead with the same results.

Is there any best practices or caveats that I should be aware of when using ONS inside an AOI?

Thanks in advance.

TJ

 

[JeremyM]

Screenshot? Is the bit being written to elsewhere?

 

[drbitboy]

Is there any best practices or caveats that I should be aware of when using ONS inside an AOI?

Only that the storage bit be used only for that one-shot; I would assume that bit comes from storage tied to each instance ("instantiation") of that AOI e.g. in a UDT or some such.

 

[nyanpasu]

Shot in the dark here, but if your AOI is ran conditionally, you might need to reset them with an EnableInFalse routine.

 

[Operaghost]

Shot in the dark here, but if your AOI is ran conditionally, you might need to reset them with an EnableInFalse routine.

Exactly my thought too. A common mistake I see in people first starting to use AOIs is forgetting that they have to write logic to tell the AOI what it is supposed to do when it is false. They often assume that bits will turn off and timers will reset.

OG

 

[GaryS]

I think I can add something here that may help
I apologize in advance I am not a good writer and in particularly in technical things so I hope can understand what I am trying to explain.

Is your ONS bit tag declared as a Local tag within the AOI itself or did you create the tag in the Global processor database. The different location will change the way it works.
You must also remember that the ONS is function or a subroutine if you will. The tag is just stores the status of the function .
A few thing to always keep in mind when working with an AOI
You pass parameters into and out of the AOI and every time the AOI is executed you running the exact same AOI code (NOT A COPY but the same original code just using different parameter values )
When the rung in front of the AOI is true it will execute just like any other program top left to bottom right . All the parameters are buffered within the AOI and that buffered parameter data is what is used within the AOI code. When the AOI is executed the buffers are first cleared the program runs once then the parameter values are passed into the buffers and the program executes
If the program executes with the parameter controlling the ONS is false (Cleared) the program will read it as a false rung and clear the ONS status Tag. But the next scan the parameter may be set and the output of the ONS will be true for that one scan you may see the output for the ONS toggle ON and OFF the hole time the AOI is executing . if it’s an ONS it may just appear to stay on when in reality it may be toggling on and off with every pass. With a program scan time of 200ms you will never see it change.
If you write directly to an input parameter you will have this problem, you always link an input parameters to a defined tag in the tag data base the problem goes away then . I had a similar problem some time back worked on it for about 3 days finely called tech support they never heard of it before but when they ran my code it was there, we figured out the problem and the fixit was the parameter buffering. While you can write directly to an input parameter but if you do you could have strange problems.
You should always link an input parameter to a defined tag and write to that tag.

I hope this helps

 

[Rsflipflop256]

Shot in the dark here, but if your AOI is ran conditionally, you might need to reset them with an EnableInFalse routine.

this guy wins