Why pay for PLC programming software?

[rsdoran]

After reading this post and the answers several times the answer seems to be self evident.

Why pay for software? Its a standard for the technology environment.

Think about it, a computer is an awesome machine BUT you need an OS and application software to do anything.

A computer is a hardware machine which needs and OS...Unix, Linux, BeOS, Windows, Dos etc. To program these OS or apps you need a Programming Language...C, C++, Pascal, Fortran, VB etc etc al.

A PLC is a machine, it must be told what to do. Therefore a Programming Language is needed...no different than a computer (which a plc is in a sense).

Overall we ( the buyers ) do what we have to. IF we own a computer we pay what is asked for the OS (yeah the Linux guys will be stating ours is free...yeah right, time and familiarity is also a determination). We pay for the applications that we need. Technically this is right (even though we may dislike the prices) to pay for what someone has spent the time to develop and market.

I have no choice, my business bought/buys machines with AB products in them therefore I MUST have the software, the same goes for Siemens, AD, GE, and others. If there is a problem I must be able to reload or modify the program.

Many of us arent really concerned about the price actually (except it excludes some of us from obtaining it for personal use). Even with all the bitchin about support, prices etc etc al we have our favorites (personal or company mandated) that we deal with on mostly daily terms and will favor them because of familiarity. Personally none are perfect (i know i aint) so any take getting use to after dealing with another brand specifically.

It boils down to we do what we must.

I gonna state this even tho it may be or seem to be inappropriate because I have a need.

I am in the market for a Scope meter...preferably Fluke 123 or 190 series or similar, 20mhz or higher. I have an abundance of new/used plc's primarily GE Fanuc 90-30 or Siemens s7-200/300, S5 to trade. Please forgive me for this blatant request but I have a need but not the funds to buy new.

 

[Terry Woods]

The original question is...

"Why pay for PLC programming software?"

The immediate answer is simple. If you buy PLC based control systems, you buy PLC programming software (unless you are able to Pirate a copy) just to be able to program the device.

But the question, as posed, is really asking two questions...

1. Why PAY for any PLC Programming Software?
2. Why pay for PLC Programming Software?

Variation #1 suggests that PLC Programming Software can be had for FREE. While you might not have to PAY for PLC Programming Software, you usually get what you pay for!

Functionality? Does it provide all of the functions you need?

Variation? Does it apply to ALL of the PLC's you might need to program? The key-word here is "PLC's". The basic assumption is you are using typical Industry Standard PLC's.

Variation #2 suggests that there is an alternative to "PLC Software". This is TRUE!

Many of us have wished on many occassions that we could get right down into the guts of the PLC's operating system and see what's going on.

The simple answer to that is... you can't!

PLC's are CLOSED!!!

You can do what they will allow... nothing more!

This is reminiscent of the APPLE vs. PC battle. The APPLE architecture has been CLOSED forever! The PC architecture has been OPEN forever (at least, for as long as many of you young pups have been around!).

The very fact that PC's are OPEN makes them THE General purpose Programming and Control tool!

There is a STANDARD Language - "C". This language lets you get down to the very heart of the CPU! I mean, down to the beeding guts!

ALL PLC's ARE PC-Type Micro-Processors! The difference between the PLC-type Micro-Processor and PC-type Micro-Processor is that the PLC-type requires a "Mother, May I?" While the PC-Type says... "Hey, Whatever!"[

Technically, there is ABSOLUTELY NO REASON to prefer PLC-type control over PC-type control!

In fact, Technically, there are a ton of reasons to go with the PC-type control rather than the PLC-type control!

With a PC-type Control system...
You can design your Operator Interfaces as you wish! NO RESTRICTIONS!
You can design your Process Controller as you wish! NO RESTRICTIONS!

The only Caveat is, ]You gotta know what you are doing!

C'MON YOU GUYS !!! We're basically talking about using a Micro-Controller (or Micro-Processor) to control a process!!!

