S7 Sequence Programming Solution ?

[TurpoUrpo]

Yes it was, my eyes hurt trying to read it.

 

[rage44]

I analized Your example. As You wrote, it's realy clean and ease to use. I think this will be my way to make sequence. Thank You very much. It is always good to learn from someone more experienced.

 

[Andrew Hardy]

I use an integer step number for each sequence. I set an 'increment' bit when I am on step n and the conditions are true to move onto step n + 1, Once incremented I reset the bit. When the final step in the sequence is true, I reset the step number.

I then use range comparators on the integer step number to set flags to request outputs to energise.

Advantages:
1. Finished code is clean and easily readable by others
2. Step numbers relate directly to the FDS - you *have* got one these? - just checking
3. Mods to the sequence are simple
4. This method can be used on any PLC. This is a biggy for me as I have to get my head round S7, RSLogix, GX Developer and CX One.

But first and foremost comes the FDS - get this right and the rest will be easy.

 

[dahnuguy]

INT or set rst, not both, well I would not use set /reset ever,if possible

I use an integer step number for each sequence. I set an 'increment' bit when I am on step n and the conditions are true to move onto step n + 1, Once incremented I reset the bit. When the final step in the sequence is true, I reset the step number.

I then use range comparators on the integer step number to set flags to request outputs to energise.

Advantages:
1. Finished code is clean and easily readable by others
2. Step numbers relate directly to the FDS - you *have* got one these? - just checking
3. Mods to the sequence are simple
4. This method can be used on any PLC.

Advantages:
1. Finished code is clean and easily readable by others
Check

2. Step numbers relate directly to the FDS - you *have* got one these? - just checking
I can use ANY number for current step and next step, doesn't even have to be consecutive. 1,2,3,453,67,99,100,34,4,5,6,7,899.....

3. Mods to the sequence are simple
Two constants per step, less than a minute.

4. This method can be used on any PLC.
Replace the FBs in S7 with subroutines or just put it all in the main, still works the same and in any order, just doesn't look as neat as the S7 version.

If I transfered my S7 example to AB it would have a series of subroutines called from the main instead of FBs, but everything else would be the same.(I have recently done this on a simple machine with a SLC500)

Your method is a strict "Step , then Step N+1" system. Not knocking it, just identifying it.

You are using the set / reset to stop the run through after you change the integer.
Just update the integer at the top of the scan and eliminate all the set bits. Each step moves a new integer index number into a "preindex", once a scan , at the top, in the main, move the "preindex" to the index. No more run through. If the move is conditioned you get a pause or hold with built in manual mode.

Fewer bits, easier to follow, easier to alter later.


For me, half the point of using an Integer step index is to avoid the set / reset dance for every step. Not add to it. You could use set / reset without the integer.

Modifying my sequence involved editing 2 constants per FB to be altered.
It took a minute to change the entire sequence and save it to ZIP for the second example.

A real minute, 60 seconds, edited, saved and archived.

I could alter my Integer sequence several times an hour,
or even use variables and change it all during runtime, through the HMI,
or even write a bit of code that chooses the sequence dynamically by recipe, max flexible. Or let it be fixed and never change it, and use the same base code for another project.

I have manual mode and pause and stop and reset all built in the first couple lines of code. Very little overhead or housekeeping.

I don't see any way to make it better without adding complexity.

The only thing that would make it better is to use JL............and that would make it NOT integer method.

 

[KalleOlsen]

I use nearly the same step-technique as you do, only putting the whole schmutz into one FB. And I gave up the S/R bits looong time ago.
***

A comment to JL.
I think you could (but neither say you should, nor that it is better

) use it with your integer 'random' numbering aswell. Look here at this simple example:

Kalle

 

[Andrew Hardy]

I'll have a play with this next time I write a sequence. I guess I use an increment bit from the days when setting a bit was 1 byte whereas moving a constant was 4 bytes and this could be significant - not so relevant any more now that PLCs generally have decent amounts of memory and are reasonably quick

 

[dahnuguy]

reasonably quick

