Logix 5000 ONS Across Multiple Programs

[drbitboy]

re-investigated this again. If I change the reset time to non-0 I can verify that the ONS rung does execute and the totals get reset.

So, for some reason it doesn't work when it's 0? But it does on the other one?

New_Day_ONS is a different bit than NewDay_ONS.

 

[AMarks95]

I am curious why OP felt the need to reinvent the OSR.

As the good doctor notes, while you can use the address of an ONS as an XIC, this is not usually done because this is functionally equivalent to treating it as on OTE, ie you lose the 'one-shot' aspect which was why you used it in the first place.

That's not what's being done. ONS bits are unique and only used on the ONS instruction, nowhere else and with no other instruction.

 

[drbitboy]

That's not what's being done.

Um, based on the pictures and the code you supplied, that is exactly what is being done.

 

[AMarks95]

New_Day_ONS is a different bit than NewDay_ONS.

Um, based on the pictures and the code you supplied, that is exactly what is being done.

https://imgur.com/3mLydMU

THEY ARE ENTIRELY DIFFERENT PROGRAMS.

 

[AMarks95]

New_Day_ONS is a different bit than NewDay_ONS.

Yes, in the main for the RAS program:

NewDay_ONS is the global in this program.
New_Day_ONS is local to each subprogram.

 

[OkiePC]

Why not just OTE the bit when you want the actions to take place throughout the other programs based on the clock minute, and use a local one-shot storage address in each of them to drive the required actions.

Then the bit will turn back off a full minute later (plenty early enough to cause a transition the following day, plenty long enough to follow along and troubleshoot.)

EDIT: I missed a whole page of posts and now see that this is sort of what DrBitboy did, only I see no need for the timer.

 

[drbitboy]

re-investigated this again. If I change the reset time to non-0 I can verify that the ONS rung does execute and the totals get reset.

...



So, for some reason it doesn't work when it's 0? But it does on the other one?

See here.

​

 

[AMarks95]

See here.

View attachment 67907​

Reset time is referring to the New_Day_Reset_Time_DINT tag in the Clock_Control routine. Not the PRE of the TON.

 

[AMarks95]

Why not just OTE the bit when you want the actions to take place throughout the other programs based on the clock minute, and use a local one-shot storage address in each of them to drive the required actions.

Then the bit will turn back off a full minute later (plenty early enough to cause a transition the following day, plenty long enough to follow along and troubleshoot.)

EDIT: I missed a whole page of posts and now see that this is sort of what DrBitboy did, only I see no need for the timer.

I see no need for the timer either, but it wasn't working with a ONS straight to the OTE so I had to try something else.

 

[OkiePC]

I see no need for the timer either, but it wasn't working with a ONS straight to the OTE so I had to try something else.

Put the timer compare straight to the controller scope OTE bit. It will stay true for one minute. XIC this bit and then use a ONS with a unique storage bit in each of the programs that need to take action. Then you don't have to try to figure out if call order or time-slicing is breaking your global one-shot, because there won't be one. All the one shots will be unique to each program and the scope won't matter.

 

[robertmee]

I see no need for the timer either, but it wasn't working with a ONS straight to the OTE so I had to try something else.

If you want to try something else:

XIC condition OTL Reset_Bit

Your logic to do something on XIC Reset_Bit

On the last rung of the last routine
XIC Reset_Bit OTU Reset_Bit

I hate using timers to overcome some inherent race condition.

 

[drbitboy]

add

XIC(Global_New_Day_ONS)ADD(someDINT,1,someDINT)

​

to every routine to determine where that one-shot is being detected and where it is not.

If the identical program is running in two places (PLCs?) with different results, then find out what is different between those two places.

 

[AMarks95]

Put the timer compare straight to the controller scope OTE bit. It will stay true for one minute. XIC this bit and then use a ONS with a unique storage bit in each of the programs that need to take action. Then you don't have to try to figure out if call order or time-slicing is breaking your global one-shot, because there won't be one. All the one shots will be unique to each program and the scope won't matter.

I ended up doing this. It's basically the same, but avoids any race conditions that might exist that are internal to the controller. Definitely more robust and doesn't require the use of other timers and such. I think this will end up working. Not sure what the original issue was, but I've tested by setting the PLC clock to 2359 and waiting a minute to watch it roll over to 0 and verify that it does initiate the reset.

 

[OldChemEng]

A unique tag for a ONS instruction is used only ONCE in an program period. It is also a bad idea to use a ONS tag anywhere else in the program for XIC, XIO, etc insructions. An OTE tag can be used on an OTE instruction ONE TIME. An OTL tag can be used on multiple OTL instructions. These rules apply for PLC-2, PLC-5, SLC-500,CompactLogix & ControLogix programs. If you violate these rules, you PLC will exhibit "EMO" (Errotic Machine Operation).

 

[AMarks95]

I'm at a loss here. The code is definitely working, I just don't know why it doesn't work when I'm not watching.

Whether I change the reset time setpoint or use SSV to set the system clock to just before midnight I can wait 1-2 minutes while watching the PLC run and see the EQU and OTE go true and even watch the values MOV 4->5, 3->4, 2->3, 1->2, 0->1. It just doesn't work if I go offline (leaving it in run mode) and leave it overnight to do it's thing. But the exact same code does work on the other PLC when I'm not watching.