Good Program Design for an OR Branch With Latching?

TL140 · Apr 22, 2015

I was reading Programmable Logic Controllers: An Emphasis on Design and Application, By Kelvin T. Erickson (great book, highly recommend) and I remember that there was a section saying that the following situation was bad programming practice, but I cannot remember the solution. I wont have my book back for a few weeks and I thought that you guys may also have your own approaches so I figured why not ask you guys.

Situation:
Basic On/Off motor w/ memory with also an HMI start button. Logic would look a lil like this..



Start                  Stop         M1

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

HMI_Start    |

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

  M1         |

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

What would you guys use?

paraffin power · Apr 22, 2015

I'd use that method. I'd oneshot the start buttons too.
I'd be interested to hear why this is 'bad'.
Pp

rdrast · Apr 22, 2015

I'd start the rung with the STOP contact, then have the seal in branch.
In some PLC's it makes no difference, as they will scan everything in every rung anyway, but in others, as soon as a false condition is detected, the rung evaluation stops and the output(s) are updated.

JesperMP · Apr 22, 2015

There is absolutely nothing wrong with this approach.
I would like to know the arguments as to why it is bad programming style.
As long as the rung doesnt become very huge, it is more easy to understand in a hurry, as opposed to splitting into separate -(S) and -(R) rungs.

The HMI_start is dubious though.
There is no HMI_stop, so is it a toggle switch or a momentary button ?
If a toggle switch, if HMI_start is true, M1 will stop and then restart when Stop is pressed.
If it is a momentary button, there is the risk that the state hangs if the HMI is shutdown or there are comms problems. I prefer to generate oneshots for momentary HMI buttons, and then use the oneshot states for the start/stop logic.

Aabeck · Apr 22, 2015

The only thing I do differently from the "bad" example would be to add check's for: (as appropriate)
Motor OverLoad Relay, Tank Level OK (if a pump), Lid or Safety Open, MCR On, E-Stop ON, etc between the STOP and M1 Output. That way the output will be shut off if any of the safety items trip. Otherwise I use exactly that line many times.

jethridge · Apr 22, 2015

I see logic like that almost every day, not sure why it's 'bad'. Never had a customer complain, even pharmaceutical customers.

Steve Bailey · Apr 22, 2015

The logic can be improved if you use a confirmation signal from the output device instead of the command as the sealing contact. For example, if M1 is a motor starter, wire an auxiliary contact from the starter to a PLC input and use the aux contact in place of the M1contact. That way, if the starter trips out on an overload, the PLC will also turn off the command to the starter.

JesperMP · Apr 22, 2015

Steve Bailey said:
The logic can be improved if you use a confirmation signal from the output device instead of the command as the sealing contact. For example, if M1 is a motor starter, wire an auxiliary contact from the starter to a PLC input and use the aux contact in place of the M1contact. That way, if the starter trips out on an overload, the PLC will also turn off the command to the starter.

If one uses oneshots on HMI buttons (as I suggested earlier), you cannot use the aux contact for seal-in.
Btw, we also use oneshots on hardware start-buttons. If it is stuck on, the motor wont start. No oneshot on the hardware stop-button.
As to that the contactor drops out or does not engage, there should be alarms that monitors this, and the alarms should be in series (negated) with the stop button.

Steve Bailey · Apr 22, 2015

HMI buttons can be tricky. They can get stuck in the on state. Hence the practice of using one-shots.

You can turn an HMI button into a one-shot by the following code inserted at the end of the PLC's main routine.



HMI_Start                                 HMI_Start

----] [-----------------------------------(R)-

That doesn't work around the issue of having to wait for the feedback signal before turning off the HMI button. For that you can use the following:



HMI_Start     Feedback                HMI_Start

----] [------------] [-------------------(R)-

JHarbin · Apr 22, 2015

Steve Bailey said:
HMI buttons can be tricky. They can get stuck in the on state. Hence the practice of using one-shots.

You can turn an HMI button into a one-shot by the following code inserted at the end of the PLC's main routine.

HMI_Start HMI_Start
----] [-----------------------------------(R)-

That doesn't work around the issue of having to wait for the feedback signal before turning off the HMI button. For that you can use the following:

HMI_Start Feedback HMI_Start
----] [------------] [-------------------(R)-

I program my HMI buttons as Momentary, but I always have logic in my PLC or Controller that looks at the point that the HMI is controlling and if it is ON for a period of time (say 2 seconds), it gets turned OFF by the PLC or controller.

Admittedly, I typically use Redlion HMIs and Honeywell HC900 controllers and they make this programming simple, but I use this method when I program PLCs too.

I also *always* program a popup to actually make the change. The actual pushbutton will be on the popup. It becomes a sort of "Are You Sure?" without actually asking the question.

osmanmom · Apr 22, 2015

Local Start , Remote Start ?

Manual Mode ,Auto Mode ?

TL140 · Apr 22, 2015

thanks for the input guys. Once I get the book back, I'll be sure to update on what was written. Shoot, I may even be thinking of something totally different haha. But nevertheless, I have learned some things in this thread.

TL140 · Apr 22, 2015

JesperMP said:
The HMI_start is dubious though.
There is no HMI_stop, so is it a toggle switch or a momentary button ?
If a toggle switch, if HMI_start is true, M1 will stop and then restart when Stop is pressed.
If it is a momentary button, there is the risk that the state hangs if the HMI is shutdown or there are comms problems. I prefer to generate oneshots for momentary HMI buttons, and then use the oneshot states for the start/stop logic.

Well it was more of a quick write up. It may have had a HMI stop, but I wanted to more or less demonstrate on the OR input with the latch as well. Like I said in my previous post, I may have though of something totally different.

jtashaffer · Apr 22, 2015

I agree with with one shots on hard wired pushbuttons. I had a line awhile back that would start up on its own because of that reason. As far as the rung goes I set mine up like that. But as stated by others stop pb go on the left side then start on and seal in then the condition inputs motor overload, safeties ok etc then the output

Aabeck · Apr 22, 2015

When I program things, I put the most common on item in the main line & branch down in order to the least common on item. When I check conditions that must be met I start with the least common on item & progress to the most common on item.

Maybe the example is "bad" because the Start PB is on the main line, which would be the least common on item & forcing the CPU to process the branches almost every scan.

The attached picture is how I would order the rung to improve scan time.

Good Program Design for an OR Branch With Latching?

TL140

Lifetime Supporting Member

paraffin power

Member

rdrast

Lifetime Supporting Member

JesperMP

Lifetime Supporting Member + Moderator

Aabeck

Member

jethridge

Member

Steve Bailey

Lifetime Supporting Member + Moderator

JesperMP

Lifetime Supporting Member + Moderator

Steve Bailey

Lifetime Supporting Member + Moderator

JHarbin

Member

osmanmom

Member

TL140

Lifetime Supporting Member

TL140

Lifetime Supporting Member

jtashaffer

Member

Aabeck

Member

Similar Topics