ONS behavior

[waterboy 7]

I read in the help file that an ONS will run for one program scan. So I used one in a ladder after an EQU to set an OTE. That OTE bit is used later in a Function Block Totalizer. But the Totalizer didn't reset when it was supposed to. I removed the ONS from the ladder rung and the Totalizer works as expected. I try not to use ONS anyway so I'm not too concerned except that I still would have expected it to work. Is the ONS only good for the one ladder scan or do they work through one scan of the entire program with multiple ladders, Function blocks etc ?

[b_carlton 61]

If the condition before the ONS was FALSE on the previous scan and is TRUE on this scan then the output from the ONS will be a TRUE. Make sure that the address assigned to the ONS is not affected by any other logic in any part of the program. I assume from your description you have an EQU instruction followed by the ONS instruction followed by an OTE instruction. If the EQU has just become true then the ONS will output a TRUE and turn on the OTE location. Take care if the location addressed by the OTE is not used as an output in any part of the logic. On the next scan, whether the EQU is true or not, the output of the ONS will be false and will turn off the location referenced by the OTE instruction. Edited 27 Sep 2012 by b_carlton

[waterboy 7]

you are correct, the rung was EQU ONS OTE next rung was a JSR to the Totalizer Function Block routine Where the OTE bit was used to reset the totalizer Next link again used the OTE to move data to a holding register neither OTE nor ONS were used anywhere else on the PLC. Wierd.

[b_carlton 61]

Without seeing the relevant portions of the program - the rung with the ONS, the rung with the JSR and the 'totalizer' code - it's difficult to give any meaningful advice.

[waterboy 7]

Thats easy enough

[b_carlton 61]

It may be that you ahve simplified the picture of the totalizer but just to check - do you have an EnableIn? If not does the Totalizer work at all?

[waterboy 7]

I have that bit set in the properties of the Totalizer block. Since it will never stop I didn't see a need to bring it out to a bit. I did wonder if that was a good coding practice, but yes it works like this. Edited 27 Sep 2012 by waterboy

[b_carlton 61]

Maybe someone more familiar with function blocks, and the totalizer in particular, will be able to help. Sorry.

[PLCMentor.com 60]

So it works now? Because it looks like to me that you have your totalizer in ProgOper mode instead of ProgProg mode and you are using the ProgResetReq not the OperResetReq. I really dont like all their "flexible" modes that they have so I usually just set my function blocks up with the ProgProgReq set to 1 and the ProgOperReq set to 0. To me that keeps things a little more straight forward.

[waterboy 7]

I agree with your opinion of the flexibillty simply confusing the issue. Too many options. I have never used these where an "operator" can access their params, they are always simple totalizers for a period of time, So it seems to make no difference which mode I use.

[BobLfoot 301]

Does the EQU ONS OTE rung sit in the continuous task or is it in a periodic task. Strange things can happen to ONS in periodic task.

[Conor 4]

Hi guys, With help of this forum I got totalizers working in my PLC's before. I have attached a doc with a working version. Any questions give me a shout working_totalizer_example.doc Conor PS. I know that it says Mid reset, but it is actually resetting at 6:00 am. Edited 28 Sep 2012 by Conor

[waterboy 7]

Continuous task

[waterboy 7]

You are doing something very similar (and you used an ONS in the ladder!). I see you bring out the EnableIn, ProgProgReq and ProgStartReq to an Enable_SF_Tot bit. Is that strictly necessary (if they are never manipulated) or is it permissible to simply set them in the properties dialog and not even make them visible? I certainly need to get a better grasp of the difference between ProgProg and ProgOper

[Conor 4]

Hi Waterboy, I cant remember if it was someone on here or my local Bradley tech rep, but these two (along with the enable) bits have to be made to get it working correctly. I know you may never have to use them, but if it works... Conor Edited 28 Sep 2012 by Conor

[waterboy 7]

I agree they must be set but do they have to bet set with a tag or can they just be set from the totalizer properties dialog like the ProgOper and RunStop are in your example.

[Conor 4]

I am not 100% sure. But as I said, it works fine for me, so I would recommend to do it this way because of this Conor PS, Sorry. I suppose if it works with being set via the properties then maybe do it that. Maybe one of the other guru's can shed light on it. Since I have done it this way first and it works for me I keep doing it this way. I find that I then dont forget if I am doing another one that I need to have them set. Edited 28 Sep 2012 by Conor

[Sergei Troizky 26]

The ONS is a contact-type instruction for local use. If the pulse is being used anywhere else, use the OSR instruction. Edited 28 Sep 2012 by Sergei Troizky

[waterboy 7]

Is that clearly documented somewhere?

[b_carlton 61]

I think he was trying to describe the effect of the ONS was limited to the rung it is on. If you have a rung ending with a ONS then a single OTE this is functionally equivalent to an OSR instruction. The OSR just combines both functions - the ONS and the OTE - into one instruction.

[Sergei Troizky 26]

All I wanted to say is that I see no need to emulate OSR by ONS+OTE, especially when the latter makes problem. Edited 29 Sep 2012 by Sergei Troizky

[waterboy 7]

treading lightly, I'm just trying to understand... By "problem" do you mean that there is a functional difference between an ONS+OTE and an OSR? b_carlton's answer appears to disagree. Or I am just not getting it Please clarify. What exactly do you mean by "local" use ? Do you mean that that ONS is only good for a single ladder scan and not the entire program scan ? That would be a significant difference.

[cbuysse 1]

There is no functional difference between an OSR and an ONS/OTE combination as you're attempting to use it. Both versions will change the value of the tag in the OTE or output of the ONS to 1 when the EQU instruction transitions from false to true. That tag value will remain 1 until that rung is evaluated again. On the next time around the tag value will be changed to 0. That means that tag value will be 1 for everything else the PLC does until it gets back to reevaluating that rung. Just out of curiosity, your documentation states that the reset should occur a minute before midnight, but if I'm interpreting things correctly in the code it appears that it will actually reset a minute before noon. Is that what you had intended or am I reading it incorrectly? My only other thought would be to make sure that the tag you were assigning for the ONS instruction was not used anywhere else in the program. Referencing that tag elsewhere can cause some real headaches.

[waterboy 7]

Yep, just discovered that today myself. I was playing with it last week testing different scenarios and left it like that just to keep you on your toes . But 235900 is the time I need to set that bit and that has been corrected. I also removed the ONS from that rung and placed an OSRI on the totalizer block just to eliminate everything related to the previous ONS. Also added a rung that uses .ProgResetDone to move that value to a test register just to see how that works.