rslogix5000 [ONS]

Well strange things happening with a [ONS] instruction in Rslogix5000. I used this in a routine to mov a value once into a register when I was online it worked once then the bit stayed on if i toggled the bit then the rung would work again but then latch on. I put a timer in front of this it was the same. I changed the [ons] to a [OSR] and it works. Can someone explain.

Orther thing a normally open connected to an output and it was also staying on. When I am online and I save the program does it remember the states so that when I download again it is all toggled and how do I clear these states to there normal state as programmed very confusing especially when commisioning.

This is a post from last year that may answer your querry

http://www.plctalk.net/qanda/showthread.php?t=41154

Thanks mate a good read. I know the [OSR] & [OSF] work the best and is more predictable so I am going to stick to that.I saw the [ONS]online behaving strange. I need the state to be predictable.

I am still puzzled about the states of switches after i downloaded and online with the rung true the output not coming on. Toggle fixed it but then it had a mind of its own again.
Under edit what is "Clear all instruction defaults" ?
And when you are online and save the program a warning that to upload tag values appears I normally say yes?
Go away do some program alterations and then download again????

Greetings rigicon ...

I saw the [ONS]online behaving strange. I need the state to be predictable.

Click to expand...

actually, the ONS is "predictable" – as long as you do things its own way ...

judging from what you've posted so far, my guess is that you're somewhat confused with how the processor's "prescan" operation affects things each time that the system first enters the "go to run" state ... trust me, you are NOT alone in that confusion ...

let's take a look (for better or for worse) at the information available from the RSLogix5000 menu's Help / Instruction Help area for the ONS instruction ... let's specifically concentrate on the part about "prescan" ...

Prescan: The storage bit is set to prevent an invalid trigger during the first scan. The rung condition out is set to false.

Click to expand...

the most confusing issue here is that the author used the same word ("set") to mean two different things ... first let's slightly abridge that same statement – eliminating that troublesome word "set" completely ...

Prescan: The storage bit is WRITTEN TO A ONE STATUS to prevent an invalid trigger during the first scan. The rung condition OF THE ONS WILL BE EVALUATED AS FALSE.

that's a little better – now here's another swing at the same information again – this time in a slightly less ambiguous style ...

each time the system first goes into the Run Mode, a "prescan" operation takes place ... during this prescan operation, the system automatically writes a status of ONE into the ONS storage bit ... this has the effect of telling the ONS that it has already been "fired" ... so – even if the rung condition leading into the ONS happens to be TRUE when the rung is first scanned (note that's AFTER the prescan), then the ONS will NOT "fire" ... specifically, the rung condition leading into the ONS must now be scanned as FALSE (at least once) and then subsequently be scanned as TRUE before the ONS will "fire" normally ...

the best way to get a handle on how this works is to use a SPARE system and set up a couple of test rungs ... then experiment by going in and out of the Run mode until you understand the patterns ...

I've attached a suggested "test" program below ... NOTE: the figure below is NOT intended to be a "fix" for your problem ... in particular, the first rung is NOT normally used in most programs ... but ... if you understand how the S:FS (Status: First Scan) bit is being used to "unlatch" (WRITE A ZERO) into the ONS status bit – AFTER the prescan – but BEFORE the processor first scans the ONS, then you'll have come a long way toward understanding exactly what goes on under the hood of the ONS instruction ...

now then ... if you have any further questions about this subject, please post the program that's confusing you, and we'll try our best to straighten everything out ...

as for your other questions:

Under edit what is "Clear all instruction defaults" ?

Click to expand...

this feature is mostly for "power user" programming people ... suppose that you use a certain type of instruction quite often ... (let's use a TON timer as a simple example) ... suppose that most of the TON timers that you use have a certain Preset value ... (let's say the Preset is usually 1000 as a simple example) ... so ... enter your first TON – and the 1000 preset – and then highlight the TON with your cursor ... now go to Edit / Save Instruction Defaults and confirm the operation ...

now whenever you enter a TON, the 1000 Preset value will automatically be entered for you ... (in other words, you have "saved" the "default" settings for any TON timers that you subsequently enter into your program ...

now suppose that you're finished with the 1000 Preset TON timers ... you could highlight a TON – and then go to Edit / Clear Instruction Defaults and confirm the operation ... this releases the defaults for the TON ...

and finally ... suppose that you have already set up other instructions besides TONs with their own defaults ... if you want to clear the slate completely, go to Edit / Clear All Instruction Defaults and confirm the operation ... this SHOULD put everything back to square one ...

And when you are online and save the program a warning that to upload tag values appears I normally say yes?

Click to expand...

I recommend that my students always say "yes" to this one ... (and frankly I think that the word "Warning" is a little too strong for what's going on here) ... the software is basically just asking for your permission to extract all of the data values stored in your tags – and to then save those values along with the rest of the program ...

now there ARE some instances where you MIGHT want to say "no" – but that would be the subject for another post ...

hope this helps ...

Thank you very much Ron - most helpful. i was using the [ONS] inside a routine and when I called the routine it was behaving as it should ie first run condition. Then still calling the routine it would behave correctly. Silly me I should of realised. The fix was of course either always run the routine or change the instruction preceding the ONS or like I did use a OSR. I have other ONS in the main program and I have no problem. Good explaination and I understand the ONS.

The other answers are brilliant too - Thanks.

rigicon said:

Thank you very much Ron - most helpful. i was using the [ONS] inside a routine and when I called the routine it was behaving as it should ie first run condition. Then still calling the routine it would behave correctly. Silly me I should of realised. The fix was of course either always run the routine or change the instruction preceding the ONS or like I did use a OSR. I have other ONS in the main program and I have no problem. Good explaination and I understand the ONS.

The other answers are brilliant too - Thanks.

Click to expand...

I ran into that same problem once. A programmer called a JSR on a one-shot and inside the JSR used a one-shot also to do some logic. Problem was on first scan, the JSR is not run because of the logic, but the one-shot state is set to a ONE inside the non-called JSR. Next time the JSR is called, if the logic ahead of the preset one-shot state inside the JSR happens to be true, then it doesn't execute.

I have one problem in rslogix5000. regarding OSF.
My question is why in Add On OSF not working.
Does it works in Add on ???

robertmee said:

I ran into that same problem once. A programmer called a JSR on a one-shot and inside the JSR used a one-shot also to do some logic. Problem was on first scan, the JSR is not run because of the logic, but the one-shot state is set to a ONE inside the non-called JSR. Next time the JSR is called, if the logic ahead of the preset one-shot state inside the JSR happens to be true, then it doesn't execute.

Click to expand...

That's generally bad programming practice. Some instructions (especially ASCII string instructions) can take more than one scan to complete. I generally don't like to make JSRs conditional anyway, but if someone comes along and puts a bunch of ASCII manipulation in that sub, they could end up with a dent in their head from banging it on the desk, trying to figure out why their strings are incomplete.

Phase Manager

Phase manager has issues with ONS as well. Or at least version 19 does. I've had to create some old school one shots due to it. Haven't checked recent revs to see if its fixed or been addressed yet.

Good info. Did not know this. It explains some problems I've had.