Control.com - Nerds in Control

Hi there,

I'm really an applications guy / programmer, but do have some experience with PLCs and RTUs.

I may have to get involved with Siemens S7s, and possibly GE Fanuc - does anybody know where I might find some 'grounding' material online regarding these machines?

It is true that they are both horrible (having worked with AB PLCs) or are they ok?

Regards

Mark Wills MSc, MIAP
http://www.markwills.co.uk

Dear Mark,

No PLC systems in this world is horrible if you posses concepts and fundamentals for how to exploit powers hidden in these systems. It seems
as if you have not taken proper approach to understand how to implement / program logics in PLC platform while doing AB systems, due to which
now you are facing lack of confidence dealing with S7 and GE-Fanuc.

Unfortunately you cannot find the ground root info on net and even if you find it somehow it shall not be the right method to acquire that knowledge by just downloading and reading them.

We offer exhaustive training courses of 15 days full time, and it's a guarantee that our trainees are confidently able to do with any PLC system worldwide. We are looking for some franchisees to operate the same level of certified courses in UK, but unfortunately its not yet available.

If you have some contacts / links who might be interested in business venture with us, do let us know on our email id: training.sitek@gmail.com

However, to solve your requirements / queries, we can only suggest you to take this course in our Indian operations.

Regards
Amit
************************************
SITEK Automation & Solutions
Navi Mumbai ( India )
Email : sitek@vsnl.net
***********************************

I can only speak for the S7, yes, it is horrible to find truly understandable English tutorials and examples. You may find that the S7-200 tutorials and examples are far more intuitive than S7-300 examples, as the S7-200 documentation originated in the US. A case and point for the example is to find a truly understandable tutorial for Ethernet messaging from and S7-300 to an S7-200 using the S7-300 Step7, then compare the examples found using the S7-200 MicroWin.

MicroWin beats Step7 hands down. MicroWin was developed in the US

Ian

>I can only speak for the S7, yes, it is horrible to find truly
>understandable English tutorials and examples. You may find that the
>S7-200 tutorials and examples are far more intuitive than S7-300 examples,
>as the S7-200 documentation originated in the US. <

Dear Ian,

I'm a Simatic fan but I never spare criticism to Siemens. Their documentation quality greatly improved from the old S5 times but it is still lacking here and there. It's somehow funny (let's put it on this way, for the sake of blood pressure) to admit that, in some cases, I understood what was written in the manual only *after* I commissioned a device. :-(
And yes, generally speaking, US-made documentation is better that German.

>...<omissis>...
>MicroWin beats Step7 hands down. MicroWin was developed in the US <

you can't compare in this way the two PLC families and related programming environment. Totally different beasts, S7-300/400 is *much* more powerful and flexible.

regards
Luca Gallina

Give these links a try-

http://www2.automation.siemens.com/fea/html_76/down_module.htm

http://www.siemenslinks.com/

If your a programmer, you will love Siemens S7.
There is Ladder, Function Blocks, Graph, Statement list, Continous Function Chart and Structured Control Language (SCL)languages. Keep an open mind and think like a programmer.

"think like a programmer" - No, think like the people who are going to have to use and maintain the machine. Too many PLC programmers think that the more incomprehensible the program they write, the smarter they must be to have written it.

There are by the way two completely different PLC families from Siemens which are both called "S7". There is the S7-200 product line and the S7-300/400. The S7-200 is very "conventional", and if you have worked with any other PLC you shouldn't have much difficulty with it. The S7-300/400 is completely different, and (like its predecessor the S5) can be difficult for someone with only AB experience to understand.

As someone else pointed out, the S7-200 manual is very good. I would recommend it to anyone wishing to learn more about PLCs regardless of whether they will be using the S7-200 or not. It is available as a free download from Siemens.

Dear Michael,

I disagree. We (programmers) *must* think like a programmer, how could it be otherwise? Why should we downgrade our skills and adopt less productive programming techniques just because the maintenance electrician (why don't they hire a maintenance programmer?) does not understand anything but plain ladder? The fact that a whole nest of ladder instructions can be replaced by an handful of STL instruction would be another interesting point to discuss, for many people *believe* that ladder makes everything simple.

If a software needs continuous maintenance, then it was poorly written (blame the programmer). Maybe because the whole machine/plant project was poorly designed and documented from the beginning (in that case, blame the machine's manufacturer or even the customer who did not provide clear specs). Not to mention that, in most of the cases, you get what you pay for and sloppy programmers are cheap.

To the originator of the thread: Personally I found Simatic S7-300/400 very flexible and STL language the most productive (and, despite the detractors, the easiest to comment out). You should anyway evaluate different systems and choose the one that you "feel" the most friendly to operate on. Only in that case you'll be comfortable with your work and do your best. I suspect that the fierce anti-Siemens paladins of A-list, as many others, simply find that's hard to work on a system they don't like (AB vs Siemens = Windows vs UNIX-like = VisualBasic vs C++, the list is long.)

regards
Luca Gallina

Luca,

This is an excellent example of why computer programmers are seen as a breed apart.

You are not "downgrading your skills" to make a product that the maintenance electrician can understand - you are suiting the engineering of the product to the needs of the end-user. This type of thinking is what sees electronic equipment sold with totally inadequate instruction manuals, architects design beautiful houses that no-one can live in, control systems engineers come up with advanced loop configurations that run extremely well at design rates but cannot be started up or shut down...

"Elegant" or "efficient" programming may be very rewarding intellectually to the programmer but can be extremely frustrating to anyone trying to
trouble-shoot a system or make later modifications. And even in a well-designed and -engineered plant there will probably be a need for modifications at some stage. It is much easier to see a contact in a ladder program come on and off when a field switch is made than to find the
equivalent point in a large array.

For use in industrial applications software must be "clear", "concise" and "unambiguous". While advanced programming tools may be able to do a job in one line of code rather than several rungs of ladder or a number of different function blocks, it is doubtful if the result meets this requirement.

Take on the challenge of making your software, in whatever format, easily understood by those who will be referring to it at some stage - it is a lot harder than it seems and is a lot more rewarding than making some sort of "optimum" use of computer resources.

Bruce

Dear Bruce,

>This is an excellent example of why computer programmers are seen as a breed
>apart. <

Should I take it as a compliment or offense? ;-)))

