Sign in to follow this  
Followers 0
blueheeler

ONS vs OSR

11 posts in this topic

Is there any difference in the function of a ONS vs a OSR statement in Logix500?

Share this post


Link to post
Share on other sites
Yes and no. It depends on the processor your using. See PDF's below for ONS,OSR instruction help. ONS.pdf OSR_1.pdf OSR_2.pdf

Share this post


Link to post
Share on other sites
my distinguished colleague Mickey is absolutely correct ... "it just depends" ... and along those lines, let me point out an error in the first "official" PDF file linked in the post just above ... actually the "prescan" operation does NOT affect the ONS instruction in an MLX-1500 processor ... so what does that mean to us? ... well, in certain (rare) situations it can cause some very surprising results ... here's the basic idea: suppose that we have an input device (for example: a switch or a sensor) and we want the status of that device to "fire" something in our program JUST ONCE when the input first comes on ... aha! ... a perfect place to use an OSR instruction – or an ONS if you're working with something like an MLX1500 system ... so we write the program and everything works PERFECTLY! ... for months it works perfectly ... now then ... let's suppose that the input device happens to be OFF while the machine is running along ... then the power to the building fails ... now while the power is still off, something happens to make that input device come ON ... maybe an operator manually pushes a box down a conveyor line, etc. ... but for whatever reason, that input device is now in the ON position ... quick question: what's going to happen when the system is eventually powered back up again? ... specifically, do we want that new ON condition to "fire" – or do we NOT want it to "fire"? ... now in SOME systems that can be a VERY important question ... for one specific example: maybe we're putting "serial numbered" barcode labels onto custom-designed parts ... the point is that IF (that’s a big IF) you really DO care about whether the system "fires" or not, then you really need to understand how the processor's prescan operation DOES – or does NOT – affect the ONS and the OSR instructions ... NOTE: you really don't need a power failure to cause this situation ... just taking the processor from the Run Mode to the Program Mode and back to the Run Mode will have the same effect ... so ... the first figure below shows that an OSR instruction (running in an SLC-5/04 processor) WILL allow the system to "fire" under the test conditions that I've detailed above ... that's because the prescan operation totally ignores the OSR instruction ... but ... the second figure below shows that an ONS instruction (running in a PLC-5/20 processor) will NOT allow the system to "fire" under the very same test conditions ... that's because the prescan operation DOES "set" the ONS instruction's bit to a ONE status – to prevent "false" triggering ... but notice that the bottom figure is for a PLC-5 (using RSLogix5) and not for something using RSLogix500 – as specified in the original poster's question ... unfortunately my MLX-1500 system is at home today – but I can bring it in tomorrow if anyone wants to see a screen shot ... but the last time I tested one out, the ONS in the MLX-1500 worked exactly the same way as the OSR in an SLC-5/04 ... specifically, the MLX-1500's ONS instruction DID allow the system to "fire" under the test conditions I've outlined above ... nailing it down: the ONS in an MLX-1500 system works like the OSR instruction in the SLC-5/04 ... specifically, it does NOT work like the ONS in the PLC-5 – regardless of what the official "book" says ... more specifically, during prescan, the bit address is NOT "set to inhibit false triggering when the program scan begins" ... the book is wrong about that ... the prosecution rests, your honor ... now going one step further ... let's go back to that same "quick question" that I asked earlier ... under the test conditions that I've been using, when the system is eventually powered back up again, do we want the ON condition to "fire" – or do we NOT want it to "fire"? ... (consider that the input really IS turned ON when the machine powers back up – so presumably there's a real-live physical part actually present at the switch that really MIGHT need to be counted, etc.) ... so ... in SOME cases we DO want to "fire" ... but in some cases we do NOT want to "fire" ... and honestly, in some (most?) cases we don't really care one way or the other ... the point is that IF (another big IF) this type of thing is important in the system that you're working with, then you really need to understand what effect (if any) the "prescan" operation has on these "one shot" types of instructions ... and (here's the tricky part) unfortunately you can't simply rely on what it says in the official "books" ... final thought: programming the machinery to work correctly is ONE thing ... making sure that it works correctly in various "power-up" and "power-down" situations can be a horse of a completely different color ... the types of weird scenarios that I've covered here are generally passed off as the result of "power surges" and things like that ... the fact is that many programmers don’t really understand (or even think about) what's going to happen when (sooner or later) a PLC-controlled system runs into one of these inevitable "weird" situations ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
One example of what Ron is talking about is when you want to detect the falling edge of an input, for example, you want to know when an input is first on, then off and you want to respond to the input going off. If you program XIO I:1/0 OSR B3/0 OTE B3/1 on a SLC500. then B3/1 will pulse whenever power is cycled or whenever you switch from program to run, yet the input device did not actually change from on to off. This could be undesirable. I had that issue with a vacuum furnace Micrologix 1000 PLC program where events outputs from the temperature controller were triggering actions in the PLC program and falling edge detection was necessary.

