Logix 5000 ONS Across Multiple Programs

[drbitboy]

I hate to be the bearer of bad news, but an ONS only fires once for the remainder of the scan,

... and the beginning of the next scan cycle, or more generally until the ONS is evaluated again, which could be an indeterminate number of scans later.

 

[padees]

It needs a false to true transition to fire again.


Drop an ONS on a rung. Use that to fire something on a higher rung in the scan, and see if that works.

 

[robertmee]

... and the beginning of the next scan cycle, or more generally until the ONS is evaluated again, which could be an indeterminate number of scans later.

Yep....Logic calls a JSR once and only once. Inside called routine ONS with an OTE. That ONS is true for more than one scan.

I rarely use one shots that need to persist to other routines or tasks. Considering most tasks are periodic, it's a recipe for unexpected results.

 

[chelton]

I rarely use one shots that need to persist to other routines or tasks. Considering most tasks are periodic, it's a recipe for unexpected results.

Good practice would be to have periodic tasks, however i think you'll find most programs reside in a continuous task. Faster processor speeds and huge memory, programs are very forgiving now.

 

[robertmee]

Good practice would be to have periodic tasks, however i think you'll find most programs reside in a continuous task. Faster processor speeds and huge memory, programs are very forgiving now.

Well I can't account for bad programming practices

 

[Ron Beaufort]

DISCLAIMER: I haven't been following this thread closely – basically I have just skimmed over it now and then ...

