S7 Sequence Programming Solution ?
- Thread starter Jim.M
- Start date
I have never used Graph , I have S7 pro, so maybe I will give it a go.
I do use ladder.
And if you need want desire have to use ladder in S7 to make a sequence, I might do it this way............
Have each step defined as a FB as you have done.
Then make a DB for each "recepie" or sequence of these FBs.
Have one master FB in which I would control who goes next based on which DB is selected from the HMI.
If I want to use sequence 1, then I load the sequence from DB1 or whatever you like.
In the master the DB information is evaluated and each FB is called in the proper order. A simple --] [-- in front of each FB would control if it is on during this scan.
The master FB could set up to use any sequence defined in the master DB.
If sequence = 1 from HMI, load sequece "1" from Master DB into variables in Master FB.
I may have just repeated what someone else has already said.
I read the other posts first and none of them sounds exactly like this.
Maintenance could see the sequence being called and look in the FB to see the list and order of FBs to be called and each FB would have a true bit in front of it while it was being executed.
Each FB would need a "done" bit to tell the master to enable the next FB.
This might not be the best solution for high speed equipmnt as one scan time would be wasted as the done bit was reported and the next FB was enabled, but it would lock everything into a set sequence and be easy to follow.
Any pause would prevent the done bit and so stop the sequence in place.
Likewise any stop.
Skip would be possible in the master FB. Or even manual overide and leave sequence. Or manualy redefine the sequence from the HMI.
I don't think any of this would be very complex.
I could write the Master FB in a day or so and test for a day or two while adding the HMI screens for the various derivatives.
Maybe a week with HMI and testing and commissioning and in production.
And it would not matter how many steps are in your sequence, and the only limit to the number of sequences would be the size of your master DB.
Make a UDT in the Master DB and add the sequence data to that structure.
I almost want to do this in Lad and then do it in Graph to see the difference just for fun...............but no time.
Good luck.
I do use ladder.
And if you need want desire have to use ladder in S7 to make a sequence, I might do it this way............
Have each step defined as a FB as you have done.
Then make a DB for each "recepie" or sequence of these FBs.
Have one master FB in which I would control who goes next based on which DB is selected from the HMI.
If I want to use sequence 1, then I load the sequence from DB1 or whatever you like.
In the master the DB information is evaluated and each FB is called in the proper order. A simple --] [-- in front of each FB would control if it is on during this scan.
The master FB could set up to use any sequence defined in the master DB.
If sequence = 1 from HMI, load sequece "1" from Master DB into variables in Master FB.
I may have just repeated what someone else has already said.
I read the other posts first and none of them sounds exactly like this.
Maintenance could see the sequence being called and look in the FB to see the list and order of FBs to be called and each FB would have a true bit in front of it while it was being executed.
Each FB would need a "done" bit to tell the master to enable the next FB.
This might not be the best solution for high speed equipmnt as one scan time would be wasted as the done bit was reported and the next FB was enabled, but it would lock everything into a set sequence and be easy to follow.
Any pause would prevent the done bit and so stop the sequence in place.
Likewise any stop.
Skip would be possible in the master FB. Or even manual overide and leave sequence. Or manualy redefine the sequence from the HMI.
I don't think any of this would be very complex.
I could write the Master FB in a day or so and test for a day or two while adding the HMI screens for the various derivatives.
Maybe a week with HMI and testing and commissioning and in production.
And it would not matter how many steps are in your sequence, and the only limit to the number of sequences would be the size of your master DB.
Make a UDT in the Master DB and add the sequence data to that structure.
I almost want to do this in Lad and then do it in Graph to see the difference just for fun...............but no time.
Good luck.
bara_hence
Member
Ok then the integer method gets "dirty" me myself tend to use Set Reset logic quit often when faced with small sequences why?
Often the maintanence personel has a better understanding of the ladder editor.. Sure they should be educated in graph to bu often on my jobs the maintanence staff has so many areas they must have knowledge in so they have sometimes no interest anf some times no time to learn something new..
With this said I think its easier to do sequences in ladder but if one do the Design first with drawing Grafcets and writing wich exeptions we should handle and so on one can make a beutiful implementation in graph but sadly this isnt the case in most cases and a graph implementation gets kludged with jumps inside the sequence, jumps berformed by manupulating on the inputs of the sequence fb and jumps performed outside adressing sequence bits directly... Very hard to troubleshoot..
Often the maintanence personel has a better understanding of the ladder editor.. Sure they should be educated in graph to bu often on my jobs the maintanence staff has so many areas they must have knowledge in so they have sometimes no interest anf some times no time to learn something new..
With this said I think its easier to do sequences in ladder but if one do the Design first with drawing Grafcets and writing wich exeptions we should handle and so on one can make a beutiful implementation in graph but sadly this isnt the case in most cases and a graph implementation gets kludged with jumps inside the sequence, jumps berformed by manupulating on the inputs of the sequence fb and jumps performed outside adressing sequence bits directly... Very hard to troubleshoot..
Normally I will write several state machines for a system (or ideally re-use several and write new ones as required). Each state machine is written as a separate block. Each block will have inputs which must be supplied from other blocks (i.e. run permits or requests) and outputs to other blocks (running, done, faulted etc).
For example, an indexing processing machine with several stations performing identical tasks might have a state machine for each station plus an overall "master" state machine. Each individual station executes its tasks when triggered by the master state machine, perhaps after the index is completed. When each station has completed their tasks (indicated by setting the "done" permit perhaps) then the master state machine will trigger another index. In many cases such a master state machine would not directly control anything, but will serve only to synchronize several sub-sequences when they must run in a co-ordinated fashion.
It is also possible (and sometimes more efficient) to directly connect state machine blocks together without a master sequencer. This applies particularly for two state machines that share a common resource that must not be used simultaneously, such as a pressure transport or pumping station, or for sequences which only have simple relationships (for example, a feeder supplying a batching system).
update
First, anyone who advocates using a bunch of set / reset bits to run a sequence has not had the same experience with this that I have.
Try changing the order of this type of sequence or add a new step to the middle of the sequence when the process changes. It gets ugly quick.
Set / reset are generally reserved for rare situations, and for good reason.
Now in review of my earlier post here.
I have since used Graph and I must say that it is great for state machine, but it is very difficult to do anything complex with. So I tried for a couple weeks to make everything work in the Graph and then realized that the Graph is better suited to keeping the order of things not complex logic.
I then used the Graph to condition the steps and used a bit in each Graph step to call my FBs that ran the complex logic of each step.
It worked well and satisfied the functional spec that required Graph be used to run the machine, but it left me wondering what the real benefit was. The logic was still in Ladder and STL. Writing all the logic in Graph was impossible and just the attempt was painful.
Now in review of my integer method.
The way I would implement the integer method would provide the most flexibility and ease of modification of any method I have used or seen used. I have heard lots of arguments and had to go behind others for years. They all think the way they wrote it is the way it will be forever and if it changes , they are usually not around to do it.
Or they are an integrator who is perpetually behind schedule and has found some spiffy complex way to write code super fast and are only concerned about shipping as much almost working equipment as fast as possible without regard to who has to work with it later.
You know who you are.
Most people make choices based on what is faster, easier, less involved today, while not even acknowledging future modification or troubleshooting as an issue.
I have never written anything that remained in place even before it shipped.
The hardware design rarely goes unaltered, and the customer spec changes weekly.
If you build the exact same machine every week and just hit download for the program, you are a rare case.
I have yet to hear any argument against using integers as steps that makes it worth abandoning, but I will listen to all ideas, because I want to know what works best.
Adding a step in Graph is pretty easy if your not concerned about the step variables being sequential. Just click and insert step with transition.
The step will be called step 1 step 2, 3,4,5,6 etc. Then you add one after step 2 it will be called step 7 but it doesn't matter the order is determined by the order in the Graph, but it still bugs me.
Graph is just not as good for complex logic as it is for controlling a sequence. Graph fails miserably at making even mildly complex decisions with branches. It gets big and hard to see fast.
However, Graph really shines in runtime troubleshooting.
One big graphical picture of the whole process. Just follow the moving green box to see the flow of machine function.
Once, I narrowed down a single prox switch on a complex machine in literally 10 minutes using Graph. It was so easy and fast I was surprised. The maintenance guy I was working with was amazed.
But Graph is something I would only add to a machine if the customer asked for it. Graph adds a layer of extra work and complexity while only adding a small return.
I have not yet encountered a situation where the integer method will not work, or is difficult to follow.
One caution is to remember that if you use the integer method and you disable a FB with the step number or a bit, any outputs addressed solely in that FB could remain on until that FB is called again.
If this might be an issue, then pass the step number as a parameter to the each FB and do the compare inside the block.
So here is the basic structure of my idea.
Write a FB where :
The number of the FB step is an input parameter.
The step to do next is an input parameter.
The step that should follow this step is an output parameter.
(Tell the block which step to write into the step index when the block is done with the "next" input variable. Done equals Next from input goes to Next step output)
The current step is an integer that is passed into the the FB as an input.
Compare previous step to current step to see "if it is my turn to run"
(if "my step" equals "current step" then this FB runs)
Insert you logic here.
When "done" change the step number to the "next step".
Now if we number the steps 10, 20, 30, 40, etc.... we can add 9 additional steps between any current steps with no renumbering of the others. No reasonable edit would require more than that to be added and if you need more then just renumber. If you want them consecutively numbered. But if each step has a step number and an input telling which step to call next, it doesn't matter at all. Step 1 can call step 12 if it needs to , just chance the input for next step.
Jumping is simple. An integer can only be one number at a time, so you can't be in two steps at once , unless you want to and use the same step number on multiple functions.
Make sure you do some housekeeping so each block is properly initialized and leaves in an orderly fashion.
Now if you want to make several sections of the machine similar, copy past the FBs and change the sequence number to suit the desired order of the newly added blocks.
This is the simple 1.2.3 integer method that I used in several situations or 1,5,2,3 if you change the order. But in this method the order of the sequence is fixed during runtime. Each block is called by the previous block and in turn calls the next block.
A derivative method gives each step a static number and a master control that calls the overall order. This works well with processes that use similar steps but may need to change the order frequently.
Make a simple recipe in a DB with the correct order for each situation and look there for which block to call next. The "next" block might not be "current block plus one" and the next block might change depending on the current process or the current conditions.
Process 1 might be 1,2,3,4,5
Process 2 might be 1,4,5
Process 3 might be 1,3,5,2,4
or
When over 70 degrees, call 1,4,5,6
When less than or equal to 70 degrees, call 1,2,3,4,
In a washing machine, sometimes you want an extra rinse cycle or no soak cycle, or an extra rinse, then another spin.
The customer always wants things changed and they think it should only take a few hours.
Most of us have devised methods that fit our specific set of concerns. It is an evolution. My primary concern is solid function in spite of everything conspiring against it. And then I want flexibility and simplicity.
Take any code and imagine what it would be like to add something in the middle or add an extra step after the first step, or to make it follow one sequence in one situation and another sequence in a different situation. If you are doing this exercise with properly configured integer sequence, you focus all your energy on the logic in the added step, not how to add the step or change the order of execution.
And it is easy for anyone to follow after you. They like that.
There are many methods, if your method works for you, use it and add comments so it can work for the next guy.
If I have some time, I will make an example. It is much easier to see in example and looks almost too easy.
First, anyone who advocates using a bunch of set / reset bits to run a sequence has not had the same experience with this that I have.
Try changing the order of this type of sequence or add a new step to the middle of the sequence when the process changes. It gets ugly quick.
Set / reset are generally reserved for rare situations, and for good reason.
Now in review of my earlier post here.
I have since used Graph and I must say that it is great for state machine, but it is very difficult to do anything complex with. So I tried for a couple weeks to make everything work in the Graph and then realized that the Graph is better suited to keeping the order of things not complex logic.
I then used the Graph to condition the steps and used a bit in each Graph step to call my FBs that ran the complex logic of each step.
It worked well and satisfied the functional spec that required Graph be used to run the machine, but it left me wondering what the real benefit was. The logic was still in Ladder and STL. Writing all the logic in Graph was impossible and just the attempt was painful.
Now in review of my integer method.
The way I would implement the integer method would provide the most flexibility and ease of modification of any method I have used or seen used. I have heard lots of arguments and had to go behind others for years. They all think the way they wrote it is the way it will be forever and if it changes , they are usually not around to do it.
Or they are an integrator who is perpetually behind schedule and has found some spiffy complex way to write code super fast and are only concerned about shipping as much almost working equipment as fast as possible without regard to who has to work with it later.
You know who you are.
Most people make choices based on what is faster, easier, less involved today, while not even acknowledging future modification or troubleshooting as an issue.
I have never written anything that remained in place even before it shipped.
The hardware design rarely goes unaltered, and the customer spec changes weekly.
If you build the exact same machine every week and just hit download for the program, you are a rare case.
I have yet to hear any argument against using integers as steps that makes it worth abandoning, but I will listen to all ideas, because I want to know what works best.
Adding a step in Graph is pretty easy if your not concerned about the step variables being sequential. Just click and insert step with transition.
The step will be called step 1 step 2, 3,4,5,6 etc. Then you add one after step 2 it will be called step 7 but it doesn't matter the order is determined by the order in the Graph, but it still bugs me.
Graph is just not as good for complex logic as it is for controlling a sequence. Graph fails miserably at making even mildly complex decisions with branches. It gets big and hard to see fast.
However, Graph really shines in runtime troubleshooting.
One big graphical picture of the whole process. Just follow the moving green box to see the flow of machine function.
Once, I narrowed down a single prox switch on a complex machine in literally 10 minutes using Graph. It was so easy and fast I was surprised. The maintenance guy I was working with was amazed.
But Graph is something I would only add to a machine if the customer asked for it. Graph adds a layer of extra work and complexity while only adding a small return.
I have not yet encountered a situation where the integer method will not work, or is difficult to follow.
One caution is to remember that if you use the integer method and you disable a FB with the step number or a bit, any outputs addressed solely in that FB could remain on until that FB is called again.
If this might be an issue, then pass the step number as a parameter to the each FB and do the compare inside the block.
So here is the basic structure of my idea.
Write a FB where :
The number of the FB step is an input parameter.
The step to do next is an input parameter.
The step that should follow this step is an output parameter.
(Tell the block which step to write into the step index when the block is done with the "next" input variable. Done equals Next from input goes to Next step output)
The current step is an integer that is passed into the the FB as an input.
Compare previous step to current step to see "if it is my turn to run"
(if "my step" equals "current step" then this FB runs)
Insert you logic here.
When "done" change the step number to the "next step".
Now if we number the steps 10, 20, 30, 40, etc.... we can add 9 additional steps between any current steps with no renumbering of the others. No reasonable edit would require more than that to be added and if you need more then just renumber. If you want them consecutively numbered. But if each step has a step number and an input telling which step to call next, it doesn't matter at all. Step 1 can call step 12 if it needs to , just chance the input for next step.
Jumping is simple. An integer can only be one number at a time, so you can't be in two steps at once , unless you want to and use the same step number on multiple functions.
Make sure you do some housekeeping so each block is properly initialized and leaves in an orderly fashion.
Now if you want to make several sections of the machine similar, copy past the FBs and change the sequence number to suit the desired order of the newly added blocks.
This is the simple 1.2.3 integer method that I used in several situations or 1,5,2,3 if you change the order. But in this method the order of the sequence is fixed during runtime. Each block is called by the previous block and in turn calls the next block.
A derivative method gives each step a static number and a master control that calls the overall order. This works well with processes that use similar steps but may need to change the order frequently.
Make a simple recipe in a DB with the correct order for each situation and look there for which block to call next. The "next" block might not be "current block plus one" and the next block might change depending on the current process or the current conditions.
Process 1 might be 1,2,3,4,5
Process 2 might be 1,4,5
Process 3 might be 1,3,5,2,4
or
When over 70 degrees, call 1,4,5,6
When less than or equal to 70 degrees, call 1,2,3,4,
In a washing machine, sometimes you want an extra rinse cycle or no soak cycle, or an extra rinse, then another spin.
The customer always wants things changed and they think it should only take a few hours.
Most of us have devised methods that fit our specific set of concerns. It is an evolution. My primary concern is solid function in spite of everything conspiring against it. And then I want flexibility and simplicity.
Take any code and imagine what it would be like to add something in the middle or add an extra step after the first step, or to make it follow one sequence in one situation and another sequence in a different situation. If you are doing this exercise with properly configured integer sequence, you focus all your energy on the logic in the added step, not how to add the step or change the order of execution.
And it is easy for anyone to follow after you. They like that.
There are many methods, if your method works for you, use it and add comments so it can work for the next guy.
If I have some time, I will make an example. It is much easier to see in example and looks almost too easy.
Always use never as often as possible
"you shouldn’t use integers to control a sequencer, it does not ensure a complete scan of the program whilst changing steps, and if you were here it would be audited and rejected."
No, this is why YOU shouldn't use integers to control a sequence.
12
What step am I in? Which logic block is running now? The one with a 12 on it?
What other steps are active? Only the ones with a 12.
When I change steps do I need to reset or clear anything? No.Just change the value of one integer.
What if I want a manual function to step through the sequence? or just hold it in one step? Write that number to the integer, either online or with an HMI manual entry.
What if the order changes? Change the go next number or use a list.
What if I want to add a step? Go ahead , add it, update one list in one place or change the go next number on the previous block.
Why does it have to be inverted?
Integers can also be inverted. Where is the advantage of using set reset??
If you were somewhere else all those sets and resets would get you audited and rejected.
Step 3 , next step is step 4
Step 2 , next step is step 3
Step 1 is for faulted stop, no faults? next step is step 2
Step 0 all stop everything ok, next step is step 1
Some people run to set /reset as a crutch, it feels like a good idea at the time, but it has issues and is clunky. (Uses a lot of bits and is resistant to future edits.)
I imagine you want the bit to remain set to hold your step position until it is reset, and then some done bit sets the next steps set bit.
That even sounds hard. Bunch of bits, bunch of places to make a mistake, and you have to be paranoid about clearing all those bits and conditioning each bit to be exclusive. Step 1 and not step 2 and not step 3 and not step 4, just in case someone goes online and sets one of your bits by accident.
And or , if in Step X reset all other set bits. And reset them all if in stop.
I agree,Jump is way more efficient than either of these and saves processor time.
Some people have trouble following Jumps and labels, and I would be concerned about outputs getting left on while that section of code was jumped.
It really boils down to a couple things.
Is there enough code to slow the PLC so much that the machine performance suffers? If yes, then you have to look at Jump and Label to save processor time.
Will the code never be changed? And do you want to make it difficult for anyone to add a step later? Do you like typing a lot of symbol names for bits?Then use set / reset for every step but make sure you keep the order on the page right and make sure all the other steps are excluded.
Will the code be changed, ever? Will the order ever change? Does the order change while running the process? Will anything be added? Is the scan time reasonable? Do you want to be sure only one step is executed at a time even in spite of someones efforts online? (you can use the same step number for several steps to have them happen together if you like)
And the big one , will you be the one to make changes in the future?
Then I would use an integer step index and or a step list in a DB.
I see an integer as something that has 32768 (positive integers including zero)different states and each one is explicitly exclusive of the others. Integers are also easy for any human to see and understand.
PLCs are not PCs, a good fundamental rule in one system may not apply in the other. PC programmers have their own set of issues that are valid in their instruction set. Many of them I have worked with have had trouble understanding the strength of the PLC over the PC and of course the limits that are the trade off.
If it works for you, use it, but imagine being the next guy and go look at some old code that has been hacked up in the field when changes were made.
We don't always get the feedback of seeing our code 10 years later.
"you shouldn’t use integers to control a sequencer, it does not ensure a complete scan of the program whilst changing steps, and if you were here it would be audited and rejected."
No, this is why YOU shouldn't use integers to control a sequence.
12
What step am I in? Which logic block is running now? The one with a 12 on it?
What other steps are active? Only the ones with a 12.
When I change steps do I need to reset or clear anything? No.Just change the value of one integer.
What if I want a manual function to step through the sequence? or just hold it in one step? Write that number to the integer, either online or with an HMI manual entry.
What if the order changes? Change the go next number or use a list.
What if I want to add a step? Go ahead , add it, update one list in one place or change the go next number on the previous block.
Why does it have to be inverted?
Integers can also be inverted. Where is the advantage of using set reset??
If you were somewhere else all those sets and resets would get you audited and rejected.
Step 3 , next step is step 4
Step 2 , next step is step 3
Step 1 is for faulted stop, no faults? next step is step 2
Step 0 all stop everything ok, next step is step 1
Some people run to set /reset as a crutch, it feels like a good idea at the time, but it has issues and is clunky. (Uses a lot of bits and is resistant to future edits.)
I imagine you want the bit to remain set to hold your step position until it is reset, and then some done bit sets the next steps set bit.
That even sounds hard. Bunch of bits, bunch of places to make a mistake, and you have to be paranoid about clearing all those bits and conditioning each bit to be exclusive. Step 1 and not step 2 and not step 3 and not step 4, just in case someone goes online and sets one of your bits by accident.
And or , if in Step X reset all other set bits. And reset them all if in stop.
I agree,Jump is way more efficient than either of these and saves processor time.
Some people have trouble following Jumps and labels, and I would be concerned about outputs getting left on while that section of code was jumped.
It really boils down to a couple things.
Is there enough code to slow the PLC so much that the machine performance suffers? If yes, then you have to look at Jump and Label to save processor time.
Will the code never be changed? And do you want to make it difficult for anyone to add a step later? Do you like typing a lot of symbol names for bits?Then use set / reset for every step but make sure you keep the order on the page right and make sure all the other steps are excluded.
Will the code be changed, ever? Will the order ever change? Does the order change while running the process? Will anything be added? Is the scan time reasonable? Do you want to be sure only one step is executed at a time even in spite of someones efforts online? (you can use the same step number for several steps to have them happen together if you like)
And the big one , will you be the one to make changes in the future?
Then I would use an integer step index and or a step list in a DB.
I see an integer as something that has 32768 (positive integers including zero)different states and each one is explicitly exclusive of the others. Integers are also easy for any human to see and understand.
PLCs are not PCs, a good fundamental rule in one system may not apply in the other. PC programmers have their own set of issues that are valid in their instruction set. Many of them I have worked with have had trouble understanding the strength of the PLC over the PC and of course the limits that are the trade off.
If it works for you, use it, but imagine being the next guy and go look at some old code that has been hacked up in the field when changes were made.
We don't always get the feedback of seeing our code 10 years later.
Peter Nachtwey
Member
I recommend using the JL instruction which is the STL version of a CASE or SWITCH statement. It is very efficient. Each case element is a state or step. In search step there may be three parts. The first part checks to see if the the current state is the same as the old state. If not the execute the code that that would occur on a rising edge. The second part is the code that gets execute while in this state. Sometimes this state doesn't exist. The third part checks for exit conditions and is what IEC 61131-3 SFC calls the transition. Most of the time the state machine will go the next state so the current state can be simply incremented but some times one may have to skip a state or or set the state to an error or recovery state. In these cases the current state will be assigned the next state.
This method is what I saw Siemens engineers use when I was working with them when we worked together on injection and blow molding machines.
There is ONE advantage to using bits. If you look at a SFC you can see that a SFC task can actually have two parallel branches running on the same graph. This is not possible if you use integers but there is an work around. You can start up another state machine to handle the parallel branch.
Using the JL instruction do implement a jump table almost eliminates the need for one shots. The need for Set and Reset go down because one task can always look at what state another task is in but this has its own dangers because the task numbers must be kept straight whereas a bit can be assigned to indicate when something is done and it doesn't need to change if more states are added or removed.
The JL instructions is one of the best features of the S7 and I would use it on any machine sequencing I would do if I didn't have SCL.
This method is what I saw Siemens engineers use when I was working with them when we worked together on injection and blow molding machines.
There is ONE advantage to using bits. If you look at a SFC you can see that a SFC task can actually have two parallel branches running on the same graph. This is not possible if you use integers but there is an work around. You can start up another state machine to handle the parallel branch.
Using the JL instruction do implement a jump table almost eliminates the need for one shots. The need for Set and Reset go down because one task can always look at what state another task is in but this has its own dangers because the task numbers must be kept straight whereas a bit can be assigned to indicate when something is done and it doesn't need to change if more states are added or removed.
The JL instructions is one of the best features of the S7 and I would use it on any machine sequencing I would do if I didn't have SCL.
I love hearing new ideas, if I had more time I would try them all.
I always enjoy reading your posts Peter. I like hearing other views and I try to benefit from others experience as I imagine how to implement their ideas.
However,
"This is not possible if you use integers but there is an work around. You can start up another state machine to handle the parallel branch."
I think one would have to agree that JL is the best solution from a processor speed point of view.
Graph has its points but is very limiting and I could only get it to do the basic step chores and still had to use FBs elsewhere for all the real logic, so I didn't understand the real need for the extra layer of adding Graph.
I have heard several people say integers wont do parallel branches and I just can't understand how anyone would think this.
I must begin by saying that there is no parallel in PLCs, ever. It is a long list of If Then Else. PLCs can't do real parallel and neither can older PCs. "Parallel" is generally "OR".
But the idea of seemingly parallel branches can be implemented in integer stepping by simply using the same index number on several sections of code.
Then the sections that equal "12" will all run in sequence from top to bottom as if they were actually in the same section.
If you look at the JL method, only the sections of code that are jumped into execute.
Good and bad from my perspective.
Good for execution time and all the things you love about it. Plus Seimens engineers use it, so there is that element majesty.
Bad is the fact that you have to be careful not leave any condition true when you leave the section and jump out or that element will remain on until that section is jumped into again. This could be exploited as a clever "set bit" scheme but few people could follow it late at night in the back corner of the plant while trying to figure out why the machine isn't running. Someone making a small edit might also be surprised that the new edit seems to have caused a lot of new issues.
I have met and had the privilege of discussing code with some very advanced programmers. I was in awe of the shear creative ingenuity of these people.
And then I had to interface their software on a project. After weeks of time digging through lines of code full of STL loops and jumps I discovered that a lot of it didn't work. And that was the part I had to fix before I could begin writing my part.
If it had all worked I would never have learned so much and I would never have known just how clever these guys are. But if it had worked it would have been more impressive.
It was so complex, they could not fix it and were always too busy to send a working version with examples. Any edit they made to fix one thing caused another issue and they seemed reluctant to actually test anything before declaring it functional.
It was a requirement that this "base code" be used in all projects, so there was no option of just doing it some other way.
And while I am still impressed with everything they did, and very glad to have had the experience, I am also glad that I don't aspire to that level of complexity. I could have written solid simple code to do everything that they did just using the time it took to figure out what they had done and why it didn't work.
There was a negative time savings. The whole thing was supposed to save time, but the reality is quite the opposite.
Their customers complain about the code , their own software people can't follow it, it requires weeks to edit before it works and there is no documentation because they are too busy.
My point is this:
If I can't follow it, chances are the guy after me wont have an easy time of it either.
Then there is the possibility of abandoned coils remaining on in jumped over sections of code. Bits can be modified later, or even turned on while troubleshooting online.
The JL does not address these issues without lots of housekeeping.
If I have a speed issue, I use Jump.
If I have a huge amount of code and only pieces of it are needed in each step, I would see the advantage of Jump.
If "steps" 4, 5 and 6 need to be run at the same time or in parallel, then activate each step with the same step index.
My integer method asks "which step number activates this section of code?"
and at the end you have some acknowledgement that each section of code is completed, or "DONE".
For a parallel branch to close, you would need to make sure that the DONE of each branch was "OR"ed together to move to the next section.
A List could do this by turning on several steps at once and then moving forward when any of the sections was "done" or waiting for all the sections to be "done" depending on whether you want them all "Or"ed or "AND"ed together. A list makes it easy to change the order later or change recipes on the fly.
"OR" : Begin all 3 sections at the same time but move to the next step when the first of the 3 was done.
"AND" : Begin all 3 sections at the same time (not sequentially) and then wait for them all to be done before moving to the next step.
Integer method also allows all the coils in the unused sections of code to turn off when not true and thus no extra housekeeping is needed.
It is possible that my idea of the integer method is not the same as other peoples implementation of the integer method.
I have not had an issue that was not easily resolved. And None of it is difficult to follow in concept or at runtime while troubleshooting. And those are the reasons I stick to it.
It is solid, simple, easily modified, flexible and easy to follow, even by a beginner.
I always enjoy reading your posts Peter. I like hearing other views and I try to benefit from others experience as I imagine how to implement their ideas.
However,
"This is not possible if you use integers but there is an work around. You can start up another state machine to handle the parallel branch."
I think one would have to agree that JL is the best solution from a processor speed point of view.
Graph has its points but is very limiting and I could only get it to do the basic step chores and still had to use FBs elsewhere for all the real logic, so I didn't understand the real need for the extra layer of adding Graph.
I have heard several people say integers wont do parallel branches and I just can't understand how anyone would think this.
I must begin by saying that there is no parallel in PLCs, ever. It is a long list of If Then Else. PLCs can't do real parallel and neither can older PCs. "Parallel" is generally "OR".
But the idea of seemingly parallel branches can be implemented in integer stepping by simply using the same index number on several sections of code.
Then the sections that equal "12" will all run in sequence from top to bottom as if they were actually in the same section.
If you look at the JL method, only the sections of code that are jumped into execute.
Good and bad from my perspective.
Good for execution time and all the things you love about it. Plus Seimens engineers use it, so there is that element majesty.
Bad is the fact that you have to be careful not leave any condition true when you leave the section and jump out or that element will remain on until that section is jumped into again. This could be exploited as a clever "set bit" scheme but few people could follow it late at night in the back corner of the plant while trying to figure out why the machine isn't running. Someone making a small edit might also be surprised that the new edit seems to have caused a lot of new issues.
I have met and had the privilege of discussing code with some very advanced programmers. I was in awe of the shear creative ingenuity of these people.
And then I had to interface their software on a project. After weeks of time digging through lines of code full of STL loops and jumps I discovered that a lot of it didn't work. And that was the part I had to fix before I could begin writing my part.
If it had all worked I would never have learned so much and I would never have known just how clever these guys are. But if it had worked it would have been more impressive.
It was so complex, they could not fix it and were always too busy to send a working version with examples. Any edit they made to fix one thing caused another issue and they seemed reluctant to actually test anything before declaring it functional.
It was a requirement that this "base code" be used in all projects, so there was no option of just doing it some other way.
And while I am still impressed with everything they did, and very glad to have had the experience, I am also glad that I don't aspire to that level of complexity. I could have written solid simple code to do everything that they did just using the time it took to figure out what they had done and why it didn't work.
There was a negative time savings. The whole thing was supposed to save time, but the reality is quite the opposite.
Their customers complain about the code , their own software people can't follow it, it requires weeks to edit before it works and there is no documentation because they are too busy.
My point is this:
If I can't follow it, chances are the guy after me wont have an easy time of it either.
Then there is the possibility of abandoned coils remaining on in jumped over sections of code. Bits can be modified later, or even turned on while troubleshooting online.
The JL does not address these issues without lots of housekeeping.
If I have a speed issue, I use Jump.
If I have a huge amount of code and only pieces of it are needed in each step, I would see the advantage of Jump.
If "steps" 4, 5 and 6 need to be run at the same time or in parallel, then activate each step with the same step index.
My integer method asks "which step number activates this section of code?"
and at the end you have some acknowledgement that each section of code is completed, or "DONE".
For a parallel branch to close, you would need to make sure that the DONE of each branch was "OR"ed together to move to the next section.
A List could do this by turning on several steps at once and then moving forward when any of the sections was "done" or waiting for all the sections to be "done" depending on whether you want them all "Or"ed or "AND"ed together. A list makes it easy to change the order later or change recipes on the fly.
"OR" : Begin all 3 sections at the same time but move to the next step when the first of the 3 was done.
"AND" : Begin all 3 sections at the same time (not sequentially) and then wait for them all to be done before moving to the next step.
Integer method also allows all the coils in the unused sections of code to turn off when not true and thus no extra housekeeping is needed.
It is possible that my idea of the integer method is not the same as other peoples implementation of the integer method.
I have not had an issue that was not easily resolved. And None of it is difficult to follow in concept or at runtime while troubleshooting. And those are the reasons I stick to it.
It is solid, simple, easily modified, flexible and easy to follow, even by a beginner.
Examples
These are in response to a PM I received.
I don't see how to put a file in the download area on PLCS.net
And this way the example is right here with the discussion.
I wrote this in Step7 5.5 and ran it on PLCSIM 5.4 SP5
It works.
Simple.
Easy to follow.
Easy to modify.
Lots of comments.
This is not overly clever or tricky, nor does it use any special tricks. The same ideas work in all PLCs I have used.
Please feel free to give any feedback, this is a base idea not a full blown program, but it would run a basic process with a couple steps.
"Integer1" runs a simple program with a timer in each step just to slow it down so you can watch the steps go through.
"Integer2" is a similar program , but with one of the steps relocated from the second position down to the end of OB1. Still works the same, doesn't matter what order you put the steps in or if you add a new step in the middle or at the end. I would put them in order of execution to make them easy to find, but the point is they don't have to be in order to run correctly.
The first rungs before the FBs must remain in place, the logic for the steps can be moved around.
The FBs are examples of the minimum interface parameters, you can add what ever you like to run your logic. I used FBs because I also use the STAT area in FBs as local variables instead of using the memory map where appropriate. It makes the blocks more portable when inserting into another program.
I also like passing ANY pointers into blocks on occasion and FCs work differently than FBs in this case.
Feel free to use these as you like.
They work as I intend for them to and I added a couple of bits of safety checks and a pause and a manual mode, but it is up to you to make it safe. These are only examples. Run this in the Simulator in order to understand my method, but DO NOT put these in a production machine.
I feel better now having said that.
These are in response to a PM I received.
I don't see how to put a file in the download area on PLCS.net
And this way the example is right here with the discussion.
I wrote this in Step7 5.5 and ran it on PLCSIM 5.4 SP5
It works.
Simple.
Easy to follow.
Easy to modify.
Lots of comments.
This is not overly clever or tricky, nor does it use any special tricks. The same ideas work in all PLCs I have used.
Please feel free to give any feedback, this is a base idea not a full blown program, but it would run a basic process with a couple steps.
"Integer1" runs a simple program with a timer in each step just to slow it down so you can watch the steps go through.
"Integer2" is a similar program , but with one of the steps relocated from the second position down to the end of OB1. Still works the same, doesn't matter what order you put the steps in or if you add a new step in the middle or at the end. I would put them in order of execution to make them easy to find, but the point is they don't have to be in order to run correctly.
The first rungs before the FBs must remain in place, the logic for the steps can be moved around.
The FBs are examples of the minimum interface parameters, you can add what ever you like to run your logic. I used FBs because I also use the STAT area in FBs as local variables instead of using the memory map where appropriate. It makes the blocks more portable when inserting into another program.
I also like passing ANY pointers into blocks on occasion and FCs work differently than FBs in this case.
Feel free to use these as you like.
They work as I intend for them to and I added a couple of bits of safety checks and a pause and a manual mode, but it is up to you to make it safe. These are only examples. Run this in the Simulator in order to understand my method, but DO NOT put these in a production machine.
I feel better now having said that.
Peter Nachtwey
Member
That is the main advantage.
One can take the shot gun approach and clear all the bits in the state machine instead of just clearing the current state bit before setting the next state bit.
Back in the dark ages ( early 1980s ) we used state bits but would convert them to a integer using a conversion to a float and using the exponent then we jumped using an instruction similar to the JL instruction.
I understand
That is only because it doesn't use real labels like a CASE statement.
Multiple compare and jumps is not as fast but it works.
I wouldn't do it that way. If there is only one step that needs to be run in parallel then I would just combine them into one step. However, if after step 3 there are 2 parallel tasks and they are asynchronous then I would have a task 4a and task 4b. Each of these would have its own JL with the greater task 4. This means there could be a task 4a1, 4a2,4a3 and task 4b1, 4b2.
not quite. Just remember that you can have multiple sub states within a state if you want in STL or SCL.
Thanks for the feedback
dahnuguy : If "steps" 4, 5 and 6 need to be run at the same time or in parallel, then activate each step with the same step index.
Peters response:
"I wouldn't do it that way. If there is only one step that needs to be run in parallel then I would just combine them into one step.
dahnuguy: I agree if you have a couple total states just write it in one , but I would like to maintain individual functions as separate steps or states and combine them if necessary in different sequences for different recipes. Can't combine 1 and 4 and then run 1 and not 4 or switch to 1 and 6 in parallel. And what if I have one recipe with 5 parallel steps and a second recipe that uses 2 of those and 3 different steps in parallel? and another that uses the same steps in parallel but needs them ORed and another that wants them ANDed?
I see this method as extremely flexible, but it only makes sense after a certain point of complexity. I imagine a machine with over 100 states or different functions that can be re-ordered, modified, added to easily or re-ordered at runtime and still be simple and easy to follow.
Peter: "However, if after step 3 there are 2 parallel tasks and they are asynchronous then I would have a task 4a and task 4b. Each of these would have its own JL with the greater task 4. This means there could be a task 4a1, 4a2,4a3 and task 4b1, 4b2."
dahnuguy: I don't think we are doing much different, except your un-called code isn't running, and mine is. Pros and cons have been addressed.
I see flexibility with simplicity, and I don't currently know what tasks might need to be in parallel later. New recipes might need new combinations. The examples I uploaded do not use the recipe list, these examples are a simple version, but it is still applicable.You are using 4a and 4b, its just a label.
I am using integers so the same thing. The steps could be Step 4 and SubSteps 41, 42, 43 or 401, 402, 403. In my example it doesn't matter what numbers you use. It doesn't need to be consecutive or in any order. I am using an integer as 32,787 possible states that are all exclusive and easy to call and and easy to hold in any state. Any one step can call any other step.
Quote: It is possible that my idea of the integer method is not the same as other peoples implementation of the integer method.
Peter:not quite. Just remember that you can have multiple sub states within a state if you want in STL or SCL.
dahnuguy: I have never seen my version of integer control used by anyone else. This is why I think so many people dislike the integer method.
There may be lots of people doing the same thing as me, I just haven't seen it.
Most people increment the index to next number and do the next section of code and then have trouble adding new steps between existing steps. Or they skip integers and add 10 to the index. The order of execution does not need to be linked to the numerical order of the integers.
1 What index number allows this block to execute?
2 What index number does this block write into the index when it is done?
I haven't seen anybody do that.
I can have multiple substates within a state in Ladder as well. Did you mean substates are exclusive to STL and SCL?
I am no expert with STL or SCL, I may be missing something here.
As always, I enjoy reading what others think about these ideas. I have no trouble acknowledging that JL is functionally the better method, for speed and performance, but I don't think it is the simplest or easiest to modify or follow online for troubleshooting. And for me those count for a lot.
Processor speed isn't as much of an issue as once was, ease of use and modification are always concerns of mine.
dahnuguy : If "steps" 4, 5 and 6 need to be run at the same time or in parallel, then activate each step with the same step index.
Peters response:
"I wouldn't do it that way. If there is only one step that needs to be run in parallel then I would just combine them into one step.
dahnuguy: I agree if you have a couple total states just write it in one , but I would like to maintain individual functions as separate steps or states and combine them if necessary in different sequences for different recipes. Can't combine 1 and 4 and then run 1 and not 4 or switch to 1 and 6 in parallel. And what if I have one recipe with 5 parallel steps and a second recipe that uses 2 of those and 3 different steps in parallel? and another that uses the same steps in parallel but needs them ORed and another that wants them ANDed?
I see this method as extremely flexible, but it only makes sense after a certain point of complexity. I imagine a machine with over 100 states or different functions that can be re-ordered, modified, added to easily or re-ordered at runtime and still be simple and easy to follow.
Peter: "However, if after step 3 there are 2 parallel tasks and they are asynchronous then I would have a task 4a and task 4b. Each of these would have its own JL with the greater task 4. This means there could be a task 4a1, 4a2,4a3 and task 4b1, 4b2."
dahnuguy: I don't think we are doing much different, except your un-called code isn't running, and mine is. Pros and cons have been addressed.
I see flexibility with simplicity, and I don't currently know what tasks might need to be in parallel later. New recipes might need new combinations. The examples I uploaded do not use the recipe list, these examples are a simple version, but it is still applicable.You are using 4a and 4b, its just a label.
I am using integers so the same thing. The steps could be Step 4 and SubSteps 41, 42, 43 or 401, 402, 403. In my example it doesn't matter what numbers you use. It doesn't need to be consecutive or in any order. I am using an integer as 32,787 possible states that are all exclusive and easy to call and and easy to hold in any state. Any one step can call any other step.
Quote: It is possible that my idea of the integer method is not the same as other peoples implementation of the integer method.
Peter:not quite. Just remember that you can have multiple sub states within a state if you want in STL or SCL.
dahnuguy: I have never seen my version of integer control used by anyone else. This is why I think so many people dislike the integer method.
There may be lots of people doing the same thing as me, I just haven't seen it.
Most people increment the index to next number and do the next section of code and then have trouble adding new steps between existing steps. Or they skip integers and add 10 to the index. The order of execution does not need to be linked to the numerical order of the integers.
1 What index number allows this block to execute?
2 What index number does this block write into the index when it is done?
I haven't seen anybody do that.
I can have multiple substates within a state in Ladder as well. Did you mean substates are exclusive to STL and SCL?
I am no expert with STL or SCL, I may be missing something here.
As always, I enjoy reading what others think about these ideas. I have no trouble acknowledging that JL is functionally the better method, for speed and performance, but I don't think it is the simplest or easiest to modify or follow online for troubleshooting. And for me those count for a lot.
Processor speed isn't as much of an issue as once was, ease of use and modification are always concerns of mine.
Last edited:
TurpoUrpo
Lifetime Supporting Member
Please, USE QUOTES. Its awful to read if not used.
It wasn't that awful.
I started with quotes and something went amiss and didn't work right in the preview, so I left it and used names with spaces after.
Similar Topics
Hello,
i have a machine with 3 axis that can run simultaneously controlled by other software but sometimes this goes wrong due operator fault.
So...
Hello,
I am trying to make a sequence program by using MOV function to change the value of a register. So far I have always used SET and RSET for...
I am taking my first attempt at modifying a program on our little bottling machine.
We need to automate a sequence to purge the tank on the...
hello all experts.
i'd like to know your experiences about sequence programming.
i use positive or negative edge detection(|p|or |n| elements)...
hello i am currently working on my program. i have some problem where i need some guidance.
i have a question where when i do the next network...
