Sequential Programming Methods

TL140

Lifetime Supporting Member
Join Date
Jun 2014
Location
South Carolina
Posts
152
Hey guys,

I was curious as to what is your preferred method for sequential/step programming? I have seen a lot of ways used such as Hex MOVs, Shift registers, counters, and even sequential latching, and a few others.
 
Personally prefer tag 'Step Number' as DINT, and use DINT MOV instructions as I go. Allows me to create code that is easy to read, and align with the functional descriptions for process engineers. I am accustomed to large systems subject to internal FATs, external FATs with customers and finally SATs during commissioning. The design documents need to be easily read,, and translated to code. Makes no sense to me to bugger it up by converting to HEX or using bits shifts...etc. Also allows me to provide space for spare steps for when commissioning time comes around.

1 -> 10 -> 20 -> 30...etc

Early on in my career it was 'pin charts' and indirect addressing, this was a bit more painful to modify the sequence, and the documentation couldn't account for steps that required a variety of step transitions, or variety of output activation conditions.
 
TL140,

I would say that the biggest guiding factor in regards to programming comes
from the customer specifications.

The MOST important factor is to get to know your customer's maintenance department and learn their capabilities. What they are used to seeing, their ability to learn new things.

I had to work on a machine for a year before management had me rewrite the program because it was written in GRAFCET (French type sequencer if I was told correctly). No one could figure out the errors on the display due to the style of programming.

Downtime went from 600 hours a year to 96 hours.

Just because you can program something quickly using masked moves, bit shifts, sequencers and other methods, doesn't mean maintenance can debug it.

Remember and NEVER, EVER forget who your friends are, MAINTENANCE !
If they cannot understand or trouble shoot your program, the machine is worthless. Management will hear about the problem, your boss will hear about it, and you will hear about it, and YOU will baby sit the machine 24/7 until the problem is fixed.

regards,
james
 
I have started some years ago using bit latching...
Then I changed to "step number" as the above post...
Easier to troubleshoot, to display alarms...
 
Personally, I'm a fan of using state machines with a step number, as others have said.

I typically have an INT that is my CurrentStep. Lots of networks are run conditionally based on comparing CurrentStep to whatever step in the statemachine/sequence is appropriate. Multiple steps may activate any given network, depending on what you are trying to do.

I also have a number of transition networks, that check the current step, and if conditions are met, move to a different step. It is possible that your sequence could branch, meaning that a step could have different transition tests to move to two different steps, depending on what happens. When the transition condition is true, I move the new step number into NextStep. I copy NextStep into CurrentStep at the end of the program, so that only one step executes per program cycle.

If you are really concerned about speed you can use a bit for each step instead of an INT comparison. However, I do recommend still having a number defining the current step number, even if it is just used to set which step bit is true. An INT can only have one value. It is very easy to accidentally have multiple bits set true simultaneously.

If your PLC supports the ENUM data type, it makes it very easy to document the different step values. Otherwise, you need to at least have them in the comments somewhere.
 
In effort to maintain the understanding of what I have used for years, I use the bit Set/Reset sequence control.

