start/stop using one push button

[harrydeharry]

----||-----(P)-----(#)-------|/|-------(s)m1.0
pb M1.2 #temp m1.0

----||-----||--------|/|----------------(r)m1.0
#temp m1.0 pb

 

[Eric Nelson]

First let's get the labels lined up...

----||-----(P)-----(#)-------|/|-------(s)m1.0

    pb     M1.2   #temp     m1.0



----||-----||--------|/|---------------(r)m1.0

  #temp   m1.0        pb

Now, I'm not understanding how this can work. Normally, you alternate on the leading edge of an input, yet your reset rung uses a --]/[-- for the pushbutton. Therefore, M1.0 can only reset when the pushbutton is released. My next concern is the #temp bit. Won't that be on for only one scan when the pushbutton is initially pushed? If so, then how can it be on when the pushbutton is released, allowing M1.0 to reset?



-Eric

 

[ArikBY]

Take a look

http://www.plctalk.net/qanda/showthread.php?t=7945

 

[andreapg]

In that pdf file you can find a ladder diagram which I created using step7 mw.
When I press the button (I0.6) M0.0 and M0.1 turn on.
When I press the button again that merkers turn off.
http://electronline.it/doc/sist.movim..pdf

 

[signal]

One of our forum members, Doug_P has an animated avatar that shows a simple flip flop that will work with most PLCs.

This flip flop can be programmed on pretty much all PLCs. Assuming P is an unbuffered push button input it cannot be guaranteed to always work on a ControlLogix platform - most of the time it will work but there could be instances when the CLX IO updates between the first and second rung of Doug's flip flop.

I've been more partial to the Counter.ACC/0 method the last few years to create toggles. I don't bother with counter roll over, it will go on toggling just fine - if it is an issue then unconditionally unlatch counter.acc/14 and it will never roll over. With the counter.acc/0 method you also need to program something so the toggle is in the right state at go to run conditions.

However the OP is working with an Omron PLC and had to use the DIFU instruction. Maybe for the fun of it our Omron gurus could point out how to use the LSB of a counter and whether roll over is an issue or not.

that's interesting.., thanks

 

[primadisetiawan]

Greetings James and welcome to the forum. We don't do homework for you but we will help you.

The problem sounds simple enough on the surface, when we push a button we want the output to be the opposite of what it was, ie,

if button then output = not output

If only it were that simple. The first difficulty we encounter when trying to solve this problem is that the PLC can complete dozens of scans while a button is being pressed. Even if the operator is really fast, he is slower than the PLC. Even Wyatt Earp doesn't stand a chance. The output will change state ever scan and the final state of the output would be indeterminate. So what we need is a way to program that we don't want to respond to the button state, just the initial pressing of the button.

The DIFU, or differential up, instruction will turn on its addressed bit on the rising edge of the input. The bit remains on for only a single scan of the PLC. This is called a one shot. After that the bit will go false and remain false until the input goes false and then true again. One shots are incredibly useful and you will find that they have thousands of applications. Note that even though Omron calls it differential up, other PLC makers may call the equivalent a one-shot, or a one-shot-rising or a one-shot-falling (DIFD).

If input A has a push button wired to it, this rung will create a one shot pulse at bit B that will be true for one scan only when button A is pressed.

   A

--] [----------+----+

               |DIFU|

               +----+

               |B   |

               +----+

Lest I do all of your homework for you and you learn nothing, I'm not going to complete the ladder, rather, lets express what we want to have happen in words.

If b and not output then turn on the output.
If b and output then turn off the output.

This takes care of describing what happens when a pulse causes the output to change state. The rest of the time, the times when we don't have a pulse (ie, the time between the instant the button is pushed and the instant it is pushed again), we want the output to remain in whatever state it was in. We can express that this way:

If !b and output the leave the output on.
If !b and not output then leave the output off.

The first two statements can be expressed in Boolean math as
C = (B AND NOT C)

The second two statements can be expressed as
C = (NOT B AND C)

Combining the two we get

C = (B AND NOT C) OR (NOT B AND C)

I hope that helps.

You help very much.. thanks

 

[Calistodwt]

The boolean expression plus a OSR as suggested by TCONNOLLY seems to work fine and is the simplest solution I have seen yet on this forum

 

[VAN]

I'm with TC, but I would have the ctr reset when it reaches 2, so when the

acc = 0 -> off,
acc = 1 -> on,
acc = 2 -> rst -> acc = 0 -> off.

That way you don't have the ctr some how getting beyond a dint or sint or whatever data type you are going to have it setup as. This also allows for more options, such as confirmation options.

acc = 0 -> off,
acc = 1 -> confirm on,
acc = 2 -> on,
acc = 3 -> confirm off,
acc = 4 -> rst -> acc = 0 -> off.

(Note - you would have to setup a timer so the confirm is only an option for a couple of seconds, then force the acc back to its last state. A subtract function might work for this, or move statements depending if 1 or 3.)

Oh, and I like having an indicator over lay my pushbuttons. This allows the pushbutton to do what it is intended to do and the indicator can change depending on what is going on in the machine.

 

[jkerekes]

I made a Toggle AOI using the JK flip-flop FB instruction in 5000. I know this doesn't help if your using a different platform.

 

[chavak]

OP mentioned DIFU, so I guess he may be using Omron, I have seen this version which is suitable for CJ series and up, [credit is not mine]


Oops, just noticed this thread is 2 year old, sorry.

 

[gryskop]

To the original OP this might be homework, but I had exactly the same problem with ControlLogix and RSLogix5000 software.

The Pushbutton in this case is an input signal from FactoryTalk. The operator needs to press a button to change the duty state of the duty controller.

In RSLogix the [One Shot] is an [ONS] object, but you can replace this with whatever your system allows.

X1 and X2 are two memory bits I use in my code. X2 will be the toggled bit you connect to whatever function you require.

A simple but effective bit of coding. Not my own though. Also had to ask somebody how they've done it in the past.

 Pushbutton                       X1 

---| |---------[One Shot]---------( )--



      X1             X1           X2

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

  |         |    |         |

  |         |    |         |

  |   X2    |    |   X2    |

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

I too would have used a D-Latch flip flop, but unfortunately in my coding this function is not available in Ladder logic.

 

[daba]

To the original OP this might be homework, but I had exactly the same problem with ControlLogix and RSLogix5000 software.

The Pushbutton in this case is an input signal from FactoryTalk. The operator needs to press a button to change the duty state of the duty controller.

In RSLogix the [One Shot] is an [ONS] object, but you can replace this with whatever your system allows.

X1 and X2 are two memory bits I use in my code. X2 will be the toggled bit you connect to whatever function you require.

A simple but effective bit of coding. Not my own though. Also had to ask somebody how they've done it in the past.

 Pushbutton                       X1 

---| |---------[One Shot]---------( )--



      X1             X1           X2

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

  |         |    |         |

  |         |    |         |

  |   X2    |    |   X2    |

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

I too would have used a D-Latch flip flop, but unfortunately in my coding this function is not available in Ladder logic.

Infortunately this logic will revert back to the "un-toggled" state in the event of power-loss, or a change from RUN to PROG and back to RUN, which I doubt is what you want to happen to the "duty" pump selection.

As I have stated already, a "toggle" should not be affected by any other event than the logic that drives it.

If you want a toggle to reset on restart, then program it in the start-up section of the code for all to see.....

 

[daba]

Infortunately this logic will revert back to the "un-toggled" state in the event of power-loss, or a change from RUN to PROG and back to RUN, which I doubt is what you want to happen to the "duty" pump selection.

As I have stated already, a "toggle" should not be affected by any other event than the logic that drives it.

If you want a toggle to reset on restart, then program it in the start-up section of the code for all to see.....

Of course, for start/stop toggle circuits, you mostly WANT it to reset if the processor restarts, but not always... for some control (example : ventilation) it would be ok to restart automatically, others a definite no-no.

So the idea of using a common "toggle" (whichever way you do it), and having specific startup resets, actually documents or reinforces the reasoning behind why you are resetting specific toggles, in exactly the same way you sometimes have to write start-up code that resets or presets numerical data.

 

[DwSoFt]

Of course, for start/stop toggle circuits, you mostly WANT it to reset if the processor restarts, but not always... for some control (example : ventilation) it would be ok to restart automatically, others a definite no-no.

So the idea of using a common "toggle" (whichever way you do it), and having specific startup resets, actually documents or reinforces the reasoning behind why you are resetting specific toggles, in exactly the same way you sometimes have to write start-up code that resets or presets numerical data.

+1
i agree

 

[daba]

+1
i agree

glad someone else thinks like i do... :nodi: