Sequential Function Chart

Hello guys (meaning both genders )
Just as a little aside, what is the kind of demand for this type of programming language. Is this something that is 'on the way out', or is it becoming more necessary to learn these days.
Any input would be welcomed.
Thanks

Oh dear, I can just smell the fresh worms from this new can you've opened!

"Sequential Function Charts, a language? Discuss"

Well, although the IEC61131-3 standard started out with 5 languages, one of which was SFCs, you'll find that current thinking tends to classify it not as a unique language, but simply as "a methodology for structuring the other languages". It depends greatly on how the SFC has been implemented by each software vendor, but in most cases the statements you use in the Steps, and the way of expressing the requirements of the Transitions, will be done using Instruction List, Ladder, or Function Block Diagram. I have seen SFCs written with literally only one statement: 'call'. The SFC did not perform any executive control over the memory or I/O. It was simply used as a procedural controller to ensure that the correct FC or FB got called at the appropriate point in the sequence of events in the machine or process. This actually provided a very visual and easy tops-down diagnostic assistance if things stopped behaving as normal. On the other hand, I've also seen SFCs full of jumps, gotos etc and watching one of them at work was like watching twinkling Christmas lights on a tree!

I don't know whether there's a growth in demand for it or not. Maybe you need to get a critical mass of people using it before it starts to influence outsiders greatly. Overall I'd say it was still a minority interest. But that's not to say the minority are wrong.

regards

Ken.

I think it depends on the project really. In my current project I have 21 (almost) identical modules which have to be set up (if selected) through the same sequence of steps. If it were only one module it would be no problem in ladder or STL (or FBL etc. for that matter), but when you get to 21 of them which while identical in structure, are all one off prototypes, which means things like switching and charging times are all different and still need to be synchronised with one another at various stages of the process, so things get more complicated.

The first point is, that when I'm finished with this project, some other poor sod is going to have to maintain it. And this system is going to a research institute where one and a half years into a two and a half year project, the guys who are going to be using it are still coming up with new ideas and that will only accelerate once they get their hands on their new toy. So my poor successor is probably also going to have to extensively modify things.