SeqStep StepCondition StepControl
Step1 PB1 Step2
--] [-----------] [------------+----(S)
|
| Step1
+----(R)


keep all the sequencing together, then later do something like this

Step1 WaitOnOper_LAMP
--] [-------------------------------(S)


If I need to know the step number, I have some small code that equates a SET bit to the number of that SET bit.
Some processors make this easy, some not.

I do like the INT/DINT MOVE style sequencing, but I try to keep a program-style until it proves lacking.

SeqStep StepCondition StepControl
StepCt PB1 GoStep2
--]=[-----------] [----------------[MOV 2 StepCt]
1


StepCt WaitOnOper_LAMP
--]=[---------------------------(S)
1



mk47 If you are really concerned about speed you can use a bit for each step instead of an INT comparison.
Bit controlled sequences may be faster, I've never done a comparison. Nice thought.

As others have said... Find out what your customer wants??
Your customer is the USER/MAINTAINER of your machine - whether you build the machine for your own company or you sell/deliver to another company/department/individual.
If you deliver what they want/need then you have a happy customer -- and likely a repeat customer.
 
Last edited:
Personally, I'm a fan of using state machines with a step number, as others have said.

I typically have an INT that is my CurrentStep. Lots of networks are run conditionally based on comparing CurrentStep to whatever step in the statemachine/sequence is appropriate. Multiple steps may activate any given network, depending on what you are trying to do.

I also have a number of transition networks, that check the current step, and if conditions are met, move to a different step. It is possible that your sequence could branch, meaning that a step could have different transition tests to move to two different steps, depending on what happens. When the transition condition is true, I move the new step number into NextStep. I copy NextStep into CurrentStep at the end of the program, so that only one step executes per program cycle.

If you are really concerned about speed you can use a bit for each step instead of an INT comparison. However, I do recommend still having a number defining the current step number, even if it is just used to set which step bit is true. An INT can only have one value. It is very easy to accidentally have multiple bits set true simultaneously.

+1 to this
 
If platform allows, CASE statement in structured text is good. I define an ENUMERATION for the steps so it's shown in plain text.
Pp


This, and the SFC/Graph mentioned by another poster are both good choices, IF you can use those languagues. I only have one customer that allows anything but LAD, so I never have an opportunity to use more complex (but easier to program) tools.

Also, it is important to note with the CASE statement that it essentially works the same as a jump/goto: it skips the code it doesn't call. This makes a lot of sense to a PC programmer, but to a LAD type guy, this can often cause confusion. If the program turned on an output in section 1, and then moves to section 2 on the next call, it will not automatically turn the bit back off, as a coil would.

I try to avoid jumps, so that I can always execute every line of code. In this way, I can use the output coils my customers are expecting, instead of using logic with a million sets and resets. I find that code reads the smoothest when every tag is only written to in one place (with a few exceptions, like temp variables for intermediate math steps).

There is an upside to skipping unwanted code with the case/jump method. The execution is faster, because it doesn't have to execute the sections for the other steps/states. It is also convenient if you are selecting between different algorithms that use the same tags.
 
Too late to edit post

In effort to maintain the understanding of what I have used for years, I use the bit Set/Reset sequence control.

SeqStep StepCondition StepControl
Step1 PB1 Step2
--] [-----------] [------------+----(S)
|
| Step1
+----(R)


keep all the sequencing together, then later do something like this

Step1 WaitOnOper_LAMP
--] [-------------------------------( ) NOT (S)


If I need to know the step number, I have some small code that equates a SET bit to the number of that SET bit.
Some processors make this easy, some not.

I do like the INT/DINT MOVE style sequencing, but I try to keep a program-style until it proves lacking.

SeqStep StepCondition StepControl
StepCt PB1 GoStep2
--]=[-----------] [----------------[MOV 2 StepCt]
1


StepCt WaitOnOper_LAMP
--]=[---------------------------( ) NOT (S)
1



mk47 If you are really concerned about speed you can use a bit for each step instead of an INT comparison.
Bit controlled sequences may be faster, I've never done a comparison. Nice thought.

As others have said... Find out what your customer wants??
Your customer is the USER/MAINTAINER of your machine - whether you build the machine for your own company or you sell/deliver to another company/department/individual.
If you deliver what they want/need then you have a happy customer -- and likely a repeat customer.


//I wondered why that Lamp would NOT turn off....:eek:
 
I use a sequential groups of bits than I number in '10' increments. I can reset them all easily on a fault and it's fairly easy to track. I also like the integer method although I find it easier to trigger multiple routines if needed using bits.

Always interested to see how everyone else does it though. I'm on the lookout for good ideas to 'borrow' :)
 

Similar Topics

Hi everyone I am very new to PLC programming and need some advice, I am trying to program the MicroLogix to run a test bed for me. The design so...
Replies
3
Views
1,705
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...
Replies
33
Views
9,536
I'm looking for any resource on Sequential Function Chart programing. Books, websites, papers, etc. Thanks for sharing, Siso.
Replies
5
Views
2,580
Hello All, I have a question on how to program a Micrologix 1000. Program is sort of like a pick & place. One sequence follows another. I...
Replies
5
Views
4,790
E
Hi All, Does any one know a method to convert representation of sequential processes (state - transition) into function block diagram to program...
Replies
0
Views
3,985
E
Back
Top Bottom