another subroutine question

Skidood · Feb 14, 2019

When the subroutine is no longer being called, and then called up again, what happens with one-shots in that subroutine? I have some rungs in the subroutine where the first instruction on the rung is a ONS. Will the ONS have reset itself so it works properly when the SBR is re-activated or does it remain "shot" and will never "one-shot" again until the PLC stops and restarts scanning. I have also used an OSR instruction in other areas of the program but the ONS is faster to throw into the project in RSLogix.
I am hoping against all hope that the ONS will reset.

Geoff White · Feb 14, 2019

The logic is not evaluated when it is not called. Coils will stay in their last state. One shots will not see transitions until scanning again. Restarting the PLC won't help if the storage bit is retentive.

thingstodo · Feb 14, 2019

Skidood said:
When the subroutine is no longer being called, and then called up again, what happens with one-shots in that subroutine? I have some rungs in the subroutine where the first instruction on the rung is a ONS. Will the ONS have reset itself so it works properly when the SBR is re-activated or does it remain "shot" and will never "one-shot" again until the PLC stops and restarts scanning. I have also used an OSR instruction in other areas of the program but the ONS is faster to throw into the project in RSLogix.
I am hoping against all hope that the ONS will reset.

Not sure I understand, but I think you are talking about the ONS instruction for a PLC5 or a ControlLogix. It has a storage bit, that is a boolean 1 when the one-shot has 'fired' and 0 when the one-shot is 'reset'

For the one-shot to reset itself, the conditions that preceed it on the rung have to execute when they are false. This is considered the 'normal' method of resetting the one-shot. If you can find a way to call the subroutine while the condition that fires the one-shot is false, that is the least confusing way of using the subroutine.

You can 'manually' reset the ons by clearing the storage bit. This is not good programming practice ... sort of like using GOTO in Basic. But it does work. An OTU instruction can be used and will not affect other logic. But it is a duplicate destructive instruction aimed at the same address, so your programming software should (correctly) warn you about it.

Using the same ONS storage bit on a different rung, and having it execute with the conditions that preceed it on the rung evaluate to false, will also reset the One-shot. This is also a duplicate destructive instruction aimed at the same address, so your programming software should (correctly) warn you about it. BUT this method will CONFUSE the heck out of anyone who looks at the code. Ask me how I know! This is horrible programming practice. Kind of like using self-modifying code in assembly. I list it because it does work. But please don't do this.

Whatever method you use to reset the one-shot - PLEASE DOCUMENT WHY you are doing what you are doing. Extra calls to subroutines that don't make sense are hard to figure out. OTUs on one-shot bits are harder to figure out. And multiple uses of ONS storage bits are the worst of the lot. Be kind to yourself the next time you review the logic, and document it well.

Skidood · Feb 14, 2019

I'm using a MicroLogix 1400 PLC and RSLogix 500 software.
I can choose between using an ONS and an OSR. With the OSR you have to create/assign a storage bit and an output bit. The one shots are activating instructions like MOV and ADD, CPT, COP and CPW.
I am using mostly ONS which don't require you to create/assign any bits.
Also, the key thing here is that the ONS is the first instruction on the rung, since I was assuming that as soon as the subroutine is called, that rung in that subroutine will be seen as true and the one shot will activate the output on the rung on the first scan of the sub. And activate it ONLY for one scan.
So i dont have any input conditions that precede the ONS.

thingstodo said:
Not sure I understand, but I think you are talking about the ONS instruction for a PLC5 or a ControlLogix. It has a storage bit, that is a boolean 1 when the one-shot has 'fired' and 0 when the one-shot is 'reset'

For the one-shot to reset itself, the conditions that preceed it on the rung have to execute when they are false. This is considered the 'normal' method of resetting the one-shot. If you can find a way to call the subroutine while the condition that fires the one-shot is false, that is the least confusing way of using the subroutine.

You can 'manually' reset the ons by clearing the storage bit. This is not good programming practice ... sort of like using GOTO in Basic. But it does work. An OTU instruction can be used and will not affect other logic. But it is a duplicate destructive instruction aimed at the same address, so your programming software should (correctly) warn you about it.

Using the same ONS storage bit on a different rung, and having it execute with the conditions that preceed it on the rung evaluate to false, will also reset the One-shot. This is also a duplicate destructive instruction aimed at the same address, so your programming software should (correctly) warn you about it. BUT this method will CONFUSE the heck out of anyone who looks at the code. Ask me how I know! This is horrible programming practice. Kind of like using self-modifying code in assembly. I list it because it does work. But please don't do this.

Whatever method you use to reset the one-shot - PLEASE DOCUMENT WHY you are doing what you are doing. Extra calls to subroutines that don't make sense are hard to figure out. OTUs on one-shot bits are harder to figure out. And multiple uses of ONS storage bits are the worst of the lot. Be kind to yourself the next time you review the logic, and document it well.

Skidood · Feb 14, 2019

My one-shots are the first instruction on the rung. Im starting to think that they won't get reset simply because the subroutine is no longer being called.

Geoff White said:
The logic is not evaluated when it is not called. Coils will stay in their last state. One shots will not see transitions until scanning again. Restarting the PLC won't help if the storage bit is retentive.

daba · Feb 15, 2019

