Handling Stops & Resets in Sequential Programming

[themullet01]

Hi everyone. I was looking for some advice and I hope that some of you can help me. Is there any rule of thumb for handling stops and resets in a sequential program? It's something that confuses me now and again. For instance I have attached a simple example. It is a section of code controlling a sequence which has six states, State 0 - State 5. State 5 is the final state. Say for example that this code is controlling a machine and half way through the sequence the operator needs to pause or stop the machine mid sequence to remove a part or something. Once the operator has removed the part they restart the machine and the machine continues from where it has left off. It isn't really possible to insert a stop bit in the lines controlling the states as this will unlatch the particular state that the machine stopped on and it will not be possible to relatch on when the machine restarts. Also if the machine stops whilst in state 1, the timer will be affected??? So what is the best way to deal with these problems of stops and resets? I would really appreciate some help on this. thanks in advance

 

[jmsmoreira]

I normally use what I call Work flag, in the conditions for the next step. Let's say in your program, between the State0 contact and the part present contact.
This work flag can be among other things (light barriers, safety doors,....), controled by a stop and a start button.
If you press the stop button the flag will fall, if you press the start button the flag will come up again, and the cycle will continue.

 

[kolyur]

With the logic you provided, one solution would be to use JMP/LBL instructions to jump "around" the sequence rungs when the machine is paused. These rungs wouldn't be scanned during that time, which means that the coils would remain in their existing states and timers would stop and retain their current values. Now, some folks here will raise holy h-e-l-l when the idea of skipping rungs is suggested. They'll say it's poor programming practice (it isn't if done correctly and documented) and that it's harder for Bubba to troubleshoot (probably true). But you can't beat the simplicity of the JMP/LBL in this scenario.

I would propose that a better solution would be to change the OTE coils on your sequence bits to actual latch/unlatch coils. Each time the sequence progresses, you'll need to unlatch the current step bit and simultaneously latch on the next step bit. The advantage of this setup is that you can then insert contacts at the beginning of every rung to pause the sequence when necessary. Whichever step is currently latched will remain in that state.

 

[themullet01]

Hi thanks for the reply. So say for instance that I do what you suggest and place a 'work' bit (work bit is linked to all stop buttons) into the conditions for switching to the next state. That will mean that the machine will still go ahead and complete all actions in the current state even though a stop has been pressed. The stop button being pressed will only present a transition into the next state. Is that situation ok? Thanks again.

 

[Outrage]

Hi can you not put a "pause" XIC in your output logic that turns off all the outputs driven by the "STATE_X" bits in your output handing part of the program. You can also use a pause XIC on each sequence step in parallel to your latching branch.

This should mean that all your outputs are disabled, your sequence logic should stay latched where it is but not be able to step any further.
I don't know what the construction of the machine is but i've made the assumption you will want to disable your outputs when paused and disabling the outputs will leave your machine in the same state.

Cheers,

Lee

-Edited to add assumptions-

 

[jmsmoreira]

Hi thanks for the reply. So say for instance that I do what you suggest and place a 'work' bit (work bit is linked to all stop buttons) into the conditions for switching to the next state. That will mean that the machine will still go ahead and complete all actions in the current state even though a stop has been pressed. The stop button being pressed will only present a transition into the next state. Is that situation ok? Thanks again.

Thats what I do, then I also use the work bit to stop some outputs like motors or valves.

 

[Lancie1]

Also if the machine stops whilst in state 1, the timer will be affected???

Yes, it could be. For a temporary stop or hold, your T4:0 TON will either be reset to 0 and start over when State 1 is restarted, or it will time to 7 seconds and the DN bit will go on. What you must do is determine what is best for the process - should the timer stop in mid-stream then resume later, or should it be reset and start over, or should it continue to the end of the step before allowing a stop? If the timer can be interrupted mid-stream, then you could substitute a RTO Retentitive timer. If not, then you must make sure that State 1 is only allowed to be interrupted either before the timer starts, or after it finishes.

 

[OkiePC]

If it is beneficial to store the machine state through a power cycle, normal stop, or other mode change, then use a different style of State Logic using the OTL instruction. There are good examples if you search the forum for state engine or washing machine.

Keep mode control logic separate (before) the state processing.

I like to keep fault states separate too, sometimes a separate little state engine to control fault reaction steps if complex shutdown, reset or homing cycles might be required.

If you need to remove product and reset, then there should be a sensor in that location to make the state logic true on a branch back to the state you need when returning to auto mode.

If no sensor is practical, you need an operator control to decide whether to resume, back up one step, start from step 1, whatever suits it.

Most of the time, it has been beneficial to store the machine state through a power cycle, and if you find that you never need that, it is simple enough to always force step 1 when returning to auto.

 

[RheinhardtP]

Sequence

Be careful with Stop/Pause/ and Resets. The might be a risk to your product and process i have seen this a lot in the past. Which part of your sequence you can have this active on should be determined in a Risk Assessment initially. You will also find even after this that there are times you don’t want to interrupt the sequence.

I also have found that having a controlled reset yields better results. So i would track where my sequence is and initiate my Stop sequence when resetting A start sequence.

 

[iant]