>"Elegant" or "efficient" programming may be very rewarding intellectually to
>the programmer but can be extremely frustrating to anyone trying to
>trouble-shoot a system or make later modifications. And even in a
>well-designed and -engineered plant there will probably be a need for
>modifications at some stage. It is much easier to see a contact in a ladder
>program come on and off when a field switch is made than to find the
>equivalent point in a large array. <

Academical exercises are out of discussion in a production environment. May I pinpoint that "elegant" or "efficient" are quite different from
"academical" or just "intellectually rewarding"?

>For use in industrial applications software must be "clear", "concise" and
>"unambiguous". While advanced programming tools may be able to do a job in
>one line of code rather than several rungs of ladder or a number of
>different function blocks, it is doubtful if the result meets this
>requirement. <

it is doubtful that a nest of ladder code is the panacea for all the automation solutions. But I'm afraid that this is again the old "ladder vs. all" religious issue.

>Take on the challenge of making your software, in whatever format, easily
>understood by those who will be referring to it at some stage - it is a lot
>harder than it seems and is a lot more rewarding than making some sort of
>"optimum" use of computer resources. <

The "optimum" is when you can develop a well organized, stable, flexible, clear and documented software within constraints that are time and budget. Unfortunately time and budget are normally superimposed and not controlled by the programmers. I bet that that's the origin of most of the problems.

Regards,

Luca Gallina

Hi Luca, I have seen on several occasions (both in real industrial activities and in this forum) the attitude that "ladder" is somehow inferior and "inefficient" because for example it does not readily allow array handling. Higher level languages are stated to be far superior because they allow the use of more complex mathematical processing and will result in a programme occupying 9% of the available memory instead of 10%. Similar comments have been used about all the IEC61131 formats, and it is not just an issue with ladder logic.

The same attitude can often be seen in the product of software jockeys who "design" visual displays for HMI's for instance. These will invariable make full use of the available colour spectrum, flash everything that might possibly be flashed, and use every conceivable combination of input. The result impresses the guys with the money but makes the operator's job that much harder.

The difference is between an engineer who uses a software element as part of an overall system to solve a problem, and the prima donna software guru who is not satisfied with the customer's version of their requirements, but insists on interpreting those requirements their own way. In one case I was told that there was no point in making provision to squeeze an extra 200 or so kW out of a gas turbine under extreme conditions when in fact in some possible but unlikely circumstances this would have made the difference between the plant staying on line or having to shut process lines down at considerable expense.

A coherent software engineering approach will make it easier to give an effective result that meets budget and time constraints - not using this approach will make this almost impossible. For industrial applications, the approach needs to include a risk assessment to identify areas where the software engineering needs to be very rigorous - all set out in IEC61508. If a systematic approach is adopted it is also easier to prevent requirements runaway. But too many people working on software systems in industry come from an academic environment where they are not exposed to these issues.

As a very simple example - a moderately complex logic function involving half-a-dozen or so variables can be implemented in its full "sum-of-products" form, or it can be manipulated using Boolean algebra to a minimal realisation. My preference is for the full form as: a) the realisation can be directly compared to the original truth table as part of the verification process b) additions or alterations can be done with minimum disruption on existing operational circuits c) it is quicker