even so, it appears that some of the folks posting here are suffering from some common misconceptions on how the ONS instruction works in RSLogix5000 ... maybe I can help clear some of these up ... (NOTE: the example I'm posting here is being run on the Version 16 Emulator which is the only thing I have available for testing right now ...)

the MainRoutine shown in the screen shot below is chugging right along – as proven by the rapidly increasing value stored in COUNT_MAIN_ROUTINE_SCANS ...

Rung 1 in the MainRoutine is being executed as TRUE – and is thus activating ("calling") Routine_A once for each time that the processor scans the MainRoutine ...

many programmers would expect the value stored in COUNT_ROUTINE_A_SCANS to increase – as the ADD instruction is expected to increment that value for each scan of the rung ...

but note that the value stored in COUNT_ROUTINE_A_SCANS does NOT change – as shown in the circled Destination of the ADD instruction ...

POINT OF THE POST: here's where some common misconceptions come into play ...

(1) the ONS instruction is highlighted "GREEN ON THE SCREEN" – that should mean that the ONS is currently TRUE – doesn't it? ... NO ... that is a common misconception ...

in simplest terms, the "GREEN ON THE SCREEN" highlight does NOT always signify that an instruction/condition is TRUE - or that it is "ACTIVE" ...

(2) as shown in the circled Value of the ToolTip, the ONS instruction's tag (ONS_FOR_ROUTINE_A) contains the value of 1 – the value of 1 means the same thing as TRUE - doesn't it? ... NO ... that is another common misconception ...

SUMMING UP FOR NOW: the ONS instruction in Rockwell products does NOT always do what we THINK it should do – nor does it always do what we EXPECT it to do ... and just for completeness let me say that the ONS and OSR instructions in other Rockwell platforms (RSLogix500/SLC/MicroLogix, etc.) have some DIFFERENT quirks when compared to the ControlLogix/CompactLogix platform being discussed here ...

FINALLY (and IMPORTANTLY): this post isn't intended to help "solve the Original Poster's problem ... I'm just trying to get everyone on the same "apples to apples" or "oranges to oranges" page ... hopefully that would help move the discussion along ... even more helpful would be posting the actual programming code ...

peace to all ...
.

 

[padees]

DISCLAIMER: I haven't been following this thread closely – basically I have just skimmed over it now and then ...

even so, it appears that some of the folks posting here are suffering from some common misconceptions on how the ONS instruction works in RSLogix5000 ... maybe I can help clear some of these up ... (NOTE: the example I'm posting here is being run on the Version 16 Emulator which is the only thing I have available for testing right now ...)

the MainRoutine shown in the screen shot below is chugging right along – as proven by the rapidly increasing value stored in COUNT_MAIN_ROUTINE_SCANS ...

Rung 1 in the MainRoutine is being executed as TRUE – and is thus activating ("calling") Routine_A once for each time that the processor scans the MainRoutine ...

many programmers would expect the value stored in COUNT_ROUTINE_A_SCANS to increase – as the ADD instruction is expected to increment that value for each scan of the rung ...

but note that the value stored in COUNT_ROUTINE_A_SCANS does NOT change – as shown in the circled Destination of the ADD instruction ...

POINT OF THE POST: here's where some common misconceptions come into play ...

(1) the ONS instruction is highlighted "GREEN ON THE SCREEN" – that should mean that the ONS is currently TRUE – doesn't it? ... NO ... that is a common misconception ...

in simplest terms, the "GREEN ON THE SCREEN" highlight does NOT always signify that an instruction/condition is TRUE - or that it is "ACTIVE" ...

(2) as shown in the circled Value of the ToolTip, the ONS instruction's tag (ONS_FOR_ROUTINE_A) contains the value of 1 – the value of 1 means the same thing as TRUE - doesn't it? ... NO ... that is another common misconception ...

SUMMING UP FOR NOW: the ONS instruction in Rockwell products does NOT always do what we THINK it should do – nor does it always do what we EXPECT it to do ... and just for completeness let me say that the ONS and OSR instructions in other Rockwell platforms (RSLogix500/SLC/MicroLogix, etc.) have some DIFFERENT quirks when compared to the ControlLogix/CompactLogix platform being discussed here ...

FINALLY (and IMPORTANTLY): this post isn't intended to help "solve the Original Poster's problem ... I'm just trying to get everyone on the same "apples to apples" or "oranges to oranges" page ... hopefully that would help move the discussion along ... even more helpful would be posting the actual programming code ...

peace to all ...
.

It does exactly what I expect it to do, and it works well in proper situations. I don't think there is a variance between RS500 and S5K on how this instruction works, but there could be.


Good example info!

 

[AMarks95]

Given the behavior, I suspect the answer to @robertmee's query is the most likely explanation:

• one or more of the programs is run conditionally on any give scan cycle,
• so if it did not run on the scan cycle when the global one-shot bit's value was 1
  • (i.e. the first scan cycle when the time value was 832 after being 831 on the previous scan cycle),
• then it will not see the value of 1 on any subsequent scan cycles when it does run during that same minute (832).

Nope, no conditional JSRs

 

[AMarks95]

I hate to be the bearer of bad news, but an ONS only fires once for the remainder of the scan, until what is firing it goes false. You can hold an ONS true until you retired, but it will only fire once.

Proper placement and use is key with this instruction.

Yes, I am aware how the ONS works. I wanted to use a single ONS at the global level in the first program to reset a bunch of stuff at the beginning of the day in all of the subsequent programs. I have found that it is not working as expected, hence the confusion and the post.

 

[robertmee]

Yes, I am aware how the ONS works. I wanted to use a single ONS at the global level in the first program to reset a bunch of stuff at the beginning of the day in all of the subsequent programs. I have found that it is not working as expected, hence the confusion and the post.

Millions of installs with no unexpected ONS operations reported, so fairly certain something unique to your code.

How many Tasks? If more than one, then you have some that are periodic that execute asynchronous to the continuous task. You can't use a global ONS in that case.

I'm curious about this one...if not proprietary send me a copy of the original code to test. You can PM for an email.

 

[padees]

I think "millions" of installs is a fair stretch. That's over 1/2 million total broken down per minute installs over the course of a year.


I think it might seem like forever, but break it down to seconds.


No one knows your thru put.

 

[drbitboy]

... I have found that it is not working as expected, ...

"It" being the your code and not the PLC or the one-shot.

The PLC program cares not a whit what you want or expect it to do, but it will mercilessly and inexorably do exactly what you tell it to do.

Stated another way:

The only thing worse than the PLC not doing what you wanted it to do is when it does exactly what you told it to do.

If you post your code, then you may find out how you should have expected it to work.

 

[drbitboy]

There are at least two other, both very unlikely, but possible explanations:

• bug in the compiler that builds the PLC program for download
• bad or corrupted memory (perhaps this PLC is in outer space?)

 

[drbitboy]

Nope, no conditional JSRs

Are there any early RET (return) instruction in the JSR-called routines?

 

[chelton]

Are there any early RET (return) instruction in the JSR-called routines?

Or have you checked to that the routine isn't being called again from somewhere else in the program? If the routine was called more than once what your seeing would make sense.