2 OSR's same bit

Jezz · Apr 30, 2003

Hi all,
Just a quick question my co-worker has said using the same OSR twice is bad practice in the following bit of code could you please give me your opinion.
What happens is I:1/0 is pressed O:2/0 latches, then when I:1/0 is pressed a second time O:2/0 unlatches.



    I:1/0    B3/0        O:2/0    B3/1     O:2/0

|----] [-----[OSR]--------]/[-----[OSR]-----(L)----|

|                     |                            |

|                     |  O:2/0    B3/1     O:2/0   |

|                     ----] [-----[OSR]-----(U)----|

Thanks Jezz

ndzied1 · Apr 30, 2003

Since the manuals recommend against it, I would say that even though the code works as desired now, that may not be the case in future processor revisions or on other processors.

By not specifically defining what happens when a one shot bit is used multiple times in a program, Rockwell is then free to change the internal behavior of the bit so long as it doesn't change what happens when you only use the address one time as listed in the manual.

Since there are several different ways to duplicate the code you posted (just search this site for "one button toggle") I can see no reason not to bring it into compliance with the recommendations of the programming manuals.

Just my opinion (...and it's free)

kamenges · Apr 30, 2003

You have a rather special case that just happens to work by playing how the plc actually processes a oneshot. I would suspect that if you used the same bit on two unrelated rungs it wouldn't work so well.
I agree with Norm. There are clearer ways to do this same thing and I recommend you use one of the other options. But that is a nice little exploit you have there.

Keith

93lt1 · Apr 30, 2003

I have seen some strange things from addressing a one-shot twice.(first hand experience...my own fault)

My Hopethesis : The one-shot address when used twice as an OSR, is true for only one scan for which ever of the two rungs' preceding conditions came true first. If the second rung's preceding logic comes true and the first is still true, nothing happens.

My Untested Conclusion : In this case the O:2/0 can obviously not be on and off at the same time so no problems are realized.

After re-reading the post above, IF the above logic works, My Hypothesis is not correct.

Does it work??

Jezz · Apr 30, 2003

Yes it work's its works just fine

93lt1 · Apr 30, 2003

Well I guess it's another one of those "mysteries"

Jezz · Apr 30, 2003

I was actualy show this bit of code on a traing course last September (not an AB course)...........

The question is now should I tell my boss about this??? lolis

Jezz

seppoalanen · Apr 30, 2003



    I:1/0    B3/0        O:2/0      O:2/0

|----] [-----[OSR]--------]/[--------(L)----|

|                     |                     |

|                     |  O:2/0      O:2/0   |

|                     ----] [--------(U)----|

Is this works as well ? No, it is not! Sorry !

Steve Etter · Apr 30, 2003

I believe you will find that your logic will work just as well without OSR B3/1 at all:

    I:1/0    B3/0        O:2/0             O:2/0

|----] [-----[OSR]--------]/[---------------(L)----|

|                     |                            |

|                     |  O:2/0             O:2/0   |

|                     ----] [---------------(U)----|

The reason this (and your logic, too) is because the PLC does not update update the status of O:2/0 until the after the entire rung is complete. The key here is that you wrote the logic as a single rung. As kamenges pointed out, it would not work so well had you programmed it as two separate rungs.

Steve

Allen Nelson · Apr 30, 2003

No, Seppo, that won't work. The first branch will be evaluated first, setting O:2/0. THEN the second branch will be evaluated. Since O:2/0 will be set, the second branch will Reset it.

That's what the oneshots are for. When the PLC scan evaluates a one-shot, if the bit is not set, it sets the bit and proceeds to evaluate the rest of the rung/branch as TRUE. If the bit is already set, the PLC retains this state, but evaluates the branch as FALSE. If the rung/branch condition is FALSE, the PLC resets the one-shot bit.

And that's WHY this silly piece of code works. It would not work if the branched oneshots had different addresses, because then the second branch would work the same way as the logic that Seppo posted.

If you were to change the oneshot into the coil equivalent:



           Bit                                                    Bit

 . . .A---[OSR]---B . . . .     =     . . .A---+------------------( )

                                               |

                                               |   Bit

                                               +---| |---B . . .

'
then this would be the roughly the same as the "double-coil" flip-flop that I posted HERE

I agree with Keith, it's a unique way of making double-oneshots work for you.

Thanks for the chuckle.

Peter Nachtwey · Apr 30, 2003

A thousand cursers on the PLC manufacturers.

They shouldn't even give one the option to use two or more one shots with the same state coil!

This is a violation of Delta rules #2:
Make it difficult to do the wrong thing.

I had to go to a end user site where the integrator botched a project. The problem was that one coil was used to hold the state of 5 one shots! It is no wonder things appeared to happened randomly. This was many years ago and the first time I ever programmed a PLC5.

I addition I just don't like the inconvenience of having to pick another state bit and make sure it is not used some where else. I think they should be allocated automatically out of a pool of one shot state bits.

There may be cases where using one state bit for multiple one shots works but as someone pointed out there is usually a clearer simpler way.

I like modicon's history table technique better with the N and P( negative and positive edge) contacts. Why? Because the positive and negative edge states change only between scans whereas AB, Siemens and TI505 edge detection happens when the one shot is executing. In general I think it is harder to screw up oneshots using the old Modsoft.

Our product uses the Modsoft approach which adhere to Delta rule #1:
Make it easy to do the right thing.

Steve Etter · Apr 30, 2003

Well maybe it won't work in every processor (can't say for sure) but I am working with a Unitronics V280 right now where it is.

I have a Fanuc 90-30 I am going to set up and try it on now.

Steve

Alright. I wrote the code (single One-shot) in the 90-30, and it does not work. I actually does in the V280, though. Hmmm...

Jezz · Apr 30, 2003

I've now replaced this bit of code with a counter and a couple of equals i.e







      I:1/0    B3/0        ---------------

|------] [-----[OSR]-------|CTU          |----(CU)---|

|                          |Counter C5:0 |           |

|                          |Pre       2  |----(DN)---|    

|                          |Acc       0  |           |

|                          ---------------           |

|      ---------------                         O:2.0 |

|------|EQU          |-------------------------(L)---| 

|      |Sour C5:0.acc|                               |

|      |Sour        1|                            

|      ---------------                               |

|      ---------------                         O:2.0 |

|------|EQU          |-------------------------(U)---| 

|      |Sour C5:0.acc|           |                   |

|      |Sour        2|           |                   |

|      ---------------           |   --------------  |

|                                |---|MOV         |--|

|                                    |Source     0|  |

|                                    |DestC5:0.acc|  |

|                                    --------------

Allen Nelson · Apr 30, 2003

That works, Jezz, but it is not very efficient or elegant. The only place where I would consider it acceptable is when you are designing a system that currently has only two states and want to leave open the possibility for 3 or more without having to make significant changes.

There are two common solutions:

The ONE-SHOT



   Input            Input-ONS

----| |----[OSR]------( )

 



  Input-ONS   Output           Output

-----| |--------|/|-----+--------( )

                        |

  Input-ONS   Output    |

-----|/|--------| |-----+

The EXCLUSIVE OR



    Input       WAS              WAS

-----| |--------| |-----+--------( )

                        |

    Input     Output    |

-----|/|--------| |-----+

 



    Input       WAS             Output

-----| |--------|/|-----+--------( )

                        |

    Input     Output    |

-----|/|--------| |-----+

Most programmers use the ONE-SHOT, but I've seen plenty of XOR style flip-flops too.

Your use of Latch-Unlatch means that the Output will return to it's last state after a power failure, which the above code won't. Is this required, or a potentially dangerous side effect?

seppoalanen · May 1, 2003







      I:1/0                ---------------

|------] [-----------------|CTU          |----(CU)---|

|                          |Counter C5:0 |           |

|                          |Pre       2  |----(DN)---|    

|                          |Acc       0  |           |

|                          ---------------           |

This works as well, CTU is dynamic itself ?

2 OSR's same bit

Jezz

Member

ndzied1

Lifetime Supporting Member

kamenges

Member

93lt1

Member

Jezz

Member

93lt1

Member

Jezz

Member

seppoalanen

Member

Steve Etter

Lifetime Supporting Member + Moderator

Allen Nelson

Member

Peter Nachtwey

Member

Steve Etter

Lifetime Supporting Member + Moderator

Jezz

Member

Allen Nelson

Member

seppoalanen

Member

Similar Topics