but there are a lot of people who would use Karnaugh mapping or similar in these cases because it results in "simpler" logic.

Cheers, Bruce.

But why should we as programmers, or perhaps technicians thinking as programmers as you suggest, work with software that sucks? If there was some great overwhelming advantage to using Siemens products,for example, I could probably see that view. But as a programmer, and I think I qualify as a programmer, I know that practically anything that can be done with bad tools can be done better and easier with good tools. And the argument about STL doesn't hold water because you can do that with good and pleasant tools as well. Now, there is certainly room for personal preferences and some people simply can't function without a GUI, for example, but there are some examples of automation software that are simply bad. Hard to use, illogically organized, non-intuitive, and counter productive. And that wouldn't be so bad if you could simply choose something else, but there are very few product lines where you have any choice except what the manufacturer in their infinite wisdom provides. And _that_ wouldn't be so bad if you could simply avoid buying their product because their software sucks, but they conduct the rest of their business so that it's all or nothing. It's very difficult to use Koyo in a Siemens house or Siemens in an AB house. Fortunately this vertical model will collapse on itself eventually as it has in general computing. DECs greatest days were after UNIX was ported to their machines. And IBM has saved itself from irrelevance by opening their hardware to Linux and other NIH ideas. But automation, for several reasons, some of which actually do have some merit, will probably be the last bastion of proprietary computing. So even ladder logic, which is pretty much the same across the board will still be done with some very good tools and some unbelievably wretched ones depending on whose hardware you buy. And a choice made decades ago may well bind you to work with wretched tools for the forseeable future. But to say that it's just that I or another programmer simply finds it hard to work with tools we don't like is to imply that we would not know the difference between software that sucks and that which doesn't. And I think that discrimination is a distinguishing characteristic of software craftspeople who _know_ it could be done better. And there are forces at play that will eventually make it possible to pick and choose.

Regards

cww

In reply to Luca Gallina - I think you are misinterpreting my point. My point was not that you shouldn't apply adequate technical skills to writing the program, but rather that you should look at the problem from the point of view of the persons who will be maintaining and operating the machine after you are done.

As I have said many times before, it is very easy to write a complex program. It is on the other hand much more difficult to write a simple one. In my previous reply I said "too many PLC programmers think that the more incomprehensible the program they write, the smarter they must be to have written it". A good program will be simple and obvious to anyone who reads it. The programmer only has to write the program once. Other people will have to read and understand it for years to come.

To say that a program will never have to be read and understood later is to say that the original programmer was flawless and omniscent, and anticipated every possible advance in production process and product design for the life of the machine. This might be desirable, but it seldom happens in practice.