I'll have a play with this next time I write a sequence. I guess I use an increment bit from the days when setting a bit was 1 byte whereas moving a constant was 4 bytes and this could be significant - not so relevant any more now that PLCs generally have decent amounts of memory and are reasonably quick

I have learned that a lot of things that are done now have their roots in some hardware limit from 30 years ago.

Even 10 years ago no one would read and write to DBs unless they really needed to. I do it now just to keep code portable and to make data easier to move around. I use the STAT area in FBs instead of M bits, then it all gets setup automatically when you define a new instance DB for the FB in a new program or a new instance in the same program. Old S5 coders will see this as slower, and want to use all M bits everywhere and take a day to rename all those bits when they re-use the block, even though they are now using a new S7 / 400 processor.

I like to debate the issues to get to the root of it. If A is really an advantage over B or if it is just personal preference.

When someone says A is better, I want to find out why.

If they say B is better because "I like it better", then that's that. I still want to know what it is they like about it though.

Often I am taken as argumentative, but I am just passionately curious.

I think you will enjoy leaving those sets behind and it wont cost you any functionality.

 

[dahnuguy]

I think you could (but neither say you should, nor that it is better

I use nearly the same step-technique as you do, only putting the whole schmutz into one FB. And I gave up the S/R bits looong time ago.
***

A comment to JL.
I think you could (but neither say you should, nor that it is better

) use it with your integer 'random' numbering aswell. Look here at this simple example:

Kalle

It can all go in one big FB, the only draw back is one less nest level in your other FBs. And if the machine is basically a list of steps, why wrap them all up in another FB?

I still like having the step control and housekeeping in the main. I feel better knowing that these couple of lines will always execute.

But if you like it and it works for you, there is no reason not to.

As for your Integer / JL example. It's really a JL example, with an integer being used to pick the jump. Nice idea, but it also inherits the parts of JL I don't like.

On-line, while looking at some code it might not be obvious that a portion of code isn't even running. It is also a bit more difficult to tell what section IS running when your not in that section.

These are issues that cause some people to get lost when troubleshooting.

I like having the step index there in every step, visible. So someone looking in step 4 can see that step 4 is not currently active and in fact that the current step is actually step 12. The logic is active, but the rung is false.

You don't have that if the code is skipped. Likewise one must resist the urge to condition the whole step FB or it will cause the same issues of leaving outputs trapped as some other methods.

I just think it is easier to follow for most non programmers.

Once you introduce JL and or set/ reset bits in steps, you are no longer using what I consider a simple integer index method.

I don't see anyway to improve it without making it more complex and or losing some functionality.

I am still looking for ways to improve it though.

Thanks for your input.

 

[dahnuguy]

Least I be branded a set / reset hater

I would like to add that I have used set / reset in the past,

"As I recall it was on a Tuesday........"

I reset an output, then followed this with 20ish lines of code with conditions that would set the same output, thus breaking the multiple coil out rule that many hold dear.

One of the 20 lines had to be on to energize the coil and every scan the coil was first reset.

This prevented a bunch of place holder bits that then would have to be OR'ed together with the coil at the end.

This was not Siemens, but I probably could have done the same thing with some form of jump.

The reset , then set was simple in that case and it worked and was easy to follow.

I don't think set should never be used, but I do save it for those times that it really adds something.

 

[Peter Nachtwey]

I don't think set should never be used, but I do save it for those times that it really adds something.

SET is useful when there needs to be some hand shaking between two asynchronous tasks. Task 1 SETs a bit to signal some event. Task 2 is waiting for the bit and when it is set Task 2 continues doing something but also clears or RSTs the bit two acknowledge the transaction.

One or both tasks could have a timeout associated with the bit. Task 1 could also start a timer when the bit is SET. If the timer times out before the bit is RST then there is a problem with task 2.

The same goes for task 2. Task 2 can start a timer as soon as it starts waiting for the bit to be set. If the timer times out before the bit is set then there is something wrong with task 1.

If both cases a index to an error message table can be set that indicates exactly what the error is. This makes trouble shooting easy.