Now the actual control is pretty simple as such, but if you write it in STL you have the choice of either writing one big long bunch of spaghetti, or doing it half way neatly with multiple loops and sub-routine calls. But I have no idea of how competent this guy is going to be (never mind having a say in who it's going to be). You can comment the stuff till you're blue in the face, but there will always be something where the other person just won't understand what you mean. Don't tell me you've never written what you believed to be a well-commented program, only to come back to it a couple of years later (or six months, for that matter) and find yourself saying, "Now what the heck did I mean by that!

Just to make life even more interesting, I don't even work for the supplying company - they have other, extremely project relevant experience to contribute, but they don't have any PLC people. So they're not interested in return business. In fact they are praying that when it goes out the door, they are never going to hear from the customer again.

So as a result I've done as much as possible of the program in S7-GRAPH, in particular for the set-up and shut down phases. That way you have a nice graphical overview of the 21 parallel paths that come down to common synchronisation points in various places, you can see at a glance where everything is at any particular time and it should be relatively easy for even a pretty inexperienced guy to take it on.

Modifications are easily made by changing the first parallel path and then cutting and pasting the changes to the rest, before modifying the addresses. Sure, it's cost the customer about 700€ more, but he's already saved that in my time alone, because I was able to do the program much quicker and since this project is budgeted at over 100+ M€, that is really peanuts!

Just to conclude, the other place where SFCs are very useful is in Batch processes, as in Chemical Plants etc. In the end, it's horses for courses, but sometimes the course is a little bit different than you might think at first glance.

Hope this has given you something to think about,

Cheers

Roy

I don't think SFC is 'on the way out'. However, its not a universal answer either. I suggest you at least look into it to see if it provides some benefit to you. Just make sure you evaluate it from the right perspective. See if SFC fits your process. Don't try to make your process fit SFC. The 'Christmas tree light' reference from Ken M (good one, by the way) is an example of trying to shoehorn a process that is not strictly sequencial into an SFC format.
I think Ken's critical mass comment is correct also. Many organizations don't want to get into something different due to training issues. Since SFC doesn't bring anything to the table outside of programming convenience and some troubleshooting aid (but only if done correctly) many organizations will steer clear of it. That alone will keep useage down.
I would definitely use it but it would need to be the right situation.

Keith

I've been thinking of learning SFC. My main question in the back of my head is, What happens if you interrupt the sequence? Do you have to be back to the beginning? Can you start up where you left off?

In particular, My interest is in organized start up and shut down sequences.

SFC is great for motion control applications

Most motion control applications are best implemented in a state machine. The SFC provides an easy and VISUAL way to implement a state machine. We get too many tech support calls from people that can't properly implement a state machine in ladder. SFC with ST or FBD is very good for motion apps. Of course, polling the inputs is best done in LD.

Greetings to all,

I’m not trying to recommend this SFC thing ... I don’t like it ... but a lot of people don’t know that RSLogix5 “right out of the box” supports the Allen-Bradley flavor of Sequential Function Chart programming ... so if you just want to tinker around with it, there is usually (assuming that you used the default installation routine) a demo program located in your “SAMPLES” directory ...

note: RSLogix500 does not support SFC or STX programming ...

[attachment]

this is just a quick screen shot of a couple of the smaller files ...

PS ... a demo of Allen-Bradley’s flavor of STX (Structured Text) programming is in the same file ... and incidentally, I don’t like it either ...

Ron

Oh dear, what did SFC or Strucured Text ever do to you?

I tend to think of all these language choices like different tools in my box. Sure you can probably put screws in with a small chisel, or use pliers for the nuts instead of a spanner but sometimes it's good to have the right things to hand. As the old saying goes "When the only tool you've got is a hammer, every problem starts to look like a nail." The main thing is - let the task to be performed determine the tool to be used, and not the other way around.

I was involved peripherally in some vision control (geddit!) a while ago working with clear unlabelled glass bottles, trying to make sure they were turned the right way round (yeah, I know, don't ask). The maths we had to do on the data coming to the PLC from the cameras would have been terrifying in Ladder or Statement list. Thank God for Structured Text that time is all I can say. Equally, SFCs would have been useless in that application.

Regards

Ken.

and we had to walk through the SNOW to get there ...

don’t get me started, Ken ... I’m the kind of guy who still thinks that DOS will eventually come back into style ...

seriously though ... if I’d ever had an actual NEED for it, then I’m sure that I could force myself to “do what I had to do” with either SFC or STX ... I look at it this way: EVERY type of computer programming always boils down to just “ones” and “zeros” when you get right down to the basics ... so how complicated can it possibly get? ... anyway ... so far, that “I-really-need-something-more-powerful-than-ladder-logic” day just hasn’t dawned for me ... again I say - so far ...

and on a totally unrelated topic that just came to mind ... I can vividly remember an article in my high school science book (somewhere around 1962) describing those “newfangled” computer things ... it said something like:

“It will never be possible to build a computer complicated enough to (for example) play chess. But if a computer that advanced COULD be built, then it would have to be as big as the Empire State Building in order to hold all of the vacuum tubes that would be required to switch the signals.”

Click to expand...

I’m 57 years old now ... I still can’t believe some of the things that I work on every day ...

(Quote
“It will never be possible to build a computer complicated enough to (for example) play chess. But if a computer that advanced COULD be built, then it would have to be as big as the Empire State Building in order to hold all of the vacuum tubes that would be required to switch the signals.”

Click to expand...

I remember that and IBM Deep Blue proved that wrong:
http://www.research.ibm.com/deepblue/home/html/b.html

I had a teacher tell me in the 60's that digital communications would never be possible either. All the things I have seen created amaze me.

DOS will eventually come back into style

Click to expand...

NO Thank you.

Ron,

I've just realised where my thinking may be at odds with yours. You said -

...computer programming always boils down to just “ones” and “zeros”...

Click to expand...

and you're possibly right. The 'programming' itself maybe be no more than 101000100000111 ...., but where I think these other languages give me an advantage is in the 'design' of what I'm trying to do. Conceptually, I don't work well in 1s and 0s. Oh, all right, I don't work well with 1s and 0s at all! Well-ordered textual descriptions of what's happening help immeasurably, and pictures are even better. Now it just so happens that these nice kind PLC manufacturers have given us not just editors for these other languages but, what do you know, they do the programming (the generation of the 1s and 0s) for me as well! OK, they may not do it as well or economically as you would do it but for me they're a lot quicker. And if I've got my design just a little bit more accurate as a result of using SFC or ST then the price to be paid is maybe worth it.

Hmmm, anybody still using machine code out there? What's your views on all this new language stuff?

Ken.

SFC's are great!

But they're not a panacea.

Once you get a handle on where and when they can be useful, you will wonder why you delayed in getting acquainted.

One of the problems with general acceptance is the initial implementation by A-B on the "classic" PLC5's. Many keen and eager people tried it out and got burned. The 5/250 implementation wasn't much better. By the time A-B came out with a really useful implementation on the the "new platform" PLC5's, people had been scared off. (But not me)

The CLX implementation is very similar to the NP PLC5 except it uses Structured Text rather than Ladder for actions and transitions.

I've tried the A-B variety on a test bed processor. I like the idea of it but, since online editing isn't possible, I can't use it.

How come even when I'm on holiday I can't stop having a look to see what's going on.

anybody still using machine code out there?

Click to expand...

You bet, I still get dragged in occasionally to have a look at the last 3 of 17 Kent K90's that I installed for Bayer in Brunsbüttel in 1980 - 81. (There are only two of us left who know what to do with these dinosaurs.) These, like many other systems at that time use the DEC PDP11 CPU. For quickly checking out things to localise the area of a fault, there's nothing better. Apart from that, you can do some things in machine code that the assembler won't let you do, for example using the same memory location once as data and then as an instruction.

The PDP8 and earlier PDP11s were particularly nice, because they had a switch for each bit immediately under the register display LEDs - using both hands and multiple fingers you could hammer a program in far faster than with the later decimal keypad. I used to regularly write little test programs of up to several hundred lines, it was quicker and easier than assembler for me.

Cheers

Roy

using both hands and multiple fingers you could hammer a program in far faster than with the later decimal keypad

Click to expand...

You are truly in need of help

... I actually know someone with a PDP-something in his basement. He used to work at DEC and is the consumate programming computer nerd...sounds like you're in the club also (the above is meant as awe insprired admiration for those who have "the knowledge" when it comes to the 1's and 0's. I took an assembler class in college and while fun and interesting, was enough to get me to learn Pascal, Basic, C and other stuff)

viva la binarie