This same point is recognised in conventional computer programming. A good quality computer program must be understandable as well as perform its nominal tasks. One of the leading programming language and operating system developers (I don't recall his name) once said something to the effect that debugging a program is ten times as difficult as writing it. Therefore, if you are writing the program at the limits of your abilities, then you are by definition incapable of debugging it adequately.

I will also say that contrary to your opinion about maintenance electricians, my experience has been that certain individuals in that trade are the ones who seem most enthralled with complex and convoluted programs. They enjoy it as a puzzle to be solved, and they would be happy spending days on end at it. Unfortunately those days on end are often not the most profitable ones for their employers.

Dear Michael,

>In reply to Luca Gallina - I think you are misinterpreting my point. My point
>was not that you shouldn't apply adequate technical skills to writing the
>program, but rather that you should look at the problem from the point of
>view of the persons who will be maintaining and operating the machine after
>you are done. <

a real professional programmer should take care of the operator and maintenance people, as a real manufacturer should provide clear specs and a
real customer should provide clear requirements.

>To say that a program will never have to be read and understood later is to
>say that the original programmer was flawless and omniscent, and anticipated
>every possible advance in production process and product design for the life
>of the machine. <

I never said it.

I would like to pinpoint that so called "advanced" programming techniques can make programs easy to modify at a later time. To achieve such a degree
of flexibility you must own a certain degree of programming knowledge that maintenance people normally has not. And I'm definitely *not* spitting on maintenance people, as I started my career from the very bottom and I shared with them some hard times.

Regards

Luca Gallina

Wow, too bad, I really think Luca has missed the point. Programming in the Automation world is much like being an author of a book. Irrelevant of which tool you use, STL-LD-FBD. Your book MUST be targeted to a specific crowd. Which of course will change with each situation.

Luca fails to understand that unlike in the computer programming world, in automation the maintenance person uses the program to troubleshoot the machine. They see the code generally speaking. And not just for the purpose of troubleshooting the code itself but usually to troubleshoot the system and its hardware.

True, an argument could be made that well written software will enuncuate faults directing maintenance personel appropriately. But I still argue that you cannot possibly take care of all situations. Which it appears Luca thinks he can do. Dream on!!

Also to say that plants should hire programmers instead of electricians is outrageous. Automation is so much more than just a computer running code. It's a convergance of so many technologies, with the PLC programmer playing such a small part.

I would love to see a programmer's face when he finds out the glitch he made just blew out a sub-station, or say sent a 1000hp vector drive to the moon. How about a glitch that sends two robots crashing into each other. What then?

I would also like to object to the thought that troubleshooting is dumbed down. I have seen exceptional programmers crumble under the pressure of trying to fix a problem that eventually gets fixed by a good troubleshooter. And I'll also admit to seeing tradespeople who don't even know which button is used for right clicking on the mouse. There is good 'n bad in all.

I guess in the end what I'm saying is that I think we need to take a more proactive approach and understand that the Automation world is a convergance of technologies, capabilities and personnel. What we should all be aware of is that we are not isolated, only working in a bubble. The end goal must always be uptime and production, 'cause that is what pays the bills

Bottom line here is code that is easier to read and understand, geared to whoever is going to maintain it, is considered well written.

Job security is not convoluted code that only you can troubleshoot, job security is being asked to program the next machine 'cause you did such a great job on the first one.

>Wow, too bad, I really think Luca has missed the point. <

Dear Paul,
that's the view in your eyes. I still feel comfortable with my point.

>Also to say that plants should hire programmers instead of electricians is
>outrageous. Automation is so much more than just a computer running code.
>It's a convergance of so many technologies, with the PLC programmer
>playing such a small part. <

Mmmh... if a water pipe leaks, you call the plumbers, right? If a fuse keeps on blowing up you call in the electrician, right? If your car engine coughs you ask for a mechanic, right? If a program needs to be troubleshot, why don't you want to call a programmer?

>I would love to see a programmer's face when he finds out the glitch he
>made just blew out a sub-station, or say sent a 1000hp vector drive to the
>moon. How about a glitch that sends two robots crashing into each other.
>What then? <

I'm not familiar with (read "never involved in") automation disasters. And your cynical attitude does not help. Just in case, keep cool and investigate the reason why a sub-station blows up and you'll probably find that's not a matter of STL vs. LAD or similar debates...

>I would also like to object to the thought that troubleshooting is dumbed
>down. <

Maybe you feel dumbed down, but I *never* spat on maintenance people and we must agree that today's automation is pretty different from what used to be 15 years ago. Over and again, today's automation needs specialists.

>There is good 'n bad in all. <

Well, so there are good and bad programmers. Why not search for the good ones?

>The end goal must always be uptime and production, 'cause that is what
>pays the bills <

It's a well *designed* application that pays in the long run. Uptime and production may depend on the bill you're willing to pay at the beginning.

>Job security is not convoluted code that only you can troubleshoot, job
>security is being asked to program the next machine 'cause you did such a
>great job on the first one. <

Well, job security is when you succeed in developing programs that don't need to be continuously troubleshot. Convoluted code is unintentional result of poor skills or intentional
product of an evil mind. High level code is just high level code, which is, for example, exactly what you expect to control a plane's avionics. Think at it the next time you fly. ;-)

regards,
Luca Gallina

I haven't found the GE stuff to be horrible, it's pretty good with a few exceptions. Their recent software however, is horrible IMHO, and I'll use LogicMaster on the stuff we've got and simply quit buying GE when I can't. I like VersaPro and friends just about as much as I like Step 7. I'm sure lotsa folks just love these, but I know what I like. Unfortunately the OLD Siemens software is even worse. So I guess GE wins.

Regards
cww

I don't much like GE software, the hardware seems kind of kludgy, and Genius Bus should have been strangled in its crib.

Siemens is a different story, IMHO. It has a good paradigm for writing organized, maintainable, non-spaghetti code, but some things seem to have been made WAY more complicated than they need to be. As far as the basic concept vs. somebody more traditional like AB, I think it's just personal taste.

It's like a friend of mine says about Citect. Complicated, sophisticated stuff is much easier than in competitors' products, but easy, routine stuff is, well, hard.

Microwin compared to s7 is like vb compared to c (or c++). Easy for beginners.

S7 is great, having just had the misfortune of running a project using RSLogix5000 with DeviceNet. I am now comfortably back in the bosom of S7.

Having learned PLC programming about 15 years ago, on Allen-Bradley PLC-2 & PLC-5 systems, using the old DOS program (AB6200), then migrating to Taylor, then RSLogix and also learning Modicon, Moeller and now Siemens (Step7 & MicroWIN), the Siemens software is downright HORRIBLE! It is like the people who designed this software went out of there way to make it as difficult as possible (as with ALL Siemens software).

The AB & Modicon systems are simple, intuitive, and made for the average person to be able to quickly and easily learn and program the equipment.