Logix 5000 ONS Across Multiple Programs

[AMarks95]

I have multiple programs defined inside a single continuous task. I have an ONS defined in the very first program that is used throughout multiple other programs.

I'm running into the situation where that ONS is definitely executing, but by the time a program further down the list executes it's back to false so the logic behind it doesn't fire when it's supposed to.

How can I make sure that this ONS works for all the sub programs - or do I need to rewrite some (lots of) code?

 

[Cheeseface]

In the properties for the Task, have you ordered the programs in a way such that the ONS controlling program goes first?

Are you sure the controller-scoped tag is not being obscured by a program-scoped tag in all programs?

And to be clear, you're not executing ONS(thesametag) in multiple programs right? You can't do that.

 

[AMarks95]

In the properties for the Task, have you ordered the programs in a way such that the ONS controlling program goes first?

Are you sure the controller-scoped tag is not being obscured by a program-scoped tag in all programs?

Yes and yes. Clock control is my very first program. I have no local tags anywhere.

 

[drbitboy]

[Update: note that I am assuming there are multiple ONS instructions with identical logic feeding each one, and each ONS instruction with a different storage bit operand not used anywhere else; that may not be the case, but Post #1 is ambiguous about this.]

Write the state of the first ONS in a scan cycle to a single global bit, and use that global bit's state everywhere else (does Logix 5k have OSR?).

Each rung with an ONS is self-contained i.e. it evaluates the logic feeding the input rung of the ONS at the time the program scan gets around to evaluating that rung. So using multiple ONS instructions with identical logic feeding each ONS risks the state of that logic changing throughout the same scan cycle.

This is especially true if memory from physical inputs are in play in that logic feeding the ONS, because Logix 5k does I/O asynchronously with the program scan. I.e. Local:1:I.Data.0 could change state while the continuous task is partway through executing your programs.

 

[drbitboy]

.. I have an ONS defined in the very first program that is used throughout multiple other programs. ...

Is it possible the "multiple other programs" are all calling that "very first program?"

 

[AMarks95]

[Update: note that I am assuming there are multiple ONS instructions with identical logic feeding each one, and each ONS instruction with a different storage bit operand not used anywhere else; that may not be the case, but Post #1 is ambiguous about this.]

Yes, all ONS bits are unique.

Write the state of the first ONS in a scan cycle to a single global bit, and use that global bit's state everywhere else (does Logix 5k have OSR?).

This is exactly what I did. I'm comparing the PLC time to a time setpoint (only down to the minute, so the rung feeding the ONS is true for a full minute) and the ONS fires to a single global bit that is used everywhere else.

Each rung with an ONS is self-contained i.e. it evaluates the logic feeding the input rung of the ONS at the time the program scan gets around to evaluating that rung. So using multiple ONS instructions with identical logic feeding each ONS risks the state of that logic changing throughout the same scan cycle.

There is no logic in front of the subsequent uses of the bit that is toggled by the global ONS.


I've updated my logic to use a 250ms timer instead of a oneshot at the global level. Then, in each sub program I'm reading that global bit and using a oneshot there to trigger a local bit that is used within the program. They'll trigger overnight and we'll see what happens.

 

[drbitboy]

Yes, all ONS bits are unique.



This is exactly what I did. I'm comparing the PLC time to a time setpoint (only down to the minute, so the rung feeding the ONS is true for a full minute) and the ONS fires to a single global bit that is used everywhere else.



There is no logic in front of the subsequent uses of the bit that is toggled by the global ONS.


I've updated my logic to use a 250ms timer instead of a oneshot at the global level. Then, in each sub program I'm reading that global bit and using a oneshot there to trigger a local bit that is used within the program. They'll trigger overnight and we'll see what happens.

That description is still ambiguous to me. It sounds like there are multiple ONS instructions, one global bit, and multiple "uses of bit that is toggle by the global ONS?"


Why use a oneshot to trigger a (program-?)local bit when you already have the global bit? If you do not want to use the global bit directly, then why not just a simple XIC global_oneshot OTE local_oneshot rung?



Can you post some screenshots, both of the logic that writes the global bit, and of the logic that uses the global bit?

 

[robertmee]

Are all the JSRs to the subsequent subroutines unconditional?

 

[AMarks95]

Is it possible the "multiple other programs" are all calling that "very first program?"

No

 

[AMarks95]

That description is still ambiguous to me. It sounds like there are multiple ONS instructions, one global bit, and multiple "uses of bit that is toggle by the global ONS?"


Why use a oneshot to trigger a (program-?)local bit when you already have the global bit? If you do not want to use the global bit directly, then why not just a simple XIC global_oneshot OTE local_oneshot rung?



Can you post some screenshots, both of the logic that writes the global bit, and of the logic that uses the global bit?

What is ambiguous about the description?

In the very first program there is a subroutine called "Clock_Control". This is what that routine does:

1. PLC time is created as a DINT like HHMM, so 8:32 am would be 832.
2. PLC time is compared to a reset setpoint also in the HHMM format.
3. PLC_Time == Time_Setpoint -> ONS -> OTE(Global_New_Day_Bit)


Previously, this global new day bit was used throughout subsequent programs to reset various things at the beginning of the day. That is where my original issue was.

I've now modified it to:


1. PLC time is created as a DINT like HHMM, so 8:32 am would be 832.
2. PLC time is compared to a reset setpoint also in the HHMM format.
3. PLC_Time == Time_Setpoint -> TON(Global_New_Day_TON)
4. XIC(Global_New_Day_TON.TT) -> OTE(Global_New_Day_Bit)

Then, each program now has one extra line at the very top of the program's main routine.
5. XIC(Global_New_Day_Bit) -> ONS -> OTE(Local_New_Day_Bit)

and the local new day bit is now used in each of the subroutines for the program.

Are all the JSRs to the subsequent subroutines unconditional?

Yes.

 

[AMarks95]

What is ambiguous about the description?
3. PLC_Time == Time_Setpoint -> TON(Global_New_Day_TON)

It seems like there's something up with how the time comparison is handled. Time_Setpoint used to be 0. Maybe the clock never actually hits 0 and goes straight to 1, but that doesn't explain why it is working on another PLC (same series) where the Time_Setpoint is 1.

I just manually set the PLC's time to 2358 and watched it roll back to 0 and start the timer... so that's not it. Scan times for the main task are ~0.5ms. This should definitely be working. I'll leave this new code for the weekend and see what it looks like on Monday.

 

[drbitboy]

In the very first program there is a subroutine called "Clock_Control". This is what that routine does:

1. PLC time is created as a DINT like HHMM, so 8:32 am would be 832.
2. PLC time is compared to a reset setpoint also in the HHMM format.
3. PLC_Time == Time_Setpoint -> ONS -> OTE(Global_New_Day_Bit)

So in your original post you were stating that, during the one scan cycle when step 3 above wrote a 1 to Global_New_Day_Bit, that the value of Global_New_Day_bit changed to 0 later in that same scan cycle?

 

[AMarks95]

So in your original post you were stating that, during the one scan cycle when step 3 above wrote a 1 to Global_New_Day_Bit, that the value of Global_New_Day_bit changed to 0 later in that same scan cycle?

I should've been more clear that I didn't know what, exactly, was happening, just that it wasn't executing the rung whose only condition is XIC(Global_New_Day_Bit).

I didn't have a good explanation for for it because it seemed like it should be working, so I took my best guess.

 

[drbitboy]

Are all the JSRs to the subsequent subroutines unconditional?

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).

 

[padees]

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.