Are you studying this or this your normal programming Method.
- Just asking to assist not missdirect you.

 

[themullet01]

Thanks for all the replies everyone. It has been great to hear all the different views. To answer IANT's most recent question I am an automation engineer who spent about 3-4 years programming. For the last 5 years though and in my current position I haven't been programming at all. And in that time I feel I have lost the 'knack'. I am attempting to get back into it now though and I am starting by practicing to programme sequences.

The programming method I have used in this thread is the one I used to use for programming sequences simply because It was easy to follow and debug. Some people may have different opinions on this?????

Kolyur and OkiePC suggested using the latching OTL and OTU outputs for lactching the different states. Do many people use this method? I remember reading in a plc programming book once that this method can be discouraged and that it is better not to use latches for the states? What do you think?

I suppose I am just trying to gauge what is best practice and will result in a better written program in the end.

Using the 'pause' or 'work' bit to inhibit the outputs as well as a transition to the next state is probably the easist solution but potentially the problem of the timers being reset and not holding their value still exists. Would everyone agree that the best thing to do is to simply wait until the current state is completed before stopping the sequence. This would solve a lot of the problems regarding stopping timers mid sequence?

THanks again.

 

[jmsm1]

Thanks for all the replies everyone. It has been great to hear all the different views. To answer IANT's most recent question I am an automation engineer who spent about 3-4 years programming. For the last 5 years though and in my current position I haven't been programming at all. And in that time I feel I have lost the 'knack'. I am attempting to get back into it now though and I am starting by practicing to programme sequences.

The programming method I have used in this thread is the one I used to use for programming sequences simply because It was easy to follow and debug. Some people may have different opinions on this?????

Kolyur and OkiePC suggested using the latching OTL and OTU outputs for lactching the different states. Do many people use this method? I remember reading in a plc programming book once that this method can be discouraged and that it is better not to use latches for the states? What do you think?

I suppose I am just trying to gauge what is best practice and will result in a better written program in the end.

Using the 'pause' or 'work' bit to inhibit the outputs as well as a transition to the next state is probably the easist solution but potentially the problem of the timers being reset and not holding their value still exists. Would everyone agree that the best thing to do is to simply wait until the current state is completed before stopping the sequence. This would solve a lot of the problems regarding stopping timers mid sequence?

THanks again.

Sometimes you cannot wait until the step ends, for instance if you have a conveyor waiting for product, you want to stop it, as soon as you press the stop button.

I also use latch/unlatch for my sequences

Regarding the timers being reset, I don't see a big problem on that most of the times.
And there is also ways of avoiding the timer to being reset, or at least to copy the actual value, and load it again, when you want

 

[daba]

You cannot generalise....

Process timers sometimes need to be reset on restart.

Process timers sometimes need to continue from where they were when the process stopped.

Process timers sometimes need to continue from where they were "held" only when other conditions are met (eg. temperature > minimum temperature)

You have to program each eventuality accordingly, there are no rules...

What you do should be in the process specification.

 

[OkiePC]

Kolyur and OkiePC suggested using the latching OTL and OTU outputs for lactching the different states. Do many people use this method?

If you need the status of the machine or the product to be remembered through a power cycle, fault condition, mode change, etc. then you must not use the OTE instruction unless you intend to add extra unnecessary code to copy the state.

I only use latch statements for state engines, preceeded by instruction clearing the whole field of bits, one bit per state (makes electrician searching easier) so they're enforced as mutually exclusive.

This is safe for abstraction, real I/O, not so much. Never directly address real I/O in the core sequence control, by the way.

I remember reading in a plc programming book once that this method can be discouraged and that it is better not to use latches for the states? What do you think?

Again, use common sense, I have never written a program without some latches for product and machine state tracking.

I suppose I am just trying to gauge what is best practice and will result in a better written program in the end.

Using the 'pause' or 'work' bit to inhibit the outputs as well as a transition to the next state is probably the easist solution but potentially the problem of the timers being reset and not holding their value still exists. Would everyone agree that the best thing to do is to simply wait until the current state is completed before stopping the sequence. This would solve a lot of the problems regarding stopping timers mid sequence?

THanks again.

Use the retentive timer: RTO.

I usually have two RTO timers for a sequence, one for the time in the current step, one for the total cycle time. This way, you can measure and study the duration of each step/state, even log it to find bottlenecks later.

On the rising edge of a state change, store the .acc value of the Current Step RTO, then load the PREset for the new step, and RESet it.

Alternatively, with state engines that are 16 states or less, using a unique timer for each one is fine too, use RTO, and reset them at the rising edge of the 1st step of your sequence. When the maintenance tech watches the timer file, he will see them all go to zero, then each one count up as the sequence progresses, stopping and leaving the accumulator there for study.

For time limits at the device level, like coil dwell and contactor restart delays, well those go right in the output driver logic, not in the sequence.

These are my practices, and they are relatively general purpose approaches.

 

[iant]

Hi - themullet01
the reason I asked is that there are a few methods to do state sequencing.
Ladder was the original method but is very clumsy and can be a problem.
OTL/OTU is an answer - when used as OKiePC suggests
I prefer using the MOV/ (compare) for process control.
I was asking your experiance as I did nt want to confuse a student with this answer