It doesn't matter if the Micro-Controller is in a PLC or a PC. What matters is what kind of control YOU have OVER the Controller!!!
`
A PLC DOES NOT let you have the kind of control you want or need!!!

Any, So-Called, "PLC MODULE" IS a PC-Based Module.

THE PLC is a SUB-SYSTEM OF THE PC !!!!!!

For those that would cry "Hey, this is too much like REAL Programming!", I have no sympathy! This is, after all, the game we are in! Get IN or Get OUT!!!

QUIT YOUR GD WHINING!!!

 

[Rick Densing]

If you design it all yourself, you are still paying for it.

 

[Goody]

<QUIT YOUR GD WHINING!!!>

Dear Terry

I have always respected your opinions and thoughts but I have no idea what you are ranting about here.
To me the question was simple; why should you pay for software that can only program one brand of PLC?
I can see all sides of the argument but in business, the customer is king.
In this case I am the customer, I buy the PLC’s and software.

In my position, (which is different to others), I personally pay for the stuff.
At the end of the year when my accounts are done and the profits are revealed, the profits are all mine. They are not going to be eaten away by me having to pay thousands of pounds for each manufacturer’s software.
I would love to have the software for all brands of PLC. I would try each one out and maybe buy other brands regularly.
The way it is, I am going to stick to one of two brands. (Mitsubishi, Toshiba) and they will get thousands out of me each and every year because I have their programming software.

I had to pay nearly £1000 for the Mitsi software; I had to pick a manufacturer and Mitsubishi won, they being the predominant PLC around these parts.
The price of that software is offset partly by each program I write with the rate or price I charge.
I cannot justify the price of buying new software for other brands when in the main, my customers do not care which brand is controlling their machine to make bricks or treat their cloth or whatever.

But if say, an OMRON rep came to me with an offer that I buy a PLC and he would give me the software free, it is an offer I would take up.
Omron would then maybe sell me lots of PLC’s over the next years.

The Toshiba software, I got free; It was a pirate copy if you like. But Toshiba have benefited because I have bought their PLC’s.
Not many because I prefer Mitsi, but they had their chance.

Other PLC manufacturers would get their chance too if the software was free or at least cheaper.

 

[Steve Meisel]

We recently purchased a machine that came with a Keyence plc in it. I called our Keyence rep and he sent me the software, books, and cable at no charge.

Always a first for anything!

 

[rsdoran]

OK gotta love Terry's tangents. They definitely are informative. Terry you are very experienced, very well educated, and just dang good. We see you thing the PC environment offers more solutions than the plc by itself, I agree with this...to a point.

Why buy plc software...we dont all design, specify or make the machine/device. We buy/use what is needed for access, reloading program, editing etc capabilities.

This question is relative...why use PLC's at all? As Terry has stated a PC can do the same thing and allows you many options to create your own. Why not use a PC, seems the answer to that is simple...not enough know enough to program/edit/modify etc devices controlled with a PC. THere are so many options that its hard for the service/maintenance/electrician/tech to learn them all. This goes back to a statement I have made before...plc's were created to replace relays, the software to program them.

Overall this seems like a DUH to me, pc..plc whatever needs to be programmed somehow. I would like it to be cheaper but you do what you have got to do.

Mr Luft I see you got what you wanted: A long winded debate on WHY...you got it. NOTE tho that just because your company states its has being doing this for many years and you offer free software does NOT mean you have a viable product. If your concepts of marketing are any inclination of Enetron then I doubt your company will ever receive a strong market share.

Phil wanna remove a post that has seen too much action, this would be the one.

 

[Terry Woods]

Goody,

I do tend to think long and hard on my responses, so please excuse the long delay.

Your explanation of your position illustrates exactly the point that I am trying to make.

It seems crazy to me that we, the Programmers and Developers in the control industry, accept the idea that there are 2 dozen or more different PLC's out there with, at least, the same number of PLC Programming Software Packages.

I really hate the idea of an "AB Question" or a "Siemens Question".
Kinda like only being able to use FORD-Tools on Fords and CHEVY-Tools on Chevys - no such thing as a crescent wrench (spanner?).

And then we all get into pi$$ing contests over how my PLC can beat-up your PLC! It's ludicrous! I think your Mitsubishi & Toshiba PLC's are every bit as good as any others! What makes an AB look better than a Mitsubishi? In fact, what makes any PLC look better than any other???

The difference is the PROGRAMMER that wrote the code!

Am I to believe that an AB programmed by an idiot will produce a better control system than a Mitsubishi just because the former is an AB? I think not!

At this late date, all of the major PLC's are essentially the same. The only differences are the secret handshakes, winks and nods that are necessary to get the thing to perform at all. That is, the particular coding methods.

Now, with respect to the coding...
When a PLC compiles, Why does it have to compile? What is a compile?

Why does it have to compile?
The compiling is necessary so that the processor can understand the higher-level language in its own terms - machine code.

What is a compile?
A compile is an exercise where a very low-level program takes a program written in a high-level language and converts it to machine language (machine-code if you prefer). This is NOT to be confused with assembly-language. Assembly language is only ONE level above machine-code. The only thing more hateful than programming in Assembly Language is programming in Machine-Code!

Machine-code is the actual ones-and-zeros that the micro-processor (or micro-controller) in the PLC uses to actually perform work.

When the compiler sees a rung or network, it converts it into a "stackable" set of instructions, value locations and values. That is, it creates a properly ordered list of instructions, value locations and values. That list then resides in a particular place in the program sequence in memory.

During program execution, when it is time to execute that particular rung, the stackable set of instructions and data are loaded onto the "stack". The processor then executes the stack. The first entry is always an instruction. The instruction indicates the function and the operand (next word) or operands (next two words). An operand might indicate a memory location or be a value. The instruction indicates the case.

And so, by executing the instructions in the stack the processor is able to perform the process as we have described.

Now, What the Hell was that all about....????

The point is to show that we are all already performing machine-coding! Even those that only know how to "go in" and change a timer or count value are messing around at the machine-code level!

While there are a couple of differences (Big-Endians vs. Little-Endians - Remember Gulliver's Travels?) between the major processor providers (Intel & Motorola, AMD follows one or the other) they are essentially the same.

Ultimately, we are all accessing the same control system through different filters (PLC Programming Software). And so, when we get into the pi$$ing contest, we are actually arguing that "My filter can beat-up your filter!"

As if, my filter gives me better access to the bleeding-guts of the controller than yours does. It doesn't! For all practical purposes, no filter gives better access than any other!

The difference between the filters, again, is the secret handshakes, winks and nods that are necessary to get the filter to provide "compilable" code for the compiler.

And each set of handshakes, winks and nods are different.

So... where does the concept of standardization come in?

Users of those PLC Systems that have "C-Modules" should be able to port that particular program over to any other PLC that has a "C-Module". However, there is still the filter problem. AB-C ain't quite the same as Mitsu-C. They are not exactly compatable!

I believe that standardization comes in through having ONE LANGUAGE that will "talk" to any of the major processors directly WITHOUT the filters!

So, which language can provide this kind of communication and control?

The "C" Language!

PLC's DO NOT talk STANDARDIZED-C, so that means, blowing off the proprietary PLC programming software provided by AB, Siemens, Misubishi, DL, etc.

One of the greatest things about "C" is that you can create your own functions - re-creations of your favorites or originals!

You can recreate your favorite functions as you wish. If you want to specify a particular data file type, fine, do so. You just have to specify IN THE CODE how it works! This is great for subsequent readers of your code!

Another of the GREATEST things about "C" is that you can speak ENGLISH !!! AS YOU DEFINE IT !!!

"If Part_is_Late_at_Station_A then Execute_Plan_B" <<-- That is a literal command line!!!

So, my vision is, one general purpose language that gets down to the guts of the processor as you need for the very best control and, at the same time, allows access to a plethora of devices and control modules.

So that you, Goody, can maintain ONE software package, knowing that you can access any of your controllers and that you'll have access to a variety of vendors for your control modules. You won't be STUCK with any particular PLC Vendor for programming support (which you can always get right here!) or Hardware! There is a tremendous amount of "generic" type hardware out there.

Now, as to why I sounded like I was in a ranting mode...
I spent some 10+ years working in maintenance. I'm a licensed Electrician. Then I went to college for Electrical Engineering. When I got out of school our local economic situation here was in a down-turn. I wasn't willing to leave the area. I had to go back to manintenance. Since then the economic situation around here has gone up and down severly for the last couple of decades. All the time I've kept trying to learn more about my field.

At this point I have about 20-years maintenance experience with about 10-years of Electrical Engineering/Design experience.

I have a real problem with anyone that come to a "Programming" site and whines that we aren't keeping things dumb enough for a poor ignorant maintenance guy who is not willing to put in the effort to lift himself out of his own self-declared ignorance.

He continues to apologigize for his ignorance and still continues to plead for the PLC-world to be brought down to his level.

He's a self-declared, ignorant, irritating PITA!

That, is who I was directing my rant at!

However, I also believe in the concept of open forum.
So, he is what he is, and I said what I said.
(I typically say what I mean and mean what I say!)

I've run out of patience with him. He can rot.

I've only been able to get away with this because my keepers are away on holiday!

 

[Rick Densing]

It may be a negative for mankind, but by keeping the code/operation simple, we are reducing the costs of ownership for our customers. Something that will may result in another order.
Obviously, this is from an OEM's perspective. I have often suggested more complicated stuff only to be shut down by the customer for the above reason. All that being said, I won't sacrifice the best method to do the job.

 

[Terry Woods]

Before PLC's there was hard-wiring. The maintenance people fought against the PLC idea. It was new and they didn't know how to use it. It took time and effort for the maintenance folks to be convinced of the benefit. They had to learn something new.

So, what is different in what I am suggesting?

It's simply a case of trying to get the control system designers and maintainers (customers) to recognize the benefits of the new idea. Then, as before, they need to learn how to use the new idea!

It's the same game as before! There are benefits to be had if there is an effort to learn!

Let's see, do I want to go through the pains of learning several languages which don't give me direct access to the controller or do I want to learn just one which will give me direct access to the controller?

Do I want to be restricted to a specific hardware vendor or do I want to have access to an unlimited number of hardware vendors who are competing with each other for my money?

These questions are answered in Economics-101.

"It may be a negative for mankind, but by keeping the code/operation simple, we are reducing the costs of ownership for our customers. Something that will may result in another order."

"Simple" is a relative term; Simple for who? A turn-key system is supposed to be simple for the user - Plug-n-Pray, if you will. Such a system requires great effort on the part of the designer.

Obviously, this is from an OEM's perspective. I have often suggested more complicated stuff only to be shut down by the customer for the above reason. All that being said, I won't sacrifice the best method to do the job.

As I said, customers need to be convinced of the benefits. My vision includes providing access and a copy of the source-code with the system. Just as customers now have at least one PLC Software packages to support their own systems, they will need to have a copy of "C" to create and maintain their PC programs.

Whether you like it or not, it is coming! So, why not embrace it?

 

[ganutenator]

my two cents

Wow this is a long thread. It has kind of veered away into a PLC vs PC thread however.

1) 1st of All, Yes, the PLC manufactures are raping you. Why? because they can. Each Manuf. is in essence a monopoly for its own PLC. Yes, you can switch to another manufacturer, but at what expense. There is a serious learning curve to each PLC. Not to mention keeping backup parts for production. Also, compatibility to HMI's, OITs, hardware, etc. I think that most would agree that is very very very difficult, if not nearly impossible to switch a plant over to another PLC manufacturer. Plus, I think most PLC books I read stated "stick with one PLC manufacturer" and with good reason.

What I hate the most about this raping procedure is how you have to buy every little item individually in order to appear competitive to other PLC manufactures. AB is the worst abuser of this. Just give me everything I need, i.e. software, PLC, chassis, power supply, PCMCIA card, AND CABLE, and charge me more for the PLC. This way I don't have to beg/explain to my superiors that I need a $200 cable.


2nd) for the PLC vs PC debate I believe that there are very strong cases for both.

Problems with PLC's :

1) the blasted proprietary stuff
2) not able to create your own functions
3) buying expensive software packages for each and every platform
4) learning curve for each
5) cost cost cost cost; not only hardware, but development as well
6) relay ladder logic
7) portablitily
8) forced into using one software package
- I was able to get arround this a little bit in AB. I could export the code and comments into ASCII and use VIM and Perl to program. This cut my programming time nearly in half, and made me profitable as a programmer. Even though it took me twice as long to write code as my fellow engineers, I was able to finish in half the time. But it was a royal pain in my *** to get this to work.
9) Time, it takes much longer to write PLC code than it does to write the equivalent in another language.
10) code needs a PLC to run. PC programmers have always had the ability to compile test re-compile test re-compilet test etc.
11) Too many bad programers out there. (myself included, however, after 7 years, I am getting better). Every electrician that has ever come along and changed a timer value thinks that they are a programmer.
- sure there are more



Advantages of a PLC:

1) Robust
2) does not run games
3) IT guys don't understand them
4) Does not entirely depend on Microsoft
5) The ability to view/change compiled code online
- try troubleshooting a program poorly written in structured text online.
6) Its not an available PC that someone else will try to come along later and use for an additional purpose.
7) Easier to try and figure out an existing system, some things are constant. A PC based system has an infinite number of combinations.
8) its not a pc



I agree a lot with what Terry has been stating, however, there needs to be some changes in order for the PC based control market to take off.

My "genie pop out of a lamp" Solution:

Imaging a function block diagram that is controlling a process. As an electrician, you easily view this online, and see the inputs and outputs of a particular function block to determine that it is operating properly. The function block may be labeled as Conveyor 154 (East Packaging conveyor) Control for example. By double clicking on the function block you could see the guts of the function block. Up would pop, either ladder logic, or structured text, or C code for example. You could use this function block over and over again. The variables would not all be global, as in the current PLCs. You would have to pass data into and out of the fucntion. But this would make it easier. I.E. you would see a line coming into the function block as I:00/1 or whatever with a comment of HOA-154 Auto. In the code inside of the function block, it would just be Auto. Do you see the potential for duplicating sections of code here, without having to reassign addresses?

2nd, all of this code would run in a Sony Playstation II. I believe the current cost is $200

3rd, the I/O would be ethernet I/O. Pick whatever manuf you want. All manuf. would be forced to be compliant if they ever wanted to sell I/O

4th The HMI would be in VB on a flat touchscreen monitor and connect to the USB port of the playstation.

5th, One of the ports of the ethernet I/O hub would go to a wireless ethernet hub. This way, you could walk right up to the device that you were troubleshooting and be online to the PLC with your laptop. Look ma, no wires.

6th, The HMI would communicate back to a server with all of its data. This data could be broadcast on a web page.

7th, A palm pilot, web ready cell phone, or other web browser could view this HMI data.

....Just my thoughts.......

 

[Ken Roach]

Sigh.

 

[rsdoran]

I have a real problem with anyone that come to a "Programming" site and whines that we aren't keeping things dumb enough for a poor ignorant maintenance guy who is not willing to put in the effort to lift himself out of his own self-declared ignorance.


He continues to apologigize for his ignorance and still continues to plead for the PLC-world to be brought down to his level.

He's a self-declared, ignorant, irritating PITA!

That, is who I was directing my rant at!

However, I also believe in the concept of open forum.
So, he is what he is, and I said what I said.
(I typically say what I mean and mean what I say!)

I've run out of patience with him. He can rot.

Why has a question concerning buying PLC Software become an attack on ME (either personally or as a Maintenance Man in general)? The above is a very egotistical statement, it falls into the category WHY at this time you should "dumb" down (which really means stop thinking like an a$$ and make it understandable). A PLC is a device used in an area where a wide range of expertise/skills are even more important. Most plants dont need a programmer but they do have to hire someone that can understand what that Professional Programmer has done but needs to have more skills.

Dont give me that ego **** about pulling up out of the self declared ignorance...you dont get it do you? Its engineers/programmers etc that create the atmosphere that makes "maintenance men" ignorant. NOTE THO IGNORANCE IS NOT STUPIDITY.

Y'all try to make it sound like its wrong not to KNOW all this stuff. Not all want to be an Engineer, Programmer, or even Management. They just want to be able to comprehend what is being done. As things stand now there are multiple brands of PLC's on the market and still the most common way to do things (overall) is with Ladder Logic. Yes this will change but not the way you may think it will. Yes the PC is a viable alternative, have you developed a system using one? One that anyone could use if they can program?

I am a Maintenance Man, to fulfill the qualifications for my class rating I have to be certified welder, EPA certification for refridgerant recovery, 2 year A.S. degree in electronics, training in pneumatics/hydraulics, PLC training...this just to get an hourly wage job. I have also obtained an MCSE (3.51 track, havent recertified yet), cisco, and numerous pneumatic/hydraulic, drives, plc and business management.

No I am not a Programmer nor an Engineer, as alot of Maintenance Men arent.

Yes I am ignorant but ignorance is relative not always an absolute. It does not signify stupidity or the inability to comprehend when the subject in discussion is done in a fashion that can be related to. Ignorance is also not being willing or capable of looking at something objectively, the "I AM RIGHT .. YOU ARE WRONG ALWAYS" thing.
IF I and those here were truly ignorant then we wouldnt participate at all, I do not write code that often or that indepth BUT I know where to look for a multitude of information on a multitude of brands/devices/software. The idea on a forum (I thought) was to share information and ideas. I have attempted to share what I can.

AS i stated above I dont understand why a Post about BUYING PLC software has turned into a debate about plc vs PC AND an attack towards me (either directly as I think it is or indirectly as a maintenance man). Maybe you could enlighten all of us?

Personally I like reading your long winded debates etc when programming is involved. I ususally print out the whole thread to maintain what code/theory/equations etc you have posted. Your ideas about PC's make sense, but so far you have never shown a hardware method to start it. Ever thought about working with others on an open system to implement a PC design? Ever used a stamp? Designed an I/O board? I have burnt many a 286/386 board working on this stuff.

Yes I am ignorant to certain things but I share what I know and attempt to teach and learn from those around me. I feel sorry for the maintenance men that have to work with or for you, with that god complex I doubt any of them can be more than mindless labor.







Get off your high and mighty ****. You are doing a job working with machines...this aint rocket science.

 

[Rick Densing]

I have a real problem with anyone that come to a "Programming" site and whines that we aren't keeping things dumb enough for a poor ignorant maintenance guy who is not willing to put in the effort to lift himself out of his own self-declared ignorance.

Last I checked, this site was called PLCS.net not PLCPROGRAMMING.net

Like it or not, ignorant maintenance guys (I don't include you Mr. Doran) are part of the world and always will be. Ranting may make you feel good, but it won't change anything.

You also condradict yourself with your own biography. Once you raised your own knowledge level, you became an engineer.

 

[Allen Nelson]

Ron

One thing you must have learned by now about Terry is that his Keepers make sure that he takes his medication. Currently, his keepers are out of town....

When I first read Terry's diatribe, I was puzzled as to who he was complaining about. Although you've had a few post that start with "I'm just a lowly tech....", I've seen others here what are more in favor of "dumbing down the code for the sake of maintenance" than you.

But I don't happen to think that there's anything "only" about being a tech. Most of the ones that I've worked with know more about electrical and mechanical engineering than I am ever likely to, if for no other reason than I sit in a cushy office most days typing, while they're out there looking and fixing.

Terry's wrong about a lot of things (including the REAL original quesiton of this post, which was "Why isn't my business model working to bring zillions of users to get my free software?". I think Stephen Loft got the answer that he should have known all along. Both Charles Darwin and P.T. Barnum were right.

As for the rest of Terry's rant about where PLCs are heading, "'C' is comming"? Maybe. I'm also highly skeptical. Is there any advantage between

    A     B

---| |---( )

and

IF A=1
  THEN B=1
  ELSE B=0
ENDIF

to repressent the desired outcome? I can't figure out where ganutenator (and others) feels that there is something so wrong with Ladder. It's a graphical representation (which must be a good thing, since he advocates flow charts), it's compact ([sidetrack]and don't anyone start on how STL is more compact - in every example I've ever seen, someone takes Siemens ladder, shows how that ladder exists in STL, and shows how much cleaner they can do it in STL by hand. Baloney! That's a flaw in the translator/compiler, not the language. Regardless of the languge, it takes word of raw memory for the instruction, and one word for each address reference. It will also have a few dedicated registers for interim results. Period [/sidetrack])


I figure that there are maybe 20 Basic PLC instructions (if you don't too 61311-3 and say that a MOVE from a float to an integer is different from a MOVE from an integer to an integer - they're both MOVEs as far as I'm concerned.).

I haven't yet reached the depth of all that I can do with those instructions, a bit of indirect addressing (an Array, in 'C' terms), and imagination. Why are more needed?

All the other instructions are typically just "Function Blocks" of those 20, or variations on the theme.

There's also more to running a PC to act like a PLC than just writing some 'C' code that reaches down to the roots of the processor. It still needs an operating system to do the housekeeping (like polling the I/O after every program scan). If it was as easy as Terry makes out, the folks at the Puffin PLC project would have been finished long ago.

I'm not saying that things aren't going to change. Of course they are. And it may even change in some of the ways being predicted.

But again to reference Darwin, things change because there's a pressure to need them changed. As I see it, while htere's some problems with the way things are now, all the proposed solutions are no better.

Take ganutenator's "Put all I/O on ethernet" idea. Sounds good on the surface. But I wouldn't want one bad Level Transmitter take down the entire I/O ethernet network. Or perhaps he means to replace a 16-point I/O module with a 16 point hub? Instead of running 2-wires, we'll run CAT-5? Where's the advantage?

 

[Tom Jenkins]

Thanks Allen - I was waiting for somebody besides me to say it!

I don't know if C will give more compact code than RLL. I don't know if an "open" PLC will really save money. I don't know if distributed I/O is less expensive, or as reliable, or more flexible, or as deterministic. AND I DON'T CARE!

I think many of us loose the real point of applying PLCs - to serve an end users requirements. And the end user isn't paying for elegant code, or compact panels, or the sexiest interface. The end user is paying for plywood, or engine blocks, or clean water at the tap, and so on and so on ......

Since the end user wants to pay as little as possible for these items, the total cost of converting his automation logic into working controls is the final arbiter of the "best" technology at least in a global Darwinian view. And as we have stated many times, total cost includes hardware, and configuration / programming software, and control logic, and installation, and de-bugging, and maintenance, and lost product for errors in any of the above.

I used to do my controls with high level language. (OK, it was DOS and Q-Basic, not Windows and C, but I don't think the differences are significant.) And they worked fine, and my customers were happy. I went to ladder for several reasons, all of which, in my opinion, are as valid today as they were 8-10 years ago when I made the change to PLC:

De-bugging is simpler with ladder logic and most RLL programming packages

Operator interface is improved because a number of suppliers have products optimized for reading and writing to PLCs

Customer acceptance was better, because justified or not they felt a PLC was more robust than an industrial computer and serial I/O

Elimination of a single point of failure. I could use small PLCs for about the same cost as my serial I/O, and by putting protection logic and local control at each one I could maintain equipment functions even if my master control or main PLC died, thereby improving customer uptime.

Maintenance was simpler, since many users had access to somebody that could troubleshoot PLCs but there were few to none that could work with high level languages.

Please note that control hardware cost and initial programming were not critical parts of the decision process. That is because they weren't that different from one architecture to the other, and because they constitute a small percentage of overall system cost.