Skidood said:
I'm using a MicroLogix 1400 PLC and RSLogix 500 software.
I can choose between using an ONS and an OSR. With the OSR you have to create/assign a storage bit and an output bit. The one shots are activating instructions like MOV and ADD, CPT, COP and CPW.
I am using mostly ONS which don't require you to create/assign any bits.
Also, the key thing here is that the ONS is the first instruction on the rung, since I was assuming that as soon as the subroutine is called, that rung in that subroutine will be seen as true and the one shot will activate the output on the rung on the first scan of the sub. And activate it ONLY for one scan.
So i dont have any input conditions that precede the ONS.

The PLC will NOT reset any one-shot bits itself, your logic determines when the ONS bits get reset, nothing else.

An ONS at the beginning of the rung will mean that the following logic on that rung will only ever get evaluated as true ONCE, and ONCE ONLY, forever, even if the PLC is restarted.

You can, of course, reset the ONS manually as suggested, by OTUing the bit somewhere, and then the rungs with the ONS as the first instruction will once again evaluate as TRUE, but once only.

I cannot see any situation where I would put an ONS as the first instruction on a rung, its purpose is to post-condition your logic so that an event is only seen once per false-to-true transition.

An example, suppose you had to ADD to a number when an input is ON, the input could be ON for longer than one program scan, so your ADD instruction would ADD multiple times. You would follow up the input bit with a ONS, so that the ADD will only be true at each false-to-true transition of the input.

daba · Feb 15, 2019

Skidood said:
My one-shots are the first instruction on the rung. Im starting to think that they won't get reset simply because the subroutine is no longer being called.

You are starting to think correctly, why would the PLC reset bits in your application, it doesn't have any intelligence, and just follows orders.

Skidood · Feb 15, 2019

Gotcha.

Also, brain is mis-firing....I mis-spoke earlier when I said you dont need to assign a bit for a ONS...you do. And with an OSR, it's 2, not 1. And yes I am entering lots of comments on many rungs as explanatory info. Mostly for myself since down the road I may have to solve a problem and will probably be completely baffled when looking at the logic..lol....I'm getting to be that age.....

proof · Feb 15, 2019

Skidood said:
My one-shots are the first instruction on the rung. Im starting to think that they won't get reset simply because the subroutine is no longer being called.

Why would you think anything else?

Why would you want anything else?

If the logic is not executed, it doesn't do (change) anything. It does not matter why it was not executed. I certainly wouldn't want the PLC to assume that since I hadn't called a subroutine for (10 ms, 10 seconds, 1 hour, etc), that it should toggle bits on or off. If the bits should change, the logic should change them! If you are starting to use a routine and need to initialize some flags, you must write specific logic for initialization, with the exception of the pre-scan rules.

Skidood · Feb 15, 2019

proof said:
Why would you think anything else?

Why would you want anything else?

If the logic is not executed, it doesn't do (change) anything. It does not matter why it was not executed. I certainly wouldn't want the PLC to assume that since I hadn't called a subroutine for (10 ms, 10 seconds, 1 hour, etc), that it should toggle bits on or off. If the bits should change, the logic should change them! If you are starting to use a routine and need to initialize some flags, you must write specific logic for initialization, with the exception of the pre-scan rules.

Because I'm a dumb newbie who assumed that if a subroutine is not being called, all the logic in it would basically just go false. That's why! :nodi:

bernie_carlton · Feb 15, 2019

We were all 'dumb newbies' at the start. Don't let us old codgers who may have forgotten that get you down. But listen to the advice. After a while you will be chuckling at the newest crop of newbies.

OkiePC · Feb 15, 2019

In general, try to avoid conditional subroutines. They have their place. For instance, I often have a subroutine called "1st Scan" in which I do things I always want done on a transition to run mode. Or, I might have a conditional routine that does some repetitive calculation that I want to "submerge" from view and normal scanning.

But for normal machinery control, scan all of it all the time, even if it means having a contact or compare on every rung to determine whether or not it executes. It is easy to misunderstand the fact that many instructions do something when scanned false that is different than when not scanned at all.

The OTE is one of those that it's important to understand that when scanned and evaluated as false, the instruction writes a zero to the address. This is an action you will not get if you don't scan it at all.

proof · Feb 15, 2019

Skidood said:
Because I'm a dumb newbie who assumed that if a subroutine is not being called, all the logic in it would basically just go false. That's why! :nodi:

The logic only makes changes when it is called, so the bits only change when the logic runs and changes the bits. Output coils do not hold outputs on like real relays, they turn the bits on or off when they are executed. If the inputs to the logic would make the output false, but the rung isn't executed, the output doesn't change.

Now think about what would happens to logic that depends a timer. You can do tests that depend on the timer accumulator (timer.acc). However, if the logic for the timer is in a subroutine that is not executed, the accumulator value does not change except when the timer is executed. Try putting a timer in a subroutine, but only execute the subroutine every 10 seconds. Watch the value of the accumulator.

another subroutine question

Skidood

Member

Geoff White

Member

thingstodo

Member

Skidood

Member

Skidood

Member

daba

Lifetime Supporting Member

daba

Lifetime Supporting Member

Skidood

Member

proof

Member

Skidood

Member

bernie_carlton

Lifetime Supporting Member + Moderator

OkiePC

Lifetime Supporting Member

proof

Member

Similar Topics