2 OSR's same bit

[Jezz]

Allen,
The latch is reset on a first scan so I also need on the unlatch to be able to latch a reset bit which is why I've used a latch and unlatch.

Hope that makes sense

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

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

|  |   First scan       |        |---|MOV         |--|

|  ------]  [------------        |   |Source     0|  |

|                                |   |DestC5:0.acc|  |

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

|                                |                   |

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

 

[Allen Nelson]

A few comments on the logic posted

1. The OSR B3/0 is not needed. Counter only increment on a false-to-true transition, which is to say they have their own built-in oneshot.

2. I notice that instead of RES the counter, you just MOVe a zero into the .ACC value. I'm trying to remember if counters will continue to count when their /DN bit is set (I know that Timers stop timing, but I don't remember about counters.) Of course, the RES resets the /DN bit and the /EN bit as well (I think), which means on the next scan, with the /EN bit not set, the counter would increment (assuming that the input remained on), which would be why you DO need the one-shot after all.

This is why I generally don't like the Counter solution to the flip-flop (although it's popular enough). There are just too many ways that it can go wrong.

3. Instead of 1=OTL and 2-OTU, why not make it a bit simpler and have 1=OTE? You still have to have first-scan logic to reset the counter so that it's not on 'one' at startup, of course.

 

[93lt1]

Re: A few comments on the logic posted

I'm trying to remember if counters will continue to count when their /DN bit is set (I know that Timers stop timing, but I don't remember about counters.)[/B]

Since I was quoting from RSLogix 500 help in another post, here is what they say about counters counting vs. the .dn bit.

Description

This output instruction counts up for each false-to-true transition of conditions preceding it in the rung and produces an output when the accumulated value reaches the preset value. Rung transitions might be triggered by a limit switch or by parts traveling past a detector.
The ability of the counter to detect false-to-true transitions depends on the speed (frequency) of the incoming signal. The on and off duration of an incoming signal must not be faster than the scan time.

Each count is retained when the rung conditions again become false, permitting counting to continue beyond the preset value. This way you can base an output on the preset but continue counting to keep track of inventory/parts, etc.

Rockwell Software 2000

 

[Jezz]

Right Final version still using counter as I can think of another way

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

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

|                          |Counter C5:0 |           |

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

|                          |Acc       0  |           |

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

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

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

|      |Sour C5:0.acc|                               |

|      |Sour        1|                            

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

|      ---------------                         B9/35 |

|------|GEQ          |-------------------------(L)---| 

|      |Sour C5:0.acc|           |                   |

|      |Sour        2|           |                   |

|      ---------------           |            C5:0   |

|                                |------------(RES)--|

|   First Pass                                C5:0   |

|------] [------------------------------------(RES)--|

 

[rdrast]

Final version using a counter could be even easier if the output is O:x.0, don't bother resetting it, just MVM (Mask Move) the counter value directly to the output, masking to allow only the least signifigant bit through.

 

[kamenges]

Final version using a counter could be even easier if the output is O:x.0, don't bother resetting it, just MVM (Mask Move) the counter value directly to the output, masking to allow only the least signifigant bit through.

...except when you get to 32767 and the counter doesn't increment anymore.

 

[kamenges]

Sorry...

I was informed by someone keeping an eye on me that the counters in a SLC are handled as true 16-bit unsigned counters. So on the count after 32767 the counter accumulated will display as -32768 but all the bit actions will be correct. I suspect it will behave itself at the -1 to 0 rollover also.

So, never mind my last post and KEEP A CLOSE EYE ON ME!!!

Keith

 

[Ron Beaufort]

one more for the topic that would not die ...

[attachment]

 

[Peter Nachtwey]

Beauty is in the eye of the coder.

Ron, that looks most obvious to me. It's simple and clean.
I have been looking at the other post and shaking my head wondering how difficult can they make this.

 

[The Water Boy]

Like the poster implied, I would try that masked move rung only if I were interested in being woken up by a phone call from a confused maintenance guy trying to figure out why the machine isn't working. As I'm sure we all know, they always zero in on the part they don't understand and blame it for whatever problem they are having.

 

[jshiepe]

One more option with the counter:

|

|   I:1/0                            C5:0/DN             C5:0

|---| |------|OSR|--------------------| |----------(RES)--------|

|                               |

|                               |

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

|                               |-----| CTU C5:0 |--------------|

                                      | PRE = 2  |

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

|

|    C5:0/DN                                       O:2/0

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

Jeff

 

[Tom Jenkins]

Well, fellers, all of the above hoorah illustrates purty well a couple of reasons why I avoids them one shots and latch/unlatch coils in my logic if'n at all possible.

1) The operation of a one-shot is often non-obvious, and difficult to troubleshoot.

2) The operation of the logic varies from one PLC brand/model to another. That means you have to re-think the logic if you want to transport the code to a new system.

Jist my opinion, fellers.

 

[PLucas]

As I'm sure we all know, they always zero in on the part they don't understand and blame it for whatever problem they are having.

That's a rather sweeping statement to make!

There are many of us regulars here who are, first and foremost maintenance technicians, who happen to do a bit of PLC programming as well. I think you will find that what you stated is not always the case.

Do not tar us all with the same brush!

In case you are wondering.....Yes, you have annoyed me! :angr:

Paul

 

[ArikBY]

I use I very simpel logic which work great with most of PLCs except Modicon.

code



             b3/0

----{I0}----{osr}---------{b3/1}-----



      b3/1     b3/2

------{ }-----------{ }----------{B3/2}--

             I             I

             I             I 

     b3/1    I      b3/2   I   

------{/ }-----------(/ )---

It also very esey to reset and to track

 

[PhilipW]

TomJ I just have to add my whole hearted support to your comment about not using osr's and latch/unlatch's.

The osr's are just a lazy programmer's technique. There is always a better way to do it. I haven't used one for years.

Of the two methods presented here for the "One Button Flip-FLop" problem, both work just fine, but I prefer the XOR method JUST because I don't have to taint my pure and innocent code with an OSR.

OTL/OTU's are not quite so bad, just as long as they are used strictly as pairs, and when I use on I always document in the rung comment whereabouts it's mate is.

As for folk who use multiple OTL's and/or OTU's on the same flag....yuk.

State Diagram techniques eliminate 90% of this kind of nonsense.