Creating a sequencer

randy741985

Member
Join Date
Oct 2006
Location
US
Posts
154
What is the cleanest method in creating a sequencer?
Example
step1. a cylinder extends holds a part.
step2. a drill extends over the part locates .
step3. drill drills the part.
step4. drill retracts.
step5. a tap extends over the part locates.
step6. the tap retracts.

And So On, You get the idea.
 
Here is a method that is simple to implement quickly, and allows for jumping around between steps without a whole lot of overhead...

SEQ_001_sh1.JPG


SEQ_001_sh2.JPG


SEQ_001_sh3.JPG
 
I have used the method described by OkiePC many times and it works great. It's simple to understand and troubleshoot, and allows for more flexibility than using the sequencer instructions (i.e. SQO). For example, with this method you can have multiple steps running at once if your process requires it. It's all in how you start and stop the steps.
 
Okie's ladder looks dangerous to me.

One could have race conditions because there is nothing to prevent more than one state to be executed per scan.
I prefer to have pending bits that get copied to the active bits at the top of the ladder. I know this requires twice as many bits but it avoids race conditions and makes debugging a whole lot easier if you decide to put state bits in a queue so you can monitor the sequenc of events.

The real problem is that ladder is very poor for organizing state machines. SFCs are much better.
 
While I agree that ladder based state machines can be a little bulky I'm not really sold on the SFC implementations I've seen either. SFC gets real ugly real fast if you need to alter your sequence. If the have a process that can be so rigidly sequencial that you will never need to alter your sequence a simple bit shift will probably work almost as well.

I personally like the text-based languages for state machines. Most provide a methodology to create a state machine pretty quickly. If they either support execution of one state per evaluation or provide an instruction to exit the construct after a state is run, all the better.

Keith
 
Peter Nachtwey said:
One could have race conditions because there is nothing to prevent more than one state to be executed per scan.
I prefer to have pending bits that get copied to the active bits at the top of the ladder. ...

I dont think Paul finished the logic, rung 7 is the 'set' and its used in rung 2, but not again...I think this is where the interlock come into play
 
Last edited:
randy wrote:

What is the cleanest method in creating a sequencer?

Wow. There are at least three or four ways to do it, and everybody has a favorite. Mine is to use an integer register to hold the "Step" and move from 10 to 20 to 30... etc. I've also used bits but you have to hold those on (or use latches) and it's harder to insert new steps if you've used bits in the original sequence. On the other hand, bits process faster.

I generally number by 10's; this lets you set up some numbers between steps as process faults (i.e., the process step is from 10 to 20, but 11 might be used to indicate a particular failure of the 10 to 20 transition) and also leaves room to insert rungs later. To formalize it a little more, Steps 10 to 99 are used for start-up logic; Steps 100 - 199 are used to test interlocks and initial conditions before running the sub; and 200 - 899 are for the normal subroutine logic. If a subr is on Step 899, then it's done and waiting for it's next cycle; if it's in between, the subr is running; and if it hangs up, you look at the Step value and immediately know where and why.

The beauty of using state logic for a sequential machine is that you can program for fault recovery, safety and maintenance all at the same time. If the machine stops, you know why and you can write logic to recover from fault conditions that all can have numbers! The machine is safer because actuators don't fire just because somebody broke the beam or made the switch; the sensor is processed only on the step that needs it, and the rest of the time it's ignored. And, as has been said, state logic is easy to read and follow since it moves one step at a time through a sequence, and you can follow those steps.

There is no "best" way to do it, and in a real machine there are a lot of other things to worry about like actuator and sensor fault handling, parallel and series processes, subroutine and machine reset and initialization, minimum cycle time and data development and collection. And every time I write a sequence, I learn something else about how to do it better. You have the idea; try laying your steps out using bits or numbers and see what it looks like.
 
randy741985 said:
What is the cleanest method in creating a sequencer?
Example
step1. a cylinder extends holds a part.
step2. a drill extends over the part locates .
step3. drill drills the part.
step4. drill retracts.
step5. a tap extends over the part locates.
step6. the tap retracts.

And So On, You get the idea.

We have actually discussed a real machine that did something similar: http://www.plctalk.net/qanda/showthread.php?t=22335&page=1&pp=15http://www.plctalk.net/qanda/showthread.php?t=22335&page=7&pp=15

There was talk of sequencing, drums, state machine etc. but plain ladder did the job. How you do something can/will depend upon the variables involved.
 
Paul T said:
Wow. There are at least three or four ways to do it, and everybody has a favorite. Mine is to use an integer register to hold the "Step" and move from 10 to 20 to 30... etc. I've also used bits but you have to hold those on (or use latches) and it's harder to insert new steps if you've used bits in the original sequence. On the other hand, bits process faster.

I generally number by 10's; this lets you set up some numbers between steps as process faults (i.e., the process step is from 10 to 20, but 11 might be used to indicate a particular failure of the 10 to 20 transition) and also leaves room to insert rungs later. To formalize it a little more, Steps 10 to 99 are used for start-up logic; Steps 100 - 199 are used to test interlocks and initial conditions before running the sub; and 200 - 899 are for the normal subroutine logic. If a subr is on Step 899, then it's done and waiting for it's next cycle; if it's in between, the subr is running; and if it hangs up, you look at the Step value and immediately know where and why.