Share this post


Link to post
Share on other sites
Well said RON. I fought for a month one night with a ControlLogix using Indirect addressing which would consistently fault sometimes while running, and sometimes during prescan. Finally boiled down to a bad offset value in the index register.

Share this post


Link to post
Share on other sites
Let me see if I have this straight. AB has a processor with a 1-shot statement named OSR. And they have another processor with a 1-shot statement that works the same as the statement in the other processor that they named ONS. This processor also has a 1-shot statement that works different from the OSR in the other processor and they named it OSR.

Share this post


Link to post
Share on other sites
Yup Edited by Mickey

Share this post


Link to post
Share on other sites
All good reasons to dump AB and use OMRON. No stupid bits to manage for any oneshot commands.

Share this post


Link to post
Share on other sites
so how deep does this rabbit hole go? ... well, as confusing as it may seem, so far we've just been discussing the little "in-line" type instructions – the pieces that go into the left (condition side) of the rungs ... let's nail these down first ... ------------------------------------ for the SLC-500 and MLX-1000 platforms ... these use the OSR instruction ... prescan does NOT affect these ... ------------------------------------ for the MLX-1500, etc. platforms ... these use the ONS instruction ... prescan does NOT affect these ... (specifically, the book is wrong) ... ------------------------------------ for the PLC-5 platforms ... these use the ONS instruction ... prescan DOES affect these ... ------------------------------------ and now let's move into the "one-shot" type instructions that show up on the right (output) side of the rung ... ------------------------------------ for the SLC-500 and MLX-1000 platforms ... these don’t have any "output" type one-shot instructions to worry about ... (well, that was easy) ... ------------------------------------ for the MLX-1500, etc. platforms ... these have the OSR instruction available – but look at the last two rungs in the following figure and notice how different the setup for this OSR is from the OSR used in the SLC-500 and MLX-1000 platforms ... and to get back to the main point of my earlier post, the MLX-1500 operation DOES affect the OSR instruction ... (for comparison purposes, the ONS on the first rung of the figure demonstrates the operation of the ONS for the MLX-1500 platform) ... ------------------------------------ for the PLC-5 (enhanced) platform ... the figure below shows the setup for the PLC-5's OSR instruction ... and here the PLC-5's prescan operation DOES affect the OSR – but – the description in the book is partially incorrect ... ------------------------------------ finally (at least for now) a quick summary: (1) when it comes to Allen-Bradley's "one-shot" type instructions, there is a LOT of variety when it comes to what's available between the various platforms ... (2) even "one-shot" type instructions which have identical names may require completely different rung constructions between the various platforms ... (3) "one-shot" instructions are NOT all affected in the same way by the processor's prescan operation ... if you're not aware of the programming differences, then surprising results may occur whenever the system is "power cycled" or when it otherwise has a "go-to-run" event ... it's easy to blame these "electronic hairballs" on something like a "power surge" – but in quite a few cases the intermittently incorrect results can be tracked down to the construction of the program ... (4) the official books are NOT always 100% reliable ... I heartily recommend that you carry out your own experiments on a "spare" system – and that your tests include various "go-to-run" conditions ... ------------------------------------ and to BITS N BYTES who said: you're probably correct – but in my line of work, I don't get to choose my own battles ... specifically, I've got to teach what my customers demand ... to tell the truth, I get a LOT of demand for Allen-Bradley skills – and (at least so far) no demand at all for Omron ... that probably goes back to your point, Omron is so much easier to work with that no one who uses them needs the type of training I provide ... anyway, you've got me curious ... would you be willing to post a screen shot (in this thread, please) with a quick demonstration of how an Omron would take care of a simple "one-shot" situation? ... I for one would like to see the difference – and I'd PARTICULARLY like to know how the system would respond under those "go-to-run" test conditions that I mentioned earlier ... I'll understand if you're tied up – but I'm always eager to learn something new ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
This doesn't explain actually how Omron handles the one-shots, but it does show the variety of options available. http://forums.mrplc.com/index.php?showtopic=11451&hl= I would have to delve into the manuals further to check the exact operation, but I would be reasonably confident that they all operate the same in every platform... and that they do not trigger if they are not required to on 'pre-scan'.

Share this post


Link to post
Share on other sites
Hi Ron, here are details from OMRON instructions set showing differentiated instructions. Note that these apply to the CS/CJ series processors. What is really neat about his feature is the ability to change the differentiated operation of input and/or outputs instructions when online without having to be concerned about adding/managing a control bit, as in AB. OMRON_Differentiated_Instructions.pdf

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0