The beauty of using state logic for a sequential machine is that you can program for fault recovery, safety and maintenance all at the same time. If the machine stops, you know why and you can write logic to recover from fault conditions that all can have numbers! The machine is safer because actuators don't fire just because somebody broke the beam or made the switch; the sensor is processed only on the step that needs it, and the rest of the time it's ignored. And, as has been said, state logic is easy to read and follow since it moves one step at a time through a sequence, and you can follow those steps.

There is no "best" way to do it, and in a real machine there are a lot of other things to worry about like actuator and sensor fault handling, parallel and series processes, subroutine and machine reset and initialization, minimum cycle time and data development and collection. And every time I write a sequence, I learn something else about how to do it better. You have the idea; try laying your steps out using bits or numbers and see what it looks like.


Thanks For your response and I agree I like using a Integer to move thrugh the Sequence Then Use compare Statments to turn on the outputs.
 
randy741985 said:
Thanks For your response and I agree I like using a Integer to move through the Sequence Then Use compare Statements to turn on the outputs.

I too like Integer to Jumps ...but not to turn on State Flags.
1. It's still easy to see what "State" your in.
2. You Jump to Section that Runs and Jump to Bottom of Sequencer at end of section.
3. With the exception of all the compares it Runs fast and you can duplicate outputs (and timers etc) because the previous section does not run (depending on vendor). Though I like Set/Reset logic myself.

This is still easy to view in Ladder or FBD without some of the limitations of Graph (Limited Transition code possibilities)

You can really write some nice stuff:
Fault Jump to here
Pause Jump to here and resume at OLD Step (I maintain current and Last Step for jump back function)
Name your labels and anyone can understand it.

Nick
 
there are many ways to do sequencer and none is perfect, they all have good and bad sides.

just check out how many questions are about AB sequencer instructions for example. many people don't know how to use them even though AB PLCs are probably most popular platforms among users on this forum for example.

once you see that and realize that every controller comes with some way of implementing sequencer but it is different from brand to brand, simple question is who wants to learn all differences and explain gotchas over the phone to late calling customers who specified which brand they want (or have paid support for) but never really learned how to use it...
since i have to use whatever plc customer wants, and development time is always short, it was quite important to look for something that works on any plc.

one very simple method is use of counter, this makes sequence straight copy of the step list you showed, implementing multiple modes is a snap, jumping around is very easy (from one step to another) but shifting or inserting new steps around is not as easy as one would like to.

this wasn't problem for me as all planing is done before programming (excel), leaving few blank steps here or there just in case we need to make changes is not an issue either (those are processed too fast to notice), and one can and should brake any long sequence into smaller more managable parts. each can be separate sequencer which is then called by master sequencer for example etc.

if you are interested, here are some examples using same type of logic:
http://forums.mrplc.com/index.php?download=550 (allen bradley)
http://forums.mrplc.com/index.php?download=631 (mitsubishi)
 
Last edited:
Peter Nachtwey said:
looks dangerous to me.

Yep. It is real dangerous in this unfinished example. Sorry I didn't point that out.

All I was trying to do was illustrate a method of building a state machine with mutually exclusive steps that can be selected about any way the designer chooses. Allow me to expand on the example a little here:

The AUTO bit is just for example and is controlled elsewhere....usually I define my modes in logic that precedes the sequence control example.

The 1 step per scan bit lets the designer decide when it is okay or not okay to move through multiple steps in a single pass. Examine the "1 step per scan bit" where you need to, in order to avoid "racing". Also, careful construction of the definitions for "step n done" will eliminate the possibility of racing.

The "step done" conditions may be defined in logic preceeding the sequencer or just addressed right there on the branches of the sequence control. If the rungs start getting ugly from too many contacts, just redefine them in a prior section of code and use single bits that can be easily back tracked.

Basic idea: define your input conditions and update them. Process the state engine to put the machine in only one most correct state. Update the output logic and repeat.

You can take a simple flow chart diagram and translate it to the above example quite "cleanly" and most of your technicians will be able to completely understand how it works.

It is very oversimplified, does not include step tracing, diagnostics or other advanced features. For those, I use a whole 'nuther animal...
 
Mine is to use an integer register to hold the "Step" and move from 10 to 20 to 30... etc. I've also used bits but you have to hold those on (or use latches) and it's harder to insert new steps if you've used bits in the original sequence. On the other hand, bits process faster.

I like using bits, mostly because boolean logic is cleaner in Ladder and easier to see executing online.

The key word(s) to search for: State Machine.
 

Similar Topics

The idea here is to provide for a brief rapid influx of message codes while preventing sequentially repeating the same message. i.e. if two...
Replies
23
Views
675
Hello everyone, In a factory where we installed Citect 7.20 the computer began to show the first signs of end of life. They never considered...
Replies
0
Views
73
Hi everyone, I'm a last year student at the university in Ghent, and for my thesis i need to write a TwinCAT program that writes data to a .daq...
Replies
0
Views
141
When I go to create a new module in Studio 5000 I can't enter any information for the IP Address or change any other fields. Is there any fix to...
Replies
1
Views
253
Hello I am kind of new to the Rockwell world, i've mainly worked with Siemens and Schneider untill now. I am to make a HMI application running...
Replies
7
Views
1,062
Back
Top Bottom