Control.com - Nerds in Control

My question is simple, but the answer escapes me. To all you devoted Allen Bradley people and to everyone else who uses PLCs, why do you pay for their programming software?

For AB to charge $1100 - $1200 for programming software, then on top of that, some people have told me that they charge a yearly upgrade/license fee blows my mind at how many people pay these fees. Then there is Automation Direct that charges for OEM licenses and little things like manuals. They are starting to remind me of banks...charging for every little thing.

A question that has been on my mind for some time. Curious to see what some of your answers are.

I agree completely, but I have no choice.

My company would never use PLCs, but for marketing reasons we have to. I find it particularly gauling that A-B charges so much for its software.

Consider a company using all Modicon PLCs. A-B comes in and says "our PLCs are better!" The idea of switching hardware is appealing and the company wants to do it and has the money for it. But they can't! Because they can't afford the software cost in addition to the hardward costs. If A-B gave them the software when they bought A-B PLCs, the company has an incentive to switch to A-B. Instead, A-B creates a DISINCENTIVE to move to their hardware.

On the flip side, I have an incentive now to STAY with A-B now that I've got so much invested in the software. Perhaps they feel that locking people in once they get them is more beneficial to the bottom line than attractive people in the first place.

The software shouldn't be a revenue stream. I'm certainly okay paying for technical support and some nominal fee for the software (a hundred bucks, maybe?). But paying thousands per copy per year is quite painful.

This is true of every other manufacturer as well. We would be much more willing to look at other PLC vendors if their software were free (or priced reasonably.) I actually like AutomationDirect.com's pricing, and I'm okay paying for manuals (it's nominal).

-James Ingraham
Sage Automation, Inc.

James

I am dismayed at your thinking here. It costs considerably more to develop good software than it does automation hardware. In representing Schneider Electric and our programming software, perhaps you would prefer us to add this cost to the price of the hardware?

I am sure you would not go for this suggestion. Like it or not, automation company's are evolving into software vendors..... This is the facilitator for what hardware is able to do. Without it hardware is inate.

We are all in business and consumers in the majority now accept that software is a piece of the automation solution. My suggestion....Get with the program and understand the value of the tool that is now esential to an automation system

Best regards

Lee J Ward
Schneider Automation

Lee, you haven't addressed my fundamental point; no plant that isn't currently using your products can EVER switch to them. It doesn't matter if the hardware is completely free; the cost of replacing the current software with your software is prohibitively expensive. With even one piece of equipment in my plant, I have to have dozens of copies of the software for all of the engineers and maintenance people who might possibly need to look at it.

This business model can kill companies. Do you really think it's a smart marketing move to place a huge barrier to adopting your products?

-James Inrgaham

Yes software is expensive, and yes once you select your flavor you are basicly locked into the system due to capitol investment costs. Changing a system to another is not a value added or money returning investment. It is only an essential reliablity investment in the worst cases.

The best thing going for PLCs is the wide body of knowledge in support. There are integrators in almost every city who develop in ladder, function blocks, and SFCs. Bottom line, Ladder is efficient for the technician to work in and understand just like an electrical schematic.

Look at PLC 5 1771 I/O, It's still available and has been since the 80s. SLC 500 since the 90s, try and find a 286 passive backplane CPU today. (Remember when the programmer would count clock cycles to build his timing, and never provide C code for that boat anchor sitting in your warehouse?)

Today you could retrofit a junky old PC based dinosour with a sercos card, a kinetix drive, and a few lines of ladder. We are talking coordinated motion easily from a PLC. Nice stuff comes with some cost, let's face it, none of us work for free, and if they wanted me to, then I'd go broke at home and let their machines gather rust.

Yes it costs a lot for hardware, but have you checked the price of tooling? 100 dollars worth of metal can cost 1500 after being machined on a CNC. Just remember everything is worth what the market will bear, and if machinery purchases become cost prohibitive due to cost of hardware then people won't buy. That would drop the cost over time, or they would go out of buisness, which would allow you to justify change out on obsolescence costs... Just my 2 cents.

Mike Roberson
Manager/Controls Engineer/Maunfacturing and operations whipping boy/ *insert derogatory comment here*

I did a small project that required several small PLCs. 32 I/O x 5. I looked around and found this.

Mitsubishi gave me their DOS based software for free. The small brick PLC cost me 450 USD ea for 32 I/O. The cable was 120 USD.

The AB software was 1500 USD and the cable was 150 USD and the PLCs were 1250 USD ea!!!

So I used Mitsubishi. Finished the project and delivered it. Wish I could have used a Linux PC to write the code.

Then the customer says it has to be AB hardware and software at their plant!!

So I said good luck with that. I'll redo it if you want to pay for both ...AND THEY DID!!

So I have 5 cool little PLCs at home! With software and supporting hardware. I even reordered all new cabinets and relays and din rails and
power supplies and kept all the old stuff!

So you see, the big Co. just can't see the point.

I have heard about an open source project that programs several PLCs from one GUI and downloads and uploads to several different hardware types. If it was ever true I bet AB squashed it like a bug.

Make a quality product at a reasonable price and I'll pay it and be happy.

I have only bought one copy of windows, and I regret that.

If you want me to buy it, it has to work and be reasonable.

Lee,

Allen-Bradley is a very smart company. They come
out with a new set of cards that can be accessed only on a new Software. They lure u into using this new set of cards & then unleash the real thing.
They suggested us to go in for NT8 module in place of NT4 (2 nos. used in our system) under
guise of cost-reduction. Once we got down to
actual engg., we were told to go in for RS-Logix
because "NT8 works only with it". Whereas we have been using APS since long. We refused.

Rgds,
goh

Hi,

- New hardware features usually needs new software, and I think that point is easy to understand. moreover, PLCs like CLX offer amazing possibilities with newest software that you can use with 'OLD' hardware just updating its firmware, obviously you make the decision and you decide if you need/want these new features or you prefer to stay with the performance you bought some years ago.

- Why should I pay for NEW software? usually you don't have to pay the WHOLE new software, PLC companies offer you software support plans that at a lower cost maintains your software updating you with the latest versions. Once again you have the decision of taking profit of these newer versions or staying with your initial investment.

- Why use Logix (Windows based software) instead of APS (MS-DOS based software)?

1) Try Logix, you'll FEEL the diference...
2) Will Microsoft O.S. keep on supporting MS-DOS based programs in the future? will computer manufacturers keep on producing compatible hardware with MS-DOS (note that most of the newest laptops have completely replaced RS-232 serial ports with USB ports)... so will your computer last forever?

- Why pay for newest software? why we pay for newest PLCs? why did we put the first PLC in our plant? I think the answer is our competitors are producing better and faster, 'cause they invest, otherwise we would keep on working with rely logics.

Your atitude towards a potential customer is apalling. I wonder if your tech support staff will treat me like that. The attitude that a customer should "get with the program" is not a good business strategy. This goes right along with gouging your customers by charging outrageous prices for software that could hardly be considered a high quality piece of programming.
I am just learning to program PLCs and I have never used your software or hardware, and your attitude has guaranteed that neither I nor any of my professional contacts buy your products. To stress this point, I am friends with the part owner of a large automation company here in PA. He is the reason I am learning PLC and motion control. His company has built projects for companies all over the united states.

> James
>
> I am dismayed at your thinking here. It costs considerably more to develop good software than it does automation hardware. In representing Schneider Electric and our programming software, perhaps you would prefer us to add this cost to the price of the hardware? <

I am forced to use your Concept software, and it is certainly overpriced. I'm amazed at so many shortcomings in this software, and am flabbergasted that it is unable to view variables and binaries at the same time. Please don't brag about a product that cost so much to develop, but is still such an inferior product.

I understand it is expensive to develop software, and I've been biting the bullet for years over the cost to interface. I agree this cost has to be passed along, and it would be impossible to do this on the hardware end. This would skyrocket costs. It would be nice though to see a lower cost.

It's like the old adage, "I'm proud to be a tax paying American, but I'd be even more proud to pay half as much if those good old boys in charge could be more efficient."

> I am sure you would not go for this suggestion. Like it or not, automation company's are evolving into software vendors..... This is the facilitator for what hardware is able to do. Without it hardware is inate.
>
> We are all in business and consumers in the majority now accept that software is a piece of the automation solution. My suggestion....Get with the program and understand the value of the tool that is now esential to an automation system <

Please! Modicon needs to get with the program.

So this subject has got most of you riled up now for the past 3 years. Never would I have realized the passion on both sides of the fence. I am glad that many of you have come to realize that Industrial Software for Automation development has evolved into the commodity I predicted back then, and, an all be it uneven calm has ensued. The fact remains.... Programming Software is a tool just like any other tool that has to be purchased in order to do a job. The cost associated with such a job is relative. You pay $5 for a hammer to knock in a 10c nail. Conversely, you can pay $5k for a software tool that will make a multi-million dollar plant run. Typically the development of a PLC or Automation programming tool in todays environment costs between $1m and $15m and all vendors are looking for ROI. It is what it is.... The cost of doing business!

Lee J Ward
Rockwell Automation

Sorry Lee, but there is a big difference between a hammer that costs $5 and software that costs $1300+. And the hammer will work with any nail. Not just the ones made by the company that made the hammer.

I'm learning PLC programming in my off time, buying hardware off e-bay and companys that charge reasonable prices for thier hardware. Of course I'm not a company with a lot of mony to spend and its tough to get a good deal on the software.

Also, the company i work for is getting away from AB for new installations and using other brands when the old AB hardware needs to be replaced. This has everything to do with cost.

They'ere using Siemens, but I'm making some of the automation guys aware of Tealware and TOPDOC from the SoftPLC Corporation. The cost is 25% to 35% less than AB and this is quality stuff. It also runs on Windows AND linux so the programmer can work on his/her platform of choice.

AB produces quality products and thats what I'm learning with at home because of the install base. Perhaps Rockwell could open up some of those specs so the open source community could take a crack at some programming tools. That would be ideal for someone like me whos just learning and experimenting at home.

Thanks,

Mike

It's interesting, I heard all the same arguments from the people who sold million dollar computers to SMBs. And yes, it was probably worth it to get your payroll done between Fridays. But, no one would even think of paying millions for that anymore. Where are the minicomputer class guys for this market? They'll be along. Huge infrastructures were built and staffed and everyone thought that was what you had to have. All were swept away when commodity computing came along. And it's hard to even think of doing things the old way. This market is loaded with functionally identical products with redundant infrastructure and the only diversity is at the bottom. Who do you think stands the best chance of surviving? Once the bubble bursts in what smells like and walks like
a commodity market, the exodus will begin. All the same arguments could be used to justify selling PCs for 10 or 20 thousand dollars. But a cold comparison between PLCs and some $20 embedded controllers is not flattering to the big automation vendors. If solution providers could (would?) use either, I think the towers would collapse. It's already possible to do the same job with solutions that differ in cost by a ratio of 10 to 1. Reality has a way of flattening differences like that. Let's ponder how the high end can persist.

Regards

cww

Wow. I'll try to restrain myself since you are new to PLCs, but you completely don't understand AB (RA) at all. Every group at RA is a profit center. That includes the software group as well as support. Even the local "Drive Center" which is suppose to be there to help, but ends up just trying to steal you customers (from us integrators anyway), because they need to show a profit too.

Let me make this as clear as I know how. RA/AB does not want you to buy anything but RA/AB stuff. Case in point, they took a world-wide open protocol, SERCOS, and "closed it" to just work with their servo drives.

If you ever come across anything open-source for AB, it won't be from AB.

As for software $, I'm more in the middle. It does seem over priced, but one has to realize the effort it takes to write, test, and improve such applications. Also keep in mind the liability of producing "safe" software. If your email program crashes you don't break a machine or worse, hurt somebody. I know AB has considerable QC procedures.

I've never used A-D, so how's the built-in diagnostics in the programming software? The millisecond-update trending in RSLogix5000 is the best troubleshooting tool I've ever seen. Not that RSLogix5k is perfect by any standard, but the trending alone can be worth the $5k pricetag.

This is so so true!!

Basically RA have 2 faces, and they can both be ugly. Even while there are a few good people there, their customer service is in effect, distributor integrator, stockist, etc. and it does not pay for you to give them any information.

I must point out though their products are top drawer, and there are inexpensive products in the range, ML 1100 on ethernet with a web server €360 cable €40 and prog sware €400.

Keep up the Oviscating,

Liability? Every user license I've ever read for software places the liability on the user and no fault can be be placed or implied on IDE software.

In fact a lot of software costs appear to be lawyer fees in writing the user license in such a way as to absolve them of all liabilities.

Beckhoff Incorporates a diagnostic tool in there software called Twincat Scopeview. It has a configurable update rate down to 1ms. You can also set up an I/O task and link it directly to your scope and even trigger a pre-configured scope to start recording automatically within your PLC logic. Very handy.

The problem with both is that they only work with one brand. And bear in mind you can get a Mixed signal scope with a 16 channel logic analyzer and two analog channels with 512k samples memory depth and 400MSamples/sec for about $600 and use it on anything. And you can believe what it tells you. Makes big bucks for a one trick pony seem like kind of a waste. A DSO with flexible triggering and deep memory makes a really good time machine for what happened before the once every two week failure. Digital power is cheap and becoming cheaper. Google Rigol DSO.

Regards
cww

Of course you can use hardware analyzers. We use an HP 2 channel DSO scope with 16 digital inputs. For complex triggering and viewing data on internal variables, you can't beat a scan based softlogic analyzer within the PLC. That and pulling in variable names and things automatically is just icing on the cake.

KEJR

In reply to Curt Wuollet: The software I/O timing chart (AB had this years ago) is really intended for something a bit different than a real logic analyser or storage scope. The logic timing chart is intended to help find bugs in your program logic, while a logic analyser or storage scope tells you what is really going on, including hardware problems.

I've used a scope to diagnose machine problems a number of times, but I only ever used a PLC programming software based software timing chart once (more for the sake of trying it out, than anything else). It's one of those things that sounds nice in theory, but is not really that useful of a feature in practice. It's definitely not a substitute for a scope.

I've found them pretty much useless especially for timing problems since they depend on the system that isn't working. And many factors, some of them very subtle, can cause them to "lie".  Many  glitches  wouldn't be glitches if they occurred during the detection windows.

The glitch is there for the same reason that the system can't see it.  But looking at the real waveforms is not for the faint of heart, you sometimes wonder how the thing works rather than why it  occasionally doesn't.  Brute force filtering covers many sins. Most "doesn't work" problems with encoders for example are immediately obvious with a long record.

Regards
cww

Mike,

I didn't realize Topdoc was still avaliable, it's DOS-based, right? I used it back in college when I was first learning PLC programming, it was easy to use and understand, but now all I use is AB.

Thanks for the info.

Mike

As a purchaser, user and teacher in this field I can say with some authority that the cost of Rockwell software is prohibitive. Our university will allow its AB products to live out their useful life while we replace them with other brands (mostly Omron and Siemens).

The bottom line is simply the bottom line.

AB may be better but it is not 5 to 10 times better as the cost would suggest.

Anonymous said:
"AB may be better but it is not 5 to 10 times better as the cost would suggest."

I have NOT found Allen-Bradley to be 5 to 10 times as expensive as other brands. Siemens is every bit as expensive as A-B. We haven't used Modicon in a long time, but when we did there was no significant difference in price compared to A-B. Mitsubishi and GE Fanuc are also similar in cost. In fact, I've never run into ANY PLC that apples-to-apples is one-tenth the price of A-B.

Granted, there is a premium for A-B. That premium is very similar to the one for other "Tier 1" vendors like Siemens. AutomationDirect.com does have $99 PLC's, while a full-blown ControlLogix could run $10,000 or so. That's a hundred times more expensive! But it's not like comparing a Kia to a Cadillac; it's comparing a motor cycle to an 18-wheeler. A-B also has a $99 PLC.

-James Ingraham
Sage Automation, Inc.

Great I understand PLC companies have to make returns, however as many posts indicate there is a real posibility for PLC companies to make a lot more money by making more sales. At present, costs would be the decider in what could gain PLC sales, the major portion of control system sales, not just for mining and the big players as it is presently structured toward. I worked in the mining industry as a tech, however trying to justify PLC costs in local industry even over BMS can't be considered. I am one of many, imagine the money you big guys are missing out on.

Just a thought.

Peter

Lee,

This sounds more like a justification for your position as a programmer. I was wondering how you feel about buying a car but having to spend a 1000 dollars for the dealer to provide the software to be able to drive it off the lot? AND on top of that if you want to use the car next year, you have to buy the upgrade or user's license? You mention that the hardware is useless without the software and I agree, but since the software is useless without the hardware it's hardly an argument with merit. The software should be included in the cost of the machine, and the only thing that should cost is upgrades that make the hardware more efficient.

Wayne

The answer is quite simple. From the product point of view you can't
split a PLC system into a hardware and software part. Both individual
parts are useless without the other. The development costs of the
hardware of a PLC is only a fraction of the development costs of the
software, but both are defining the price of a PLC system.
If you buy a PLC system you are buying the whole system and not useless parts of it.

Why doesn't produce e.g. A-B the core of their PLC hardware in e.g.
China or anywhere else??

Their PLC hardware is the natural and best dongel for their PLC
software! And there are a lot of such 'dongels' out there :)
That's the reality ...

Best Regards
Armin Steinhoff

Lee,

why does it have to cost that much,nobody asked you to develop such costly software in the first place. you decided that type of application. Omron, mitsubishi, A.B, ect, ect. plcs softwares should all have the same software application to cut cost and also to make it easy for users. instead of having to spend money learning different applications. users do not have any say in what is going on. untill users decide enough is enough and vote on a single application, plc and software cost will always hold us hostage.

" ... plcs ... should all have the same software application to cut cost and also to make it easy for users."

Hopefully not. I would call that a disaster.

What might be nice is a standard FORMAT that any software application could save and open. Like how OpenDocument Format and PDF are all handled by myriad applications.

-James Ingraham
Sage Automation, Inc.

I suppose it would depend on which one. Having RSLogix work with all would generate a lot more enthusiasm than having say, Step 7 as the one. But it is interesting that the general software market seems to want only one product per catagory e.g. Office, AutoCAD, to the detriment of all others.

Meanwhile, the automation world has dozens of incompatible ways to product functionally identical results. Common formats and file compatibility would ease the incompatibility but would do nothing to mitigate the enormous cost of developing, maintaining and supporting the dozens of duplicative software packages which is obviously passed on to the customer.

It is even more interesting that there are business models that support both incredibly expensive software as a second profit center and those that give the software free as a part of the hardware business. I submit that using a common Open code base would cost less than either model. This means that it stands a chance of coming to pass, as is happening in the cellphone, netbook, and embedded markets. All we need is for sales to tank a little further where price begins to matter more. I am curious why you think that would be a disaster, well, except for the Step 7 case.

Regards
cww

"I am curious why you think that would be a disaster, well, except for the Step 7 case."

Answered your own question. :-)

Seriously, one ANYTHING is usually bad. Look how Internet Explorer stagnated until Firefox forced Microsoft's hand. Now there's a JavaScript engine speed war going on, with everyone fighting for "fastest JavaScript!" Competition is good.

Even with all the competition in browsers and Web standards, most websites work just fine in IE, Firefox, Opera, Safari, and Chrome.

I can't stand the "European" style that Step 7 and other IEC 61131 programming software uses. I imagine that someone who uses nothing but Step 7 can't stand the "American" style that Rockwell uses.

So I don't want a "one solution," like we have with Office.

-James Ingraham
Sage Automation, Inc.

In reply to James Ingraham: A standard format won't do you much good without standard content. A lot of newer PLCs use the programming software to pre-compile the program and add run-time libraries before downloading it. The vendors don't have a standard binary download format even between different models of their own products, let alone work with anyone else's. That's why you have to upgrade your programming software to use a new model of PLC.

Open formats only work when different parties are willing to work together towards a common goal. You mention OpenDocument, but you might want to remember that Microsoft was one of the last to implement it, and they still managed to produce a version that was incompatible with everyone else. What was the reason for that? Simple incompetence, or was it deliberate? We *know* that the only reason they implemented it at all was because they were told by a large number of major customers that they could forget about bidding on future contracts for office software if they didn't have it. That apparently didn't constitute enough incentive to actually do a good job of it though.

So, the question has to be why would any of the major vendors want to be compatible with anyone else? If customers didn't need to buy expensive vendor software to use their PLCs, how many of their existing customers would buy it? 10%? 5%? Programming software is a profit centre for the major vendors. Why would they want to give that up?

"A standard format won't do you much good without standard content."

True. Wanting an interoperable PLC standard is a bit like wanting a unicorn.

"Open formats only work when different parties are willing to work together towards a common goal."

Well, sort of. We have a lot of competing standards for the Web. It's really a mess out there. But it works, if at times painfully. And the organizations involved are DEFINITELY not all working toward a common goal. There's just enough commonality to make it function.

"So, the question has to be why would any of the major vendors want to be compatible with anyone else?"

True. We're back to my unicorn wish.


-James Ingraham
Sage Automation, Inc.

In reply to James Ingraham: I'm not sure what web problems you are talking about, but I have written a web based HMI system (https://sourceforge.net/projects/mblogic/) and I have been very impressed with how compatible everything is. Only one browser is any real problem, and that is MS IE.

Yes, Microsoft does play dog in the manger in the W3C committee because they want to block any progress for their own commercial reasons. However, the others work around MS informally and are bringing in new features and making sure they are compatible with each other. If any of the PLC vendors wanted to be compatible with each other they could work together in the same way even if one or two major vendors were being deliberately obstructionist.

Here's the browsers that I've worked with: Firefox, Epiphany, Midori, Chrome, Safari, and Opera. I've done some pretty esoteric CSS, XHTML, SVG, Javacript, and HTML DOM manipulation, and it works the same in all of them, except for some minor font size and padding issues (which are easy to accommodate). If the differences between PLCs were of the same order as the differences between web browsers, I think we would have very little to complain about.

Like Ford and GM same results different methods, and content... but standard content could be construed that a timer is a timer, and as an object it behaves the same as all other timers, but it may look different.

Presets are Presets etc...

Importing programs has been beaten to death, and if you work in ST then it could be possible... but Rockwell vs Siemens forget it..

There there is no common format or content..

There is the bridge that needs to be crossed - kinda like the difference between different development environments, but the same runtime (*.exe files)

Time for a another beer:)

Cheers from : Jeremy Pollard, CET The Caring Canuckian!
http://www[.]tsuonline.com
Control Design www.controldesignmag.com
Manufacturing Automation www[.]automationmag.com
3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

You are right. Interesting that this is the policy of PLC's manufacturers. For example, the producer of PIC microcontrollers has completely different policy and provides the MPLAB software free of crarge. That soft allows to create programs and is also a simulation tool, i.e. you can look how the program works without a PIC controller.

PICs are very powerful tool and are used in automation as well, the only issue is assembly language is not as convenient to use as a ladder logic.

It's a shame that PLC producers do nat have as same policy as PICs manufacturer.

Your question implies that you feel there is an alternative, which may be the purpose of the question.

As for me, I pay it for the same reason I pay for a building, electricity, taxes, etc. I am out to make money. Their software allows me to do so. They charge me for the software (and to maintain it), and I pass it on when charging my customers for my services.

Why do they charge what they do? I don't know, but I suppose they have to pay employees and overhead costs just like I do. If they charge more than the market will bear, the market will move on to someone else (just like they would do to me).

In short, I don't mind the cost, so perhaps I am the reason the cost is what it is.

A-B is now a part of rockwell international. they don't care much about soaking the customer for every dime they get.

the problem is thet the A-B products are so good. they are made to work in the harsh enviroments for a good long time. if the aplication is critical, the extra $10,000.00 spent to go with the good stuff is paid back with no lost production, low maintenance, coustermer service, ect.

the software is easy to use and very powerful. also very expencive. there is an update fee or subscription fee evry year or so.

rockwell software probably makes as much money or more than A-B makes selling hardware.

the automationdirect.com stuff is cheep. and it does work most of the time. I have recieved new processors that were defective out of the box! they promptly sent me a new one hassel free. my customer, however, had to endure another 24 hours of down time.

you get what you pay for. even in plc land.

I'm not convinced there is much of a quality difference between AB and PLC Direct. I once had an AB processor out-of-box failure and have never had one with a Automation Direct. I would say the quality of the two brands is about equal. My one complaint about A-B quality is that the RTD modules data seems noisy.

My preference for one over the other on a particular project usually has more to do with how the instruction set fits the job.

I've even done jobs with a SLC as the processor using PLC direct DL 205 I/O, because I thought the PLC Direct I/O fit the project better.

> My one complaint about A-B quality is that the > RTD modules data seems noisy.

Oops, meant to say "A-D" (Automation Direct) RTD modules.

Well, I suppose I pay because I feel it is worth it for that software and for the tech help and upgrades that I receive in return for the yearly support fee. I can't imagine using 6200 or some other acii-interface, dos-level software.

I guess PLC hardware and software manufacturers could roll those software development and support costs into the price of the hardware, but then the hardware would look too expensive. Furthermore, the hardware sales would not cover a lifetime of tech help calls so I see a yearly support fee as still being necessary.

It all seems like a no-brainer to me. I mean, why pay for a car and continue to pay for gas when you can walk to where you are going?

Hi All

Perhaps the real issue here is not whether or not one should be paying for the software, the alternatives are obvious and generally
unattractive, but whether or not the PLC suppliers are being ethical when we get financially "molested" purchasing the stuff. I for one am convinced the programming software which I am using is at least 1000% overpriced, this encourages loose morals with software piracy
issues and worsens the manufacturers position, causing an increase in cost of the software causing ..............

I see numerous references to, especially Siemens programming software, which people are "just looking for a copy of" which is demonstrative of the problem.

Regards
Donald Pittendrigh

They'd be a little hard to use without programming software. And those companies have made HUGE investments in the programmers and debuggers to develop those tools. They have to recover the costs somewhere. You prefer they mark up the hardware? Then nobody is competetive and the more hardware you buy the more you've paid above and beyond for the software.

Some people don't realize the amount of hard work and time that goes into the software packages. I used to be a computer programmer, and I know that a project the size of RSLogix or Modicon's Concept and Proworx would be absolutely huge. That's a major investment, and you've got to pay those salaries somehow.

You probably don't pay for shareware either, do you?

I can only agree with 50% of this point. I do not have a problem with paying for the initial software investment. What drives me to drink is the continual updates made to the software and the associated cost. Many of the companies mentioned in this thread will create a new hardware product and only make it accessible through an update in their software. Of course, Mr. Customer, you must pay for the upgrade as well. When does it end?

Hi All

>Of course, Mr. Customer, you must pay for the upgrade as well. When does it end?

It doesn't unless someone with the required size apparatus and a healthy budget finds grounds for sueing a company practising this catch 22 scam
and sets legal precedent, I wouldn't hold my breath while waiting were I you.

Cheers
Donald Pittendrigh

I totally agree with you about it being a lot of hard work developing a software package and the manufacturers should be compensated for it. However, sometimes the software you get is not worth the price you pay. For example, a $80 game requires a lot more coding (and runs better) than a $1,500 PLC software package (i.e. RSLogix).

Some may argue that the cost of the PLC software is justified because it will help me make money. But so does a screw driver. Would you pay a $100 for screw driver just because it helped you make money?

You pay very little for a screwdriver due to the great size of the market for screwdrivers.

However, if the $100 screwdriver was the only one on the market, and I was able to earn, or save, $150 each and every time I used it, I would pay the $100 like a shot.

Money is not particularly useful sitting in your bank account. Money's greatest benefit is to be spent carefully wisely in order to make more money.

Bob Pawley
www.automating-automation.com

Which is why wise people prefer not to get into single-supplier situations, and why there are laws about a sole supplier exploiting the situation excessively.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

Because we have no choice. There were third parties selling programming software, but they were swallowed up.

As a customer, I feel very much like a hostage to Rockwell, Schneider, AutoDesk, and most of all, Microsoft.

The fact is, it costs a lot to develop and SUPPORT the software that is used to configure PLCs. The continuous "upgrades" and license fees, as well as the exhorbitant up front charges are how they pay for it. Since all of the major PLC suppliers use the same tactic these days, they
don't really have any pressure to change it. Make no mistake, we'd still pay for it somehow, it just wouldn't be a line item on the invoice.

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

Well, I develop some of those packages and the money is not really in the development in as much as it is in testing it. There are many details in each and every firmware revision and processor family. I know for a fact no third party now will compete with us and cover all the details in making a programming package correctly. We could give the software away for free but people would still need support. The hardware prices would go up to compensate. The other benefit is if your an OEM is you can share licenses and program as much hardware as you want.

Linux is free but I prefer Microsoft for many reasons which I feel are worth the money. I have met the top developers at Microsoft and they are some of the most brilliant people around. I don't think smarter people are dumb enough to work for free. Even Linus has a real job now. Yes, programming packages are not as cheap as windows but we dont have the volume either. I dont like the support contracts and think that upgrades should be sold instead but it does not look likely ...

You don't have to use PLC and their software. Just write your applications in VB and see what it cost you to support your customers.

Ditto the "because we have no choice" sentiment.

PLCs work, and they work well. Allen-Bradley - while not producing the best product - has the lion's share. They know it, and they are not shy about raping us because... THEY CAN.

I am particularly distressed when circumstances force me to purchase OLD programming software for an outdated PLC or PanelView. As usual, A-B wants the same price they would've charged 8 or 10 years ago, when today's antique was "cutting edge".

What do we do, form a "Systems Integrators Local" and strike?

Jeff Cook
Cook Controls, Inc.
Dagsboro, DE
(302) 732-1157

You could try supporting and using the software you own for free from projects who treat you as a member of the community. In time, probably a very short time, that would bring about change. I haven't weighed in on this discussion because I don't buy software to program PLC's. What I'm hearing, I generally agree with. I don't have a problem with buying and selling software at fair value, it's the abuse that seems to upset folks.

I don't think there is a solution if you keep doing things the same way. When rapid growth stops, the money has to keep coming in somehow. This leads to charging much and delivering little to keep things balanced. That system only works with constant growth or the continuing revenue stream generated by the nicks and gouges that annoy folks.

I suggest that if you adopt a method where everybody puts in a little and the users develop the software directly, there's no corporation or infrastructure to support, so the need for a revenue stream goes away. You still have programmers, you still have testers, and things get added as they are needed. Done this way, everyone receives more value than they contribute. And you actually own something, forever. No one can cut you off or force you to upgrade. Makes perfect sense to me, I don't understand why it's such a hard sell compared to the alternatives.

Regards
cww

Simple, programmers gotta eat too. Why does an integrator charge the customer for the for the ladder code in the PLC in the control panel he just sold him? Extend that line of thinking and you would think that the ladder code would come free with the PLC and controls thats all hooked up to the machine. Sorry, but my kids need shoes too. Free enterprise at its finest, take it or leave it.

Let me answer that in a few different ways:

1: Please go to mat.sf.net and sign up to help develop an alternative.

2. Lock in. When your entire plant runs on Allen Bradley, and their "open" systems are just a bunch of marketing BS, you are stuck paying
whatever they charge. Management at most companies would rather keep getting nailed on the support contracts than move over to something else.

3. Most system integrators won't build anything else. We recently (6 months ago) spec'd a machine using the new Omron processor instead of a
controllogix. We have SLC's in plant, but no CL's, and the omron was a better system at a lower price. The integrators we spoke to would not build the omron system for us without charging us a premium for their software and training expenses. By the time they were done, the CL was cheaper than the Omron. (disgusting, btw)

4. Alternatives. Who doesn't charge for software?

5. Why do you pay for Visual Studio? That is programming software as well. and can run over a thousand USD for Visual Studio enterprise edition.

I think that covers it here.....

--Joe Jansen

Hello,

It's like paying for the extra toppings on a pizza. The analogy is not quite perfect and perhaps someone has a better analogy.

Best Regards
EW

Of course you have to pay for the functionality that you get.

For me, the aggrevating thing is the support licenses that we have to pay for. It is OK to pay for online/telephone support and for new software versions that have new functionality that we need.
But is is NOT OK that we have to pay for software updates to get bug-fixes for software that we have allready paid for.

Cleverly, AB and Siemens etc. packs the updates with the new functionality and the updates with the bug-fixes together. In that way we cannot argue that we should recieve the bug-fixes free of charge.

My simple answer to you is would you rather pay for the programming software once and a fee to keep it current, or would you rather pay an extra percentage for all the hardware you purchase, even spare parts when the software is already existing? The manufacurers of plc must support the cost of their developement and support personnel in some way, and I believe the way they are doing it is probably the best and fairest for all those involved.

Stephen,
I'm curious as to what industry or job function you do? I sell and support PLC's and have done that for years. It doesn't get any easier as the PLC's and the software become more difficult and all inclusive as the manufacturers develop new features to entice users.

Are you aware of how much engineering time goes into developing these devices? Right now I have to know about (7) different programming
packages and when a customer calls me, I don't ask him for his credit card number or his service account number to offer him my "expertise". We help as much as we can and when something is beyond us, that is when we call Tech Support. Oh, and those people aren't free either...

Maybe, this will explain why PLC manufacturers charge for the software.
WGS

This question was asked in the past pretty often, mainly because PLC HW has always been relatively expensive and the tool really only was meant to program the PLC Beside the answers that I have seen regarding the investment recovery for such tools, today there are other arguments as well PLC Programming tools have grown to design tools for Industrial Automation, covering much more than the ladder in the CPU. The features also serve engineering productivity, this is very important since the application complexity of today's PLC's has increased dramatically compared to 10 years ago
If you bring your car to a garage you will also be happy to see the mechanic use advanced tools to diagnose your problem, same for Industrial Automation

Let's turn this thread up a bit...

Why do we pay for expensive, buggy, incomplete software, complete with incomprehensible (and don't worry about it since they're outdated anyway) manuals, and then have to pay additional fees for tech support to tell us how to ACTUALLY get it to work?

Not a theory, this has been my experience. No particular manufacturer is being singled out, as it's pervasive.

In a free market society, I'm afraid the answer is the same as that to the question, "Why is there so much violence on TV": because that's the
way WE like it. WE pay for it, and reward the manufacturers who do business that way, and penalize those who don't.

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

I suppose that's an answer to the question, but many of the problems you note above are addressed by providing access to the actual, compilable source code. For software questions that's the ultimate documentation. If it's buggy, then someone who cares might get in and fix it, similarly if it's incomplete or if the attached documentation is incomprehesible.

Ken

--
Ken Irving <jkirving@mosquitonet.com>

I could not read this article, and not to add something.

1. Documentation - !!! Cutting cost!!

Usually (on smaller projects) client is trying to avoid paying instrumentation and control detail design documentation (project). They usually give some instructions to the programmer.

(To prepare all information required for programming a I&C system requires technology, instrumentation & control knowledge and some basic programming knowledge. Of course it takes time as well.)

2. Pressure to finish the application software urgently, save money on communication cost etc.

Based on such basic instruction, the programmers who usually do not have instrumentation and control experience are programming (without consulting the client), and in case there is no pre-commissioning, the contractor delivers the application software, and comes to hand the work over.

Unfortunately the client realise that the I&C system does not work correctly, and the corrections commenced. Often (almost always) the
contractor is correcting his mistakes on the account of the start-up cost. The man/day price at site is of course huge (specially overseas), and the contracted amount for start-up is spent, and the work is not completed.

Often in turn-key projects, the contractor is misinforming the client by offering 1-2 weeks of commissioning and start-up services, which cannot be completed for a month.

In such project organisations (usually smaller projects in which the client has ideas to save money on detail design), the client at the end pays more, because the system integrator - programmer can claim that he had done it in
accordance with basic instructions.

So everything starts with detail design, and finishes with as-built documentation that will be very useful for maintenance or later upgrading.

Conclusion:

a. Somebody has to finish the programming
b. If the application software is not OK, the problem is again on client side, because he did not prepare the tender with design papers, he gave the work to the company that has not sufficient experience in work (again price cutting) and he did not organise the work as it should be.

I like this question; and YEA it escapes me also why MY Company Spends 15,000 a Year on AB Software then anotehr 6k a Year on Training. For New Software.. and we're even switching to ControlLogix Processors another 10k on Software..and they KEYS to unlock the software Comes on a yearly Basis of 1,200 a year for new keys and u only GET ONE KEY per package. NOW everyone can see that THIS IS A COMPLETE Money RACKET. Can't you, Ive been a VB and VC++ for Over 15 years, Ive been the the automation field a little over 2 years, And I Am AB Certified<( Yea i Know, NOW My Boss Has Stuck with AB for 10 years..and WONT LET GO..Because He Knows Nothing Else. HE knows NO OTHER Way or method
of Doing anything except AB. He Knows NOTHING about Computer Programming. (or even cares) Except Ladder Logic and RS-VIEW, In-which is SAD.

Me on the otherhand Try and Handle all the other Delima's we face that our Customers & Company's want. OPC /DDE .TCP-IP / Networking /
Client-Server / Excel Value generation / SQL-DAO Database Processes./ Custom Active-x / .And Do u Realize What I Make a year.?? 32k yep thats All...but hey its a really Relaxed Inviroment.i get to travel And Eat For Free.and i have
(3) 2Ghz Machines in my Office.

well there is my ranting,
let hear some feedback

I stayed on the sidelines so far on this one, but this post puts it all in perspective. Let's start with why I sell you PLC programming software and support contracts...

The programming software is a real cost of the technology, and has to be paid for somewhere. If it was buried in the cost of the hardware, it would increase costs to integrators while having no impact on end users. The existing model for PLC programming software moves the bulk of the costs directly to end users. This seems reasonable, since the machine builders/integrators have the product in their hands for days, while the end users have no limit for how long they need support. (I am supporting
28 yearold systems today!)

You have the choice of not buying our systems. If the customer demands that you use my stuff, it just means I'm doing a good job. Choose not to participate, or form a relationship with me, but stop doing the Whiny Whiny.

You can avoid the cost of upgrades by freezing your baseline (which several of my clients do with good reasons). This moves the cost and risk completely to the end user. I can still have a useful business relationship with you.

Bug fixes are another issue. Yet, I'm not aware of any reputable PLC manufacturer that charges its end users for serious product problems discovered years after product delivery. Just for an example, we completely covered customers back to 1993 for a problem we discovered in February 2001. Yes, bug fixes are included in upgrades--- but if the machine doesn't change, you don't need upgrades, and you wouldn't be using the machine if it didn't work in the first place. If your machine/process evolves continually, then you need support continually--- and damn, that costs something!

Ultimately, I'm the guy from the big automation company that you call in the middle of the night, on Sundays, holidays, weekends. Under better circumstances, you call me at 7:30am Monday morning and want to discuss how you can improve productivity in your existing automation. I'm the
person you need to have a relationship with if you have an evolving, completely normal set of automation.

You pay for the programming software because that pays for me. I actually like this job, so I hope you will continue! (My clients on the list: Chime in any time!)

Those are the positive aspects. There are negative ones. That brings me to the post from Brian E. Boothe. When a customer calls me at 3:00am on Memorial Day, I help him. If his employer has actually paid for the support licences, then my boss actually got some revenue from this. Otherwise, it's just me getting annoyed because a hostile user didn't learn anything useful at training.

We charge the big bucks because people often don't have the expertise they need to solve problems and we bail them out when they call. If you have a better business model, now is the time to post!

Hope this helps!

Larry Lawver
Rexel / Central Florida

Thanks for your support Larry.
You said everything I was thinking

Lee J Ward
Business Manager - Programming Software
Marketing Group
Schneider Automation

I guess that when the guys who use the software and PLCs give the stuff they are manufacturing away for free, I'll no longer need to earn the money I make from creating industrial automation products I require in order to buy the aforesaid products. Until such time, you pay a small and highly reasonable charge applies for my expertise...

Cheers
Tim Linnell

To those that have a problem with purchasing upgrades/support agreements for new software, I say if you do not want to pay for it, simply keep using your old software with the plc platforms and cards that it supported when you bought it. Otherwise if you want to take advantage of the new technology you need to pay for it. This is no different that when Microsoft releases a new version of windows and expects you to purchase the new version, or an upgrade from the version you had. You have a choice there as well, switch to a different operating system, and see how much it costs you to become productive again. At least the PLC manufacturers provide support for their software without asking for a credit card the first time you call them and want help.

Not all of them. If you don't pay your annual fee, rockwell won't talk to you at all. Even to recover the activation file that is required to run the software you already paid for.

--Joe Jansen

After reading most of the reply's on this thread, it seems to me that a lot of people just don't understand how software is priced. Software pricing is dependant on two factors

A=the cost of development over the life of product

B=the projected number of copies to be sold.

Price=A/B

Let's assume a cost of 5 million, divide by 500,000 copies (not much more is possible for this class of sotware) = 10 dollars.

Compare MS Office cost 50 million divide by 10,000,000 copies (typical MS Office number) = 5 dollars. MS sells the Office for $500. For Rockwell, using the same ratio, you get $1000.

Other factors to consider, marketing, support, backward compatibility, etc. Do you all think that software prices are just dropped on users without some thought? THIS IS BUSINESS!
Anyone who thinks that industrial software prices are too high, have never tried to code and then resell the code! Get your heads out of the sand people!

Because it's hard to get it for free :-(
Although sometimes possible...

Regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.

Sure, we pay for it. Then we copy it for internal use on other PCs. Doesn't everyone?

I do hope not. Unless you are using the product within the bounds of the End User License Agreement, do not be suprised someday, if a federal agency comes and knocks on your door.

Regards

Lee J Ward

Business Manager - Programming Software
Marketing Group
Schneider Automation

I look at it from the O/S system side. If good old MS didn't change their versions so often then PLC producers wouldn't need a team of 20-30 persons to make new versions to run on the MS platforms available. I guess if PLC software was platform free there would be about a 60% saving in unecssary R&D costs. From a PLC producer point of view they recieve about 1000 enquiries a month from PLC users about new functionality which would be handy. In this case somebody must pay for these developments. In today's competitive market hardware margins are dropping like bricks so manufacturers need to break even somehow.

Hi Ian

And if the PLC producers didn't use Microsoft, they would have a lot more manpower to add functionality or could put those people on fixing
bugs. Running an OS wersion until it makes sense to switch would save a lot of money and tremendously simplify support. And when the old
software would run on the new OS and hardware with just a recompile sanity might prevail amongst vendors and customers alike. You give up a lot and work a lot harder when you abdicate control of your schedule to Microsoft. Not to mention simultaniously supporting half a dozen incompatible products Some of which would be better left to die. Do you suppose sensible stuff like that would lower the cost of the software?

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

Some of us use our old version of RS-Logix and build all of the new machines with Automation-Direct, at a much reduced cost.

I think it will come to free software somewhere in the future, Emerson Drives now gives away it's software for programming for Free, I suspect competition will continue to drive the prices down, as more and more people find out there is an alternative to A-B, and they lose more market share...

We don't pay for programming software we use Linux. This gives us more fexibility and I fill it gives us more controll over the equipment. Also there is no software versions, cables etc. to worry about. Yes, it takes more work up front, but it is well worth it in the long run. And yes ethernet card only cost us $20.00 (more less).
Down time is comparable to PLC systems. I think I know what I am talking about I worked in automation industry for close to 10 years and used PLC extensively. As it is now I will not touch a PLC (maybe for a small application).

I remember when A-B was embarrassed of their software. So they bought ICOM. Seem to me everyone is mad at A-B prices. Bite the bullet and look elsewhere. Otherwise keep paying through the nose. Watch AD raise prices if they can. Its business. At some point you must decide you want value, not ego driven marketing induced products that promise what everyone can offer.

As a former integrator, and now as a tech support specialist for an AB distributor, i can tell you there are many reasons for paying for software.

First, there is a real cost associated with developing, testing, producing, packaging, selling, improving, and supporting the software, and if it weren't paid for directly, then it would have to be spread out over the product line for which it is intended, making the hardware more expensive.

Second, it is an investment in your ability to deliver your product to your customers. If you are an OEM or an integrator, then you pass on the cost of the software to your customer as a legitimate project expense. If you are a part of an internal engineering group, then this is simply a capital investment that allows you to keep the machines running that make the products that you sell. As a capital investment, it is also tax deductible as a business expense; so, its real cost is only about 1/2 of what you physically pay for it. This goes for the support contracts as well.

Your company probably already licenses network software (it doesn't just come when you buy the network hardware), it probably already buys upgrades to MSOffice, McAfee or Norton, and your e-mail system (they don't just send you the upgrades for free when they have them, unless you are under support), and it probably has support contracts for the copiers and fax machines (just because you buy a copier, doesn't mean the vendor will fix it for free forever!).

Third, it is a given that anyone who purchases PLC programming software is going to need help either using the package, or help with making the code they have written, work. This cost is associated with the initial purchase of the package, and with the continued support contracts. We, as distributors, for the most part, do not charge for this service. Sure you can get free software from some of the vendors, but can you get a tech support person to come out to your facility when you are having trouble? How many field personnel does Automation Direct or Modicon have out there? As an AB distributor, you can call us when you can't figure out how to properly tune your PID loop, you can't communicate with your processor, or the communications to you drives have gone down, and we will send someone to you usually at no charge. But, just because there is no charge to you, doesn't mean there is no cost to us. These visits are paid for out of the money we make selling you the software and support contracts.

Finally, nothing in life is free. If you are an OEM or an integrator, do you not charge your customer for the documentation (drawings, user's manuals, program listings, etc.) that you supply with the machine? If we go by your logic, why should they have to pay to get documentation that you've already generated to build the machine? The reason is because there is a cost associated with supplying it. Don't forget that you get what you pay for. If you've paid nothing for your software, then you can probably expect that back when you're looking for help. If you've paid a fair price for this tool (and that is exactly what it is), then you can expect a fair amount of help when you really need it. Otherwise, your only option is to develop, test, support and supply your own package, and then see what the real cost of that to your organization will be!

An interesting point here is that the person who started this thread works for a company that gives its software away for free.

(MODERATOR'S NOTE: We considered not posting this comment because of its anonymity, but were able to verify that the information submitted by Anonymous appears to be correct, because Stephen's email address was available on the Automation List. However, in the future we may consider not allowing anonymous posts in similar situations.)

(I'm Really Tired of this Question) >>> Why do u Pay For PLC Programming...

Because AB is TOP of the LINE , and when your Company Makes 4-Million dollars a Year We tend to be able to buy TOP of the Line Equipment and we make up the price thru the Customer, ("HOW exactly do u Do PLC Programming?") Thru Your DH-485 / Serial Port w/ The Freebie Cheap S*** That, Make your Customer Look Like he Spent $5.00 on Control Issues. I'd love to take a look at your SCADA Screens.. (" I Bet theyre Horrific ")...

If I recall correctly, the initial inquiry in regards to this was politely worded and seeking answers. This sort of response is totally unprofessional and not worthy of the majority on this site. As for a few of the comments that you made, let me respond (though I am not the originator of the original question).

1. There is no doubt that AB is an excellent product, but it is certainly not the only one nor I believe to be the best out there, they have an excellent marketing department.
2. That's great that your company makes $4-million a year, not all companies do and require to make do with what they can. Some of the best programmers I know started with only a DH-485 programming link.
3.As for the "horrific" Scada screens, that comment was unworthy and beneath contempt.

Steve

Hello List,

Just a story.
Once, one of my customers asked me, "why do you write your own user-interface, why do you invent your oun languages? There are a lot of wheels around the world... Have a look at this one. (He showed me a demo-project of a SCADA)... Good-looking screen, animation and other thousands delightes..."

I began to answer and at the same time I "played" with the mouse on the screen. The result was the following: the demo had crashed itself and had crashed Windows. Again: it was demo-project! = End of story.

No need to say I never heard any question on the topic after that incident.

About the UI screens... It is just a pictures, just a problem of good design. To solve it is much easier than to fight with the ugly system concepts. ;-)

Regards. Vladimir.

To the Moderators and all Subscribers:

Regarding this post, I wanted to state to everyone that I am not "anonymous" that post this reply to my original question. For any misunderstanding, I apologize.

The intent of my question is to attempt to generate information as to why software is charged for, when it is a required tool of the PLC. The product that is being sold is the PLC, not the programming software. The PLC is useless without a means to program. Even though there are development hours required, It should all be included in the overall design of the hardware product. If PLC software was open and could run on any PLC, then the discussion would be comparable to the computer example. In the computer industry there are companies that only develop software to be run on various PCs. There is no hardware associated with the final product. This makes sense. Squeezing a few extra dollars out of your customers, I consider to be questionable. Consider that many are required to purchase software and have no choice because that product is "speced in". Other fees include upgrade fees (aka Microsoft) Yearly site license fees, etc...

I, and countless others have asked this question on other forums as well.

FYI - On June 24, I was on my way back from Maine . It was an all day drive (13 hours) and I had no computer with me.

That's OK, it's making all the right people uncomfortable and has been a really interesting thread. And I believe it's a very fair question. I especially question the extensive copy protection when the software is pretty much useless unless you own the hardware.

It just raises costs. And after all, the entire pool of people who _want_ your software are by definition, your customers. The copy protection, it seems to me, is somehow related to most of the
practices folks find offensive. Once again, I have no argument with the use of it, merely the abuse. I'm sure others will argue that any way of using it is OK as long as it makes money.

Regards
cww

I think part of why integrators don't see this the way developers do, is that the work of integrators is regulary copied in whole or in part, and used and abused by the client, given away to other clients, and used by competitors on future projects. Software developers build their pricing on the idea that the cost is spread out among the users. If Allen Bradley charged customer number 1 the entire development cost of
RSLogix, then they wouldn't worry so much about it being copied or used for other purposes. I just don't think customer number 1 brought seven
figures of cash to the table to go with the PLC.

The reason the integrator can get away with charging the entire cost of development to the customer is that the developers SPENT A LOT OF MONEY developing the tools to make the integration that cost effective.

Wow, you guys have me arguing for the OTHER side, now!

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

George G. Robertson, P.E. wrote:
<clip>
> Software developers build their pricing
> on the idea that the cost is spread out among the users. If Allen
> Bradley charged customer number 1 the entire development cost of
> RSLogix, then they wouldn't worry so much about it being copied or used
> for other purposes. I just don't think customer number 1 brought seven
> figures of cash to the table to go with the PLC.
>
> The reason the integrator can get away with charging the entire cost of
> development to the customer is that the developers SPENT A LOT OF MONEY
> developing the tools to make the integration that cost effective.
<clip>

I asked a couple of software developers what is normal for development software used in large IT software projects, and I was told that there are
many different pricing models. It is however quite normal for large scale development systems to be given away free to genuine software developers, with no fees being paid until deployment. At that point you are typically
charged for the run-time in proportion to the size of the finished system.

This is essentially equivalent to giving away PLC programming software and rolling the cost into the hardware price, or giving away the MMI or SCADA development software, and charging for runtimes. In other words, some of the
suggestions regarding how automation software should be sold are in fact closer to what is considered normal practice in the large scale IT software development world than many people appear to realise.

Statements to the effect that "developing software costs a lot of money" are quite simply begging the question. The question ought to be whether the pricing system used is suited to the business model of their customers. Evidently a good many people feel it does not, although they do not seem to have articulated this point clearly. System integrators may be more satisfied
with a pricing system which is co-ordinated with their own project cash flow rather than having to gamble their working capital on a particular PLC's or MMI system's sales success.

A further point I feel compelled to address is that charging separately for the development software avoids "burdening" the hardware with this cost.

Unless the programming interface is made public and the OEM's software is being sold against competing third party programming software, then the idea that there is any "separation" is complete nonsense.

In the absense of open and fair competition there is no guarranty of meaningful correspondence between the price of the software and the perceived benefit to the customer. Since you need to buy the software to use the hardware anyway, the hardware is still being "burdened" by this cost. Any arguments to the contrary are accounting fantasies.

I won't conclude from the above that typical current pricing models are wrong, but I will say that I have yet to see a convincing arguement that they are correct.

************************
Michael Griffin
London, Ont. Canada
************************

Let us just compare a PLC with a PC. If you would have to pay for your hardware and then for your operating-system seperatly you won't be happy, because the prices for PC's would go into the 4ks.

Nobody is expecting to get hardware without the software for the price you have to pay for right now.
On the other side well established software firms will give you updates for bugs w/o any fees or just with a small admin. fee.

The behaviour of the PLC manufacturer is not to accept.

What would people say if the buy a new computer and the operating system is going to fail from time to time and they would just get the answer buy a new one???????

Limiting the amount of development by selling the software makes no sense for hardware sales. If you have 5 engineers and a company unwilling to buy more then one copy of the programing software. You only have 1 PLC sold at a time. If the software was paid for through hardware sales you have the potential for 5 PLCs sold at a time. A lot of companies have no problem buying hardware, but dislike buying software for some reason.

Hello George,

The fact: To produce a PLC you have to develop before: a) the PLC hardware, b) the embedded PLC software c) the cross-tools, workbench software.

So, the total cost of a PLC is (N*cost_of_PLC_harware + cost_of_development + profit)/N, where
N - the total quantity of producing PLCs,
cost_of_PLC_harware - cost of coping, producing,
cost_of_development - sum of cost of hardware development and cost of the embedded soft development and the cost of workbench development
profit - profit of the vendor.

So, why the cost of workbench development is distinguished is hardly to understand... possibly, because workbench (as a cross-tool) is leable to endless upgrades (if we keep in mind the dirty MS' habbits).

The other reason could be the sale policy: the more small company pay more money... or it is the cost of the support survice. (IMO, $1000 is too
expensive for it though)

There is two ways to compensate for the workbench development cost:
1. to include it in the PLC cost (to evenly spread it on the PLCs), or
2. to make separate sales of workbenchs (to evently spread it on the customers).

IMO, both ways are acceptable.

BTW, there are official representatives of the vendors in the list. Why do they lurk?

--
Best regards,
Vladimir mailto:zyubin@iae.nsk.su

The trick is, historically, the products we are now using to program PLCs were NOT originally developed by the same business units (and in
many cases that same company) that developed the PLC hardware. If they were, then your argument would be valid in general. By the way, there
are some vendors who did develop all of the above, and in some cases, MMI software together. These tend to be very inexpensive for the reason
that you gave.

Don't know why the vendors are lurking. Probably a very sensitive topic. <G>

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

Interesting. I am one of your customers, BTW, inside of mc-mc's distributor area in Greenville,SC.

I am also a former integrator, and now work inside of our corporate engineering group. I have been doing this for just over 10 years now.

>>>>>
First, there is a real cost associated with developing, testing, producing, packaging, selling, improving, and supporting the software,
and if it weren't paid for directly, then it would have to be spread out over the product line for which it is intended, making the hardware more
expensive.
<<<<<

I agree. Nobody can realistically deny that there is a cost associated with doing this. More on this later.

As an aside, I worked for Allen Bradley for a year as a line tech/supervisor in their HQ building in Milwaukee, WI. I have seen the
horrible corporate structure that these products have to support. The operators on my line had 3 layers of management over them just in the
department. Then there was another 5 layers of management before you got to Don Davis, CEO. I can confidently say that about half of those
positions would never be missed, and only exist to give a buddy a fat check. When I quit, I recommended to the department manager that he not
bother filling my position, as I really did no work there for a year. My point? Maybe the hardware wouldn't be so exhorbitant already with a better corporate structure. Fix the problem, and AB could give the software away for free and maintain the same profitability.

>>>>>
Second, it is an investment in your ability to deliver your product to your customers. If you are an OEM or an integrator, then you pass on the
cost of the software to your customer as a legitimate project expense. If you are a part of an internal engineering group, then this is simply a capital investment that allows you to keep the machines running that make the products that you sell. As a capital investment, it is also tax deductible as a business expense; so, its real cost is only about 1/2 of what you physically pay for it. This goes for the support contracts as well.
<<<<<

Kind of like the merchants in Chicago in the first half if the 1900's paid for their 'Insurance' and it was just a cost of business? Sorry, but I don't buy that argument. I know for a fact that it is not an accident that
the file formats change from one version of Logix to the next.

>>>>>
Your company probably already licenses network software (it doesn't just come when you buy the network hardware), it probably already buys
upgrades to MSOffice, McAfee or Norton, and your e-mail system (they don't just send you the upgrades for free when they have them, unless you
are under support), and it probably has support contracts for the copiers and fax machines (just because you buy a copier, doesn't mean the vendor
will fix it for free forever!).
<<<<<

Open Source. It is a beautiful thing. Network software IS free. Although the Cisco's that I set up came with the software, so I am not sure what you are getting at here.

Does my company use anything like this? No. That does not mean that it doesn't exist. I know at least one list contributor who's organization
_does_ use Linux, Open Office, and all the other free open source software. As to the analogy between the copier and the software, Rockwell has never fixed any problems with their software for me in anything that could be considered a timely manner whether I was in support or not. At best, it would be 'in the next major revision, or maybe the one after that'.

>>>>>
Third, it is a given that anyone who purchases PLC programming software is going to need help either using the package, or help with making the
code they have written, work.
<<<<<

Nope. I have never called you. I do not call RS for support, since it is usually useless anyway. Can I get a discount on my software since I don't
need this 'valuable'(?) service? I learned AB programming on APS, so I have never needed help with Logix. At best I have called to report bugs in their software. Are you telling me I should pay for that benefit? I'd rather not.

>>>>>
This cost is associated with the initial
purchase of the package, and with the continued support contracts. We, as distributors, for the most part, do not charge for this service. Sure
you can get free software from some of the vendors, but can you get a tech support person to come out to your facility when you are having
trouble? How many field personnel does Automation Direct or Modicon have out there? As an AB distributor, you can call us when you can't figure out how to properly tune your PID loop, you can't communicate with your processor, or the communications to you drives have gone down, and we will send someone to you usually at no charge. But, just because there is no charge to you, doesn't mean there is no cost to us. These visits are paid for out of the money we make selling you the software and support contracts.
<<<<<

Again, since I usually know more than the person on the phone or the one that gets sent out to me, can I get a discount for not needing this service? If I teach your tech something, will he cut me a check for 'supporting' him?

I have never had a Rockwell person come out to my site for support. Ever. Your comparison is flawed in that you compare AB distributors against AD and Modicon Corporate. I have had Modicon distributors come out and help me with problems, just like AB distributors. Usually just as pointless, but they were just as warm a body as the AB guy.

>>>>>
Finally, nothing in life is free. If you are an OEM or an integrator, do you not charge your customer for the documentation (drawings, user's
manuals, program listings, etc.) that you supply with the machine? If we go by your logic, why should they have to pay to get documentation that
you've already generated to build the machine? The reason is because there is a cost associated with supplying it. Don't forget that you get
what you pay for. If you've paid nothing for your software, then you can probably expect that back when you're looking for help. If you've paid a fair price for this tool (and that is exactly what it is), then you can expect a fair amount of help when you really need it. Otherwise, your only option is to develop, test, support and supply your own package, and then see what the real cost of that to your organization will be!
<<<<<

Again, your analogy breaks down with the Open Source projects. Without arguing who is better at what, or who is more stable than who, Linux is at least comparable to Windows over all. Yet there is a vast pricing difference.

To be honest, I have followed the RSLogix 500 upgrade path, and the latest (5.00) I really am not sure what it was that was improved. I noticed that the file formats are conveniently incompatible, thus forcing the upgrade if I get any new equipment, but functionally, I am not sure what there is. I know that it has some rather annoying bells and whistles that I wish I
could turn off (like the yellow pop-ups that appear when I am editing mnemonics that try to help me remember the parameter list. If I am in a
long coding session, I am entering code at the bottom of the screen with the code scrolling up as I enter rungs. At the bottom of the screen the
pop-up covers up the mnemonic entry window, making it impossible to see what I am typing. I paid $$$$$ to get this 'feature'?) As to the 'get
what you pay for' argument, I typically tend to disregard that anymore, as it often can be proven untrue. RSLogix is not the orders of magnitude
better than everything else. The only reason you can charge what you do is because AB holds the proprietary keys making it impossible for anyone else to write a competing package, by cutting off the communication protocol. Without being able to talk to the processor, the software would be pretty useless. This another case where prices are not dictated by quality or consumer desire, but by forced upgrades thru incompatibility, and
foreclosing any competition to maintain false pricing levels. Trust me, if AB were to allow the DH+ spec, for example, to be open (for real, not their marketing BS version of open) there would be a free version of RSLogix within a few months.

And the market would be better for it.

--Joe Jansen

you really think an open version of AB SLC 500 programming software is availible? My first entry into AB SLC 500 programming was APS. A few years later I fully purchased the 8.1 version and was so frustrated with the the "user key" and other crap that came up with using it I reverted to 3.? and have never used 8.1 again. Lately I have found some units that I could not access because I did not have the current version of the software. Now my problem I have customers who use the old APS to modify N:files and T:files etc. If I start to use the new RS Logics 500 software they also will be required to "update" just to access their paid for machine parameters.Some how it does not seem right that the progrsmming that I and some of my customers purchased are no longer usable if one of us upgrades. Another problem is that my APS will not load on a newer lap top and this requires me to carry two units around? What a pain!

I agree its a PITA to have to continually upgrade, however, in fact for most users this just is not a major issue. The relatively small yearly upgrade cost is not all that much, and quite frankly, I see no way that they could make the thing forward compatible.

The few people who complain about it can stick to their old APS software. There are still people driving 1960's vintage cars. It does not mean that the auto companies should make parts for these obsolete beasts. It comes down to how much money does it cost, and is there any potential at all to make a profit. If there is no profit in something, then there is little incentive to do it.

BTW-I think you can get APS to load and run on a new laptop as long as you have DOS installed on it instead of W2k or something, and the right hardware is used. If I am not mistaken, there is an OSS version of DOS (I think its the leftovers of DRDOS) that might work just fine for you.

Bob Peterson

Bob Peterson:
> I agree its a PITA to have to continually upgrade, however, in fact
> for most users this just is not a major issue. The relatively small
> yearly upgrade cost is not all that much, and quite frankly, I see no
> way that they could make the thing forward compatible.

Then you're not a very good software engineer... (admittedly you never claimed to be one).

Making things forward compatible is not that difficult; it just requires some forethought and some discipline. And, of course, the incentive to
do it, which in this case is totally missing at best.

Jiri
--
Jiri Baum <jiri(AT)baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

Interesting point Jiri makes ... it seems 9 times out of 10 I'm disappointed with how manufacturers manage forward compatability, but the other day was pleasingly suprised with the way ABB handled it with their new ACC 800 line of DTC drives.

This is an evolution of the ACS 600 series, and they set things up so a parameter setpoint panel from the 600 can be plugged into the 800 with no loss of functionality (although, of course, it won't be able to address new 800-specific features). The 800 series panel can be plugged into a 600 drive (new 800-specific features it knows about aren't displayed).

This makes upgrading or replacing drives a breeze. The 800 series signal terminal blocks are laid out exactly as the 600 series, and new 800-specific terminals are brought out on their own blocks. The basic footprint is smaller than the 600, so (except for tapping new mounting holes) there isn't any reason to stock both series of drives to handle breakdowns.

It's nice to know *somebody* out there thinks of these things!

Bob

mike---

I covered all of this at

http://www.control.com/1026150918/index_html

Hope this helps!

Larry Lawver
Rexel / Central Florida

Of course, the question is whether it wouldn't be better to make the 28-year thing explicit, as a support contract. The software itself would then be correspondingly cheaper, or even more so if you consider it a loss-leader.

Attempting to finance an ongoing thing from a once-off payment is a always going to be a problem.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

Jiri---

The annual support renewal rate is shockingly low, but the demand for support is constant. The upfront fee guarantees revenue to support the development and delivery of the software. The profit my boss makes pays for me, and the initial handholding every new client needs.

Yes, if everyone paid their annual fees (as is common in the HVAC business, for example), everything would be clear about the business. When my client lets support lapse, I still find a way to help, as long as it makes business sense. My 28 year old installation, mentioned in my previous post, has bought little PLC stuff during my tenure--- but my boss and salesman get $100K/year in MRO business from the account, which is enough to justify my attention.

I reject the use of programming software as a loss leader. The software has value, its support has costs, and all of that must be paid for, somehow. Cheap software, in my experience, is worth the price. The payment has to be made somewhere. (And everything can be negotiated!)

An additional note: Our bestselling PLC programming and documentation software package costs $1100. If a one-time expense of $1100 is a problem for a plant, I can't imagine why I would want to call on it. Automation is supposed to be part of a profitable plant operation. $1100 is the cost of a small downtime or a minor mechanical breakage. If a one-time $1100 expense is a problem, the plant is undercapitalized, mismanaged, or failing, and not an attractive client.

Hope this helps!

Larry Lawver Rexel / Central Florida

And if $1100.00 for software to _start_ working and buying the really expensive stuff isn't questioned, the plant is mismanaged. Then there's the continuation costs, and so on. This never seems to get looked at and these gotchas come as unpleasant surprises. My point is that the cost of proprietary systems is high, complex, and nebulous but is always regarded simplistically. If a shop commits to a given product line, the $1100.00 is diddly for the vendor as well. Heck, that's the cost of one $5.00 serial card with a "special" connector or a couple of "special" cables. I would think the business and goodwill generated by giving away the razor would be worth it considering the margin on the blades. Especially since the razor is useless without the blades and no other blades will work. And having your razor greatly increases the probability that someone is gonna want your blades. Raising the threshold for entry just doesn't seem to make sense. For an inhouse shop your argument may hold, but for a small independent shop, $1100.00 for something that might only be used for one project is kinda steep. I have personally seen this up front cost kill projects, so someone cares about the $1100.00. But then, it does provide an opportunity for folks to do it differently. With less arrogance.

Regards

cww

Jiri Baum:
> > Of course, the question is whether it wouldn't be better to make the
> > 28-year thing explicit, as a support contract. The software itself
> > would then be correspondingly cheaper, or even more so if you
> > consider it a loss-leader.

> > Attempting to finance an ongoing thing from a once-off payment is a
> > always going to be a problem.

Larry Lawver:
> The annual support renewal rate is shockingly low, but the demand for
> support is constant.

That's a problem, of course.

> The upfront fee guarantees revenue to support the development and
> delivery of the software. The profit my boss makes pays for me, and
> the initial handholding every new client needs.

I've no problem with the initial stuff; it's the ongoing thing that bothers me, because it has a vaguely similar sense to pyramid schemes.

> Yes, if everyone paid their annual fees (as is common in the HVAC
> business, for example), everything would be clear about the business.

Yes, that would be the best.

> When my client lets support lapse, I still find a way to help, as long
> as it makes business sense. My 28 year old installation, mentioned in
> my previous post, has bought little PLC stuff during my tenure--- but
> my boss and salesman get $100K/year in MRO business from the account,
> which is enough to justify my attention.

That makes sense - if the client is a current client, still buying stuff, then the support can be financed from the new stuff they're buying, even if it's a different line.

> I reject the use of programming software as a loss leader.

Sorry, that was a bit of agitation for open-source :-)

The argument still stands if you delete that clause from my post.

> An additional note: Our bestselling PLC programming and documentation
> software package costs $1100. If a one-time expense of $1100 is a
> problem for a plant, I can't imagine why I would want to call on it.

Certainly. It's just that if someone buys a $1100 package off you, how are you going to allocate that to the next 30 years?

More importantly, how will the clients know that you're allocating it to the next 30 years? If your competitor decides to skimp and only go for
25 years, they're going to beat you on price, and nobody will know until a quarter of a century down the track.

Jiri
--
Jiri Baum <jiri(AT)baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

>Third, it is a given that anyone who purchases PLC programming software is going to need help either using the package, or help with making the code they have written, work.<

If I have to call tech support because the software doesn't work properly out of the package, (or, more often, because the documentation stinks to high heaven) I shouldn't have to pay for that. The company didn't finish the product. The company has failed in their duty to their customer, and they should just be grateful I'm calling them instead of my attorney. I don't call to ask for help programming.

The motion instructions on the ControlLogix are a prime example of this situation.

For Pete's sake! Let's take this even further. The I/O is no good without the processor, so why don't they give you that? Your car is no good without the engine, so they shouldn't charge you for that either, right? This whole discussion is ridiculous! For those of you not wanting to pay for software or licensing, for those of you not wanting to pay the premium price for AB products, and for those of who convinced that AB stuff has far more bugs and problems than any other vendor's, and that their tech support is any less knowledgable than any other vendor's, good for you! And good for me, too. This means that while you are putting together systems with hardware from a mixture of manufacturers, using off-brand or bargain basement controls, struggling with "Open Systems", and playing the "Who's problem is it now that everything doesn't work together" game, I will be putting up with any inconvenience I have to from AB. In doing so, I know, from having done the same sorts of things, that my system will come up quicker, smoother, and with much less effort than the majority of yours. My initial hardware costs may be higher, but my overall project cost will be lower. I know that I have only one place to turn to when I need help (face it, all tech support is terrible); I know that my customer will be able to get product support no matter where in the world I send my equipment; I know that my customer will be able to find someone outside of AB tech support that will be familiar with the AB hardware/software/networking and be able to help with any problem that may arise. I know that the software (and hardware), no matter what I paid for it or what its problems, is supported by a multi-billion dollar entity who could care less about me and my problems, but has a vested interest in making sure it works, not by an international committee or by a company who decided to use their own home-grown OS (proprietary or "Open") and may not be around to support it, or may not want to continue supporting it, in 5 years. I know that the hardware will be around, be supported, and be compatible for at least ten years or more (can the PC or Automation Direct people say that?).

Let's face it though, bottom line is that no vendor, hardware platform, or software platform is perfect. If there was such a thing, we wouldn't be having this discussion, and there wouldn't be as many choices as there are. Right or wrong, we each do what we feel is best for our own company based on our past experience and emotions (I have never had an experience with AB that was bad enough that I would never use them again, some of you obviously have), not on any concrete rule of thumb. So, let's agree to disagree, put this ugly topic to bed, and in the words of the great Rodney King, "Can't we all just get along?"

Anonymous:
> I know that the software (and hardware), no matter what I paid for it or what its problems, is supported by a multi-billion dollar entity who could care less about me and my problems, but has a vested interest in making sure it works, not by an international committee or by a company who decided to use their own home-grown OS proprietary or "Open") and may not be around to support it, or may not want to continue supporting it, in 5 years.

That's multiple-sourcing your support might come in handy, because frankly none of the above options sounds particularly attractive.

As long as support is only available from (or controlled by) a single entity, you're going to have problems.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

>As long as support is only available from (or controlled by) a single entity, you're going to have problems.

No, this does not follow. The most you can say is that there is the potential for a problem, but frankly I'd rather have a support contract and
someone to sue if it's not upheld than chance my arm with a gaggle of be-sandalled geeks with beatific grins on a self-congratulary bulletin
board. Who are more likely to explain that my whole way of working is wrong than attempt to align the software with how I want to work.

I do find this discussion bizarre. The software in question is being used to build machines who will produce lifetime profits of 100 times the capital investment used to create them. If anything needs to be given away for free, the attention might better be focused at this end of the equation than on the material and software supplied to produce it.

If you want expertise in your supplier, you will have to pay for it at some point. If you don't, then Mat-PLC will be ready real soon now, really.

Cheers

Tim

Hi Tim

> >As long as support is only available from (or controlled by) a single entity, you're going to have problems.
>
> No, this does not follow. The most you can say is that there is the potential for a problem, but frankly I'd rather have a support contract and someone to sue if it's not upheld

Yeah, right. Read your license again. Seriously, you should, before the situation comes up.

> than chance my arm with a gaggle of be-sandalled geeks with beatific grins on a self-congratulary bulletin board. Who are more likely to explain that my whole way of working is wrong than attempt to align the software with how I want to work.

Straight line FUD. I don't even own a pair of sandals :^) and I would be glad to compare our developer's credentials with anybody's. Let's not
get slanderous or propagate myths. Probably more sandals at IBM these days.

> I do find this discussion bizarre. The software in question is being used to build machines who will produce lifetime profits of 100 times the capital investment used to create them. If anything needs to be given away for free, the attention might better be focused at this end of the equation than on the material and software supplied to produce it.

Is it somehow wrong to give it away if you want to? They have their purpose, we have ours. I find it strange that you would think that theirs is more in your favor. Think about it.

> If you want expertise in your supplier, you will have to pay for it at some point. If you don't, then Mat-PLC will be ready real soon now, really.

How on earth can you possibly make the judgement that we don't have expertise. The very idea is to have a community of experts in their particular field. We could very reasonably have a great deal more expertise on tap than any one company could ever afford. It's even perfectly reasonable that we could share some of the very same people. Very strange reasoning indeed.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

> but frankly I'd rather have a support contract and someone to sue if it's not upheld

I actually laughed out loud when I read this. You think you can sue someone for non-functioning software? Next time you install something, and
the little window pops up with all that text inside, and where you usually just press the accept button to go on, try reading it once. That should do fairly well to dismiss the whole "someone to sue" myth that for some reason
still exists. It shouldn't. Nobody has ever successfully sued a software maker, because you release them from any responsibility when you install the software. At most, they will owe you a new floppy, or $5.00 is the typical maximum liability, whichever is less.

Maybe I can offer the same for MatPLC. $5 or another free download, whichever is less.

--Joe Jansen

Can't agree with you more - and we've found that the distributors seem to know more about the products than the AB reps/techos.

My question is - isn't the software a tool to encourange more people to buy more hardware? SI's and OEM's would like to learn a product and then keep using it to keep costs (relearning) down. With ControlLogix for example, it seems to be a retraining exercise every time a new release comes out.

But we have to run several versions to keep in line with our customers (no point in upgrading to Logix500 v5.00 if most of our customers still use v4.50 (and it ain't backward compatible, of course!!!)

and then there's the firmware - nuff said!!

The investment in writing the software is huge. In order to have all the bells and whistles everyone seems to think they need, the programmers have to make it happen. The money is made software- the hardware typically is a break even process in most cases.

AB has the long term performance that others do not have. If they did not they would not be one of the leaders. Again, all the engineering and hardware and software costs have to be paid somewhere. Remember a lot of the AB stuff is built in the USA- those people tend to get higher wages. The import stuff is built where the annual wages would not hardly pay your annual utility bills. Think how you would like it if your job was outsourced to India, China or someother third world nation. The only reason it is not done now is that you are here and they are not.

There is a cost of buying products from a US company and some are related to the cost of employees. Besides if the other companies import products were that good, they would totally take over the market- which they have not.

This is degenerating into a completely unproductive flame war. Let's shut it down.

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

Allen Bradley have software writer who struggle to write good software for us to use. They are paid and in turn AB get's paid. If we steal the software and there is no profit for AB, AB will then have no reason to continue supporting their software. Also Software Piratecy is against the law. I have experience with a fired employee reporting to Autodesk about illegal copies of Autocad on about 15 computers at my old job. We brought one and loaded on 14 other computers. The company almost went through a law suite unheard of. So pay to play.

I asked this question over nine months ago and made the mistake of mentioning the programming package of one of the big three PLC manufactures and how much better it was over their competitors. The moderator censured my letter and would not post it. So I will re-visit this issue and avoid the so called ?sales pitch?.

I have read several of the letters and claims are made of the cost of writing the software, cost of support etc. These arguments are mis-placed if the cost of producing the software was considered a marketing cost. Let me be perfectly blunt. There are packages out there that suck big time so much so that it doubles the time of a project integration. And, there is a package out there that enable me to complete a project 80% faster than any other engineer using the other packages that suck.

If the marketing manager of this company pulled his head out and posted this package on the internet and put the cost of writing the package on the advertising side of the ledger the sales of his three PLC lines would go through the roof.

In reality some of his cost would actually go down. For example, when a bug is discovered the new version would be posted on his website. Client would check the website for a new version and use that first and then call tech support. The product distribution costs would disapear because it was on the net. If the package had really good help files (they are very good now), but it the package was intuitive then the support costs would diminish ever further. He would also not need to produce two packages, i.e., one for the small PLC and one for the large PLC.

Basically, hardware is hardware. I believe that for the most part every manufacture?s hardware is very good. The difference is how the hardware communicates and how it is programmed. If I can complete a project 80% faster with his product than with someone else?s product, I would be a fool not to recommend it to my client. Especially if the software was available on the internet.

Come on show some intestinal fortitude and charge us for the hardware and use the software as a very good advertising and promotional tool. You hardware sales will sky rocket.

By the way the programming package I am talking about is the only FULL IEC 1131b programming package on the market by a major PLC company. There is only one major manufacturer of PLC world wide that I am aware of that has a full IEC 1131b package (It is not Phoenix Contact)

Yes, I use the other packages that my clients require, but they still suck and cost them more integration costs because they are not as effective programming tools.

Gordon Clyde Cummings
President
Prism Automation Systems
Clearfield UT

Gordon
Can you tell me which PLC line it is? I am exploring the use of IEC 1131 programming and am interested in looking at all possibilities.

Thank You
cecskm@yahoo.com

I agree but what choice do we have. If you already have AB PLC'S in place such as the older 2 and 3 models you could get the software for free. Then AB decides to upgrade thier PLC line and sell the software dept. to Rockwell. Rockwell decides to sell the software and the next thing you know everything is costing you. I think it is crazy!. I agree that the RSLogix is easy to use but having to have a licence per user computer is way out of line. If you wish to have an engineering station on more then one data highway then you have to purchase another software package. It is for this reason I am staying as far away from AB's PLC's as feesable.

Jim

We pay for this software because we always have, we think we must, and we are used to it.

The truth is, this question is really part of the answer to the question many people ask me.

Why is it that you build far more PC based, open architecture control systems than traditional PLC systems?

Think about it.

We loved PLCs in the 70s and 80s. Every dog has his day. The day of the proprietary control system is dwindling.

The world is moving on.

Rick Caldwell
SCADAware, Inc.

My company made a conscious decision years ago to standardize our PLC's to one PLC manufacturer, Allen Bradley, based on solid buisness principles. I pay to use A-B's (Rockwell) software because I like it, I am very used to it, and it is practical to be expert on one software verses simply somewhat familiar with many. I may be "locked in" but I am comfortable operating the way we are. The incentive to change is not apparent and I enjoy the efficiency gained from knowing one software package well.

That's a very reasonable point of view. Now, how about a package that you could know even better, where everything is visible. A package that you can have a say in and truly own. Wouldn't this greater knowledge be an asset? even with the cost issue aside?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

> That's a very reasonable point of view. Now, how about a package that
> you could know even better, where everything is visible. A package that
> you can have a say in and truly own. Wouldn't this greater knowledge be
> an asset? even with the cost issue aside?

Only if the open package met the company's functional needs as well or better than the proprietary one. A completely open product that doesn't do what a $10,000 package does isn't necessarily a better deal.

That the open package may eventually be better is not a compelling reason to invest time and effort mastering it today. For companies that want to
make money using tools, a tool must first exist before the company will consider using it.

A last point: If a company changes tools, its existing applications (or its clients' applications) must:

1. continue to be supported, using the tools with which they were built, or

2. replaced with the new tool of choice, or

3. abandoned to the competition

I don't imagine that many companies will choose to abandon their clients, or replace perfectly adequate working systems just so they can use a new tool. That leaves option 1, which implies continued use and development of expertise in the current toolset. If you're going to have to be expert in one toolset that produces working solutions, where is the incentive to invest in a second body of expertise?

Once a company has standardized on a package, and invested in their own use of it, there must be a really, really good reason to choose something
else.

Just my two cents,
Greg Goodman

Another factor to consider is that there is a
ready pool of labour / consultants familiar
with proprietary PLC systems.

Just look at control.com. You'll find questions
and discussions on most major brands of PLC's.
You're not just paying for the label, you're
paying for the ready knowledge and familiarity
among the pool that goes with that label.

If your local labour market if full of people
who know AB, Modicon, Siemens, etc. would you
not be driven to pay top dollar just to simply
remain tapped into that market??

This is just another part of a supply/demand
system. The bottom line is that the market will
bear the price of PLC programming software. The
only way it will change is if there is a change
in supply or demand. Then the price will adjust
to a new value that the market will bear. It
might go down, it might go up.

Anthony Kerstens P.Eng.

Hi Greg

Chiron Consulting wrote:
>
> > That's a very reasonable point of view. Now, how about a package that
> > you could know even better, where everything is visible. A package that
> > you can have a say in and truly own. Wouldn't this greater knowledge be
> > an asset? even with the cost issue aside?
>
> Only if the open package met the company's functional needs as well or
> better than the proprietary one. A completely open product that doesn't
> do what a $10,000 package does isn't necessarily a better deal.

But, that works both ways. With the ability to customize and color outside the lines, it may well be that the open package can provide better
value. Often there's a feature that you want or a part of your solution that isn't supported by shrinkwrap software. With the open package, you can get what you want. And once developed, it's available to all. In time that should provide pretty comprehensive coverage. If the feature is a dealbreaker, the open package may well be the only way to provide it. I you want to integrate diverse existing equipment, that market is poorly served by the status quo and replacing half the stuff so it's compatible is a tough sell.

> That the open package may eventually be better is not a compelling reason
> to invest time and effort mastering it today. For companies that want to
> make money using tools, a tool must first exist before the company will
> consider using it.
>
> A last point: If a company changes tools, its existing applications (or
> its clients' applications) must:
>
> 1. continue to be supported, using the tools with which they were built,
> or
>
> 2. replaced with the new tool of choice, or
>
> 3. abandoned to the competition
>
> I don't imagine that many companies will choose to abandon their clients,
> or replace perfectly adequate working systems just so they can use a new
> tool. That leaves option 1, which implies continued use and development
> of expertise in the current toolset. If you're going to have to be expert
> in one toolset that produces working solutions, where is the incentive to
> invest in a second body of expertise?

Yes, this is the lock-in factor. Fortunately it depends on what you do. In house, that's probably it. But for consultants and SI who normally use what the customer wants, it's not as big a factor. And one package that can be made to work with most everything would be a serious
advantage. It could actually conquer the lock-in factor and provide cost benefits verses knowing a little about several packages. These would be the folks most able to benefit from a swiss army knife type product. And they would be most likely to extend and customize it. Indeed this is our target audience.

> Once a company has standardized on a package, and invested in their own
> use of it, there must be a really, really good reason to choose something
> else.

Agreed. Fortunately there are enough infelicities in the current model to provide an opportunity.The key is the customer. As they become educated, the demand changes. And they are getting smarter quickly. Take a look at the article I posted.

Regards

cww

cww wrote:
>With the ability to customize and color outside the lines, it may well be that the open package can provide better value <

I don't want to customize my tools or color outside the lines. I want to make the machine / process do what it's supposed to do quickly, and in a way that's easy for me to support and maintenance to understand. I will happily pay someone to make sure that I NEVER, EVER, see the source code for the tool I'm using to accomplish that. I don't forge my own screwdrivers, I don't write my own OS, I don't fab my own CPUs. Richard Stallman can pontificate 'till he's blue in the face; I don't care about "free software."

Exactly once I have been able to download, compile, and run an Open Source package. Perhaps this is just because I'm an idiot, but no one I've ever directly worked with in the automation industry has even managed to match my measly one "win". So I've got no desire (and no incentive) to go playing around in source code.

Don't get me wrong; I hate the commercially available options. But telling me, "Here's something you don't like, but you can fix it yourself!" isn't my idea of perfect solution.

-James Ingraham
Sage Automation, Inc.

There are three parts to a PLC:

1) The hardware (Digital and Analog I/O)
2) The operating system (code to interpret your program)
3) The programming software (a means to have the hardware do what your application requires)

A PLC cannot function with only one or two parts...all three parts are required. To say that a different unit develops programming software is a weak argument. All the manufacturers that are charging you for software use this argument as an excuse, when in actual fact, their overhead is so enormous, they have to create additional revenue streams to support their juggernaut. Not only do they charge you for the software upfront, they charge you a yearly registration/license fee (in the case of Allen Bradley and possibly others) Some even charge you for support. Then there are the upgrade fees charged when they either fix a bug or come out with a new feature. And from some of the responses on this list, to some of the discussions I have had with customers, the factory support is a waste of time and money. When a distributor knows more than the factory person, something is wrong. Why do you put up with this?

Stephen Luft
Entertron Industries
3857 Orangeport Rd.
Gasport, NY 14067
Tel: 716-772-7216
Fax: 716-772-2604
web: www.entertron.com

No disagreement. I don't like the IRS either, but I put up with it for pretty much the same reason that I put up with this software situation. Weak argument or not, the separate business units are a fact. In several cases, the PLC company BOUGHT a competitor, and they HAVE to justify the purchase on it's own merits.

George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252

You seem to be unaware that third party companies offer software to program almost any major plc manufacturers hardware. Unfortunately their software is also expensive and almost always has less features than what is offered by the hardware manufacturer. Software costs money, otherwise the integrators in this list would simply giveaway the sofware that they write to operate a machine/system for free since it would also have no value.

James:

You are right! Customer does not interested in source codes, DLL, OPC, OOP, OS, POSIX, Ethernet, sensors, PLC, customization, HMI, MTBF, DB, programming languages, etc., etc., etc.

All we need is Working Plant.

But! Automation directly connected with the hell of maintainability. The Open Source approach makes the maintainability a bit less expensive and a bit more reliable.

Regards. Vladimir.

> cww wrote:
> >With the ability to customize and color outside the lines, it may
> >well be that the open package can provide better value

James Ingraham:
> Don't get me wrong; I hate the commercially available options. But
> telling me, "Here's something you don't like, but you can fix it
> yourself!" isn't my idea of perfect solution.

If your choice is between something you hate and can't fix, and something you hate and can fix, I can see how neither would be a particularly appealing option.


Jiri
--
Jiøí Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

There is a stark difference between "can fix" and "will fix." Most of my customers are pretty busy doing real work, and don't have time (or the capacity) to learn the ins and out of a large body of source code simply to fix or customize it. Further, I do not believe my customers would be interested in paying me to do it for them -- suddenly their "free" OSS would become incredibly expensive. When compared to the cost of ones time or a contractor to customize/fix OSS, then even the A-B support contracts are incredibly reasonably priced.

Packaged software, support contracts, and upgrades exist for a reason. Not everyone is a software developer and a vast majority of users have zero interest in fixing software they acquire even if it includes source code.

Jeff

Jiri Baum:
> >If your choice is between something you hate and can't fix, and something you hate and can fix

Jeff Dean:
> There is a stark difference between "can fix" and "will fix."

Yes, of course, but it's a very different kind of difference than betweeen "can't fix" and "can fix".

> When compared to the cost of ones time or a contractor to
> customize/fix OSS, then even the A-B support contracts are incredibly
> reasonably priced.

I think the comparison should rather be the other way: for a price similar to the A-B support contracts, OSS support contractors will provide better support; partly because they have the source, but mostly because there's competition between them.

Obviously, major rewrites of the OSS would be very expensive, but then no-one will do them (unless they have good reason).

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib

Jiri Baum wrote:

> > When compared to the cost of ones time or a contractor to
> > customize/fix OSS, then even the A-B support contracts are incredibly
> > reasonably priced.
>
> I think the comparison should rather be the other way: for a price
> similar to the A-B support contracts, OSS support contractors will
> provide better support; partly because they have the source, but mostly
> because there's competition between them.
>
> Obviously, major rewrites of the OSS would be very expensive, but then
> no-one will do them (unless they have good reason).

The other issue in this whole argument is the actual net cost. To a small integrator or user, the cost of a license is quite high. because it has to be spread across a small number of projects/machines. For larger integrators or
larger users, its not a big deal because the cost can be spread over many projects/machines, and the software is made available at far more attractive pricing than the list prices often alluded to here. I once figured that the cost to the company I work for to use AB programming software worked out to a few pennies per hour of engineering time spent using them. Its such a small number that most users don't even notice it. And until there is something that works as well available as an alternative in the OSS realm, that situation will not change any.

Bob Peterson

> The other issue in this whole argument is the actual net cost. To a
> small integrator or user, the cost of a license is quite high.
> because it has to be spread across a small number of
> projects/machines. For larger integrators or larger users, its not a
> big deal because the cost can be spread over many projects/machines,
> and the software is made available at far more attractive pricing
> than the list prices often alluded to here. I once figured that the
> cost to the company I work for to use AB programming software worked
> out to a few pennies per hour of engineering time spent using them.
> Its such a small number that most users don't even notice it.

IMHO nobody - even in open source community - suggest that low cost of OSS is more than icing on the cake. The main issue is power which is
inherent in unencumbered access to all features of this system. Rewrites of OS are an extreme (and unlikely) possibility. Even small and
comparatively easy adjustments, tuning up and customising provide very efficient way how to achieve significant improvement effects.

> And until there is something that works as well available as an
> alternative in the OSS realm, that situation will not change any.

Correct. I believe that there are already a few groups working on it.

Regards

Petr

> > That's a very reasonable point of view. Now, how about a package
> > that you could know even better, where everything is visible. A
> > package that you can have a say in and truly own. Wouldn't this
> > greater knowledge be an asset? even with the cost issue aside?

Greg Goodman:
> Only if the open package met the company's functional needs as well or
> better than the proprietary one. A completely open product that
> doesn't do what a $10,000 package does isn't necessarily a better
> deal.

Naturally - but not every company has functional needs of the entire $10,000 package; we fully expect that the initial adopters will be those
who only require the basic functionalities.

> That the open package may eventually be better is not a compelling
> reason to invest time and effort mastering it today.

Unless the package will meet the company's actual functional needs for less than $10,000 worth of improvement (say 100 man-hours).

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

For all the people wanting freedom from paying for PLC programming software, I recommend looking at Horner Electric's Operator Control Station. It is an operator interface and controller in one. It uses free software that is available on their web site. "www.heapg.com":http://www.heapg.com This software programs both the control logic and operator interface. WOW what a concept. No charge for the software and the hardware is priced competitively as well.

Hello Anonymous

Good luck in getting the "It should be Free" crowd to understand that people that write PLC programming software need to get payed like everyone else. I tried to submit access to free OPC VB client code on the list but since it wasn't a Linux solution it never saw the light of day on the list. Simply resign yourself to the Linux slant of the A list and you will find swollowing each post a little easier.

I don't mind paying a PLC manufacturer for their software and technical support, however I feel I should get what I pay for. If I paid a couple of hundred dollars for software I wouldn't expect very high quality software with lots of "bells-and-whistles".

I have purchased RSI/AB RSLogix5 and RSLogix500 at a very premium price and I feel that I have been ripped-off. For an investment of several thousands of dollars I got what I consider some very poorly developed software.

It is my opinion that RSLogix software is very non-productive, especially in the areas of documentation. It is also very buggy and slow.

My personal experience with trying to talk the RSI software developers about the many problems I have with their software it is like talking to a brick wall.

I don't think we should pay for software after the prices we pay for hardware it should all be include in the price. If like me you use several diffrent PLC's like AB Rslogix, Modicon Proworx32, Mitsubishi Gppwin (now called GX Developer), it can get very expensive. The hardware is useless without a means of peogramming it so it should be free issue.

PS if you think RSlogix is bad you should try some of the others, most I have found are still using Dos or a windows version of the old dos program.

i dont mind paying for software when its feasible, which is most cases..aslong as manufactures support their software as hardware advances and that theirs no hidden charges for upgrades... however in cases like im facing now where some hardware is obsolete and the expense of the software doesnt make sense to charge the customer for ....i have one customer who has recently purchased a metal heat treat system the plc is a 884 modicon... customer wants to access this plc to check program make changes to suit local codes from gas authority and E.S.A . customer wants to verify we can conform to all codes using this system... at some time in the future the plc will be upgraded... so i would need software able to access and program an 884....good luck finding an old copy of taylor ...schneider will sell for 1700 CAN... a little steep for such an archiaic tank of a plc. dont mind paying for software capable of handling todays plc but i think schneider is trying to make to much money on something their will be no more or very little development and support for in the future, sort of seems like milking it to the end. in cases like this the only thing i can do is to buy the software take the loss on this job and hopefully make it up in future business with the company.... ive exhausted all my resources in finding a cheaper solution to activating this system for a simple commisioning and evaluation.

Seems reasonable until you consider that you probably (like most today) have little or no experience with the 884 programmming software and will need to call their tech support several times. Since it is older you will end up talking to one of their more experienced, ie more costly experts and possibly even end up costing modicon/schneider electric money.

Have you looked into Zycom software? They used to have software that handled all the Modicon PLC's

Do you mean Xycom?

I recently wrote a PO for over $700 to maintain support for our RSLogix500 and RSLogix5 software. The problem I have is that AB PLCs have been made the standard at the plant I work at, so this is what I am stuck with. As long as there is such a large base of AB PLCs that are installed out there, it will be difficult for the situation to change.

I just got a quote for a SLC5/05 processor. The $2300 price tag made my jaw drop........

Valid reasons are:

1) Economies of scale. Microsoft sell licenses in there millions, automation companies sell licenses in thousands, or less.
2) How is support payed for? You either charge a subscribtion or charge for all technical support calls, or do both. No charge, no support.
3) Software development costs are as high, if not higher than hardware development costs, yet the cost of hardware in real terms has reduced. Economies of scale apply here also. How many PC's are sold compared to the number of PLC's?

Im sorry but supply and demand is one thing highway robbery is another. Although I agree selling millions of copies of windows tends to knock down the price, lets be realistic here we're dealing with a data file editor and a comm app. not an operating system. Let not forget also that new versions are rarely a clean sheet of paper they are additions and revisons. Why is AB forcing you to pay out your nose (for buggy software) in order to take adavantage of firmware upgrades? If this software such a burden for them to develop why arent PLC programming/communications standards made open by the manufactures for third party software houses to write for?

Sorry automation companies(besides Ge-Fanuc and some Schneider products), are making us pay for their inefficencies we cant quote our customer any price we want and neither can they.

Im

Based on your comments about the cost of AB's software, it apears to me that you have alot to learn. RSLogix 500 is very easy to use and has great features. Maybe you need to read the manual or attend a training class. to help you with the cost issue, You may ask you local AB distibutor for a quote on a MicroLogix 1000 Starter Kit. it should sell for about $360 and includes a copy of RSLogix 500 Starter, a MicroLogix controller, serial cable, input simulator, and manuals. With this kit you are getting the software for free. So, now that cost is not the problem, what else are you going to complain about.

For the same reasons we pay for software tools and support to Microsoft and other vendors. We are constantly changing and developing programs on a variety of PLC's, Motion controllers etc. If you have a problem and do not have a support contract, then you do not get help, bug fixes upgrades etc. It would be nice to get it free but that is not the case with many suppliers. Replacing existing hardware and software with that of manufacturers that do not charge for their software would cost more than the fees we would save. And I am not even sure that it would be possible. If you want to have the latest and most capable software and hardware then you need
support. If you want to work with previous generation ones then you can probably get away with little support.

James Bouchard

Hi All

This issue comes up all the time, the answer is simple, do you think the software package, documentation, R&D on the software as well as the manuals even in electronic form are possible to make for free. Do you have some vision of an army of developers and translators not to mention publishers distributors etc. etc. all lining up for the greater cause of industrial automation...... FOR FREE????

If you know of a place where this Utopia exists, please let me know, I want to be there too.

Regards Donald P

Free is not always better. Software that is sold is sold at a price to maintain the company and future developements. I do not mind paying a premium for the hardware or software if it functions as I was told it would. One thing we all have in common is money. If I dont make any, Im gone, if they dont make any, theyre gone. As far as free, how many of you that want free give away your products or services?

Free is not reality, you always pay in the long run. We sell very cost effective (better than saying cheap) PLC programming software for the Siemens S5 and S7 plc's with up-to-date English documentation. I maintain records of users, their product serial #'s, their PIN #'s, the version of software they are using, and provide technical assistance if needed. Any questions visit www.ttintl.com or e-mail me at jdt@ttintl.com.

You have to include the cost of the software into the project. Unfortunately there is no direct way around this.

But remember there are indirect ways to handle this so it works out for everyone involved. Negotiation. My company pays for very little of it’s required programming software. Usually the sales person has very little leeway to negotiate for hardware but they can fudge the price of the software without getting approval from higher up’s .

I know every one can not promise huge hardware purchases to their sales person on every purchase but you can look ahead to your needs for the next 1 to 3 years and use that as a negotiation tool. We make about 40 purchases a year from GE-Fanuc ranging from 20 to 60 thousand dollars each. With this level of purchases we get most of our software free.

5 years a go I did a 50 million dollar purchase from A-B. Part of the deal was that all required software would be free for development and the customer would purchase their own licenses after the plant was up and running. The reps from A-B basically gave us their entire RS suite and the key generator they used to make key disks under the stipulation that everything would be destroyed upon completion of the project. This worked out for everyone involved. We had close to 40 seats of the entire RS suit set up for the plant start up. Not counting the hardware for the programming seats, each seat was worth about 15 thousand dollars. I was un willing to purchase these seats and basically put it that way to A-B.

What would be the alternative? Who doesn't charge for software?

The same problem pops up in other SW-areas. Joel Spolsky on joelonsoftware.com has a lot to say on this. For instance:
"All else being equal, demand for a product increases when the prices of its complements decrease." He makes a strong argument for this on http://www.joelonsoftware.com/articles/StrategyLetterV.html ending up with "Smart companies try to commoditize their products' complements." So, PLC manufacturers have to decide what are their products and what are the complements. As we can see from this current dicussion, PLC manufacturers and users do not agree. We users view the HW as the product and the programming environment as the complement. Manufacturers seem to be looking at things the other way aoround.

Other input into this, concerning getting users to switch brands. "The best way to eliminate people's objections to switching to your product is to make it easy to switch back. Nobody wants to switch to a product that is going to eliminate their freedom in the future." See http://www.joelonsoftware.com/articles/fog0000000052.html

Maybe the printer, electric toothbrush, and video-gaming markets are "different", but this flys in the face of what works there.

In all of these other markets, the best strategy has proven to give the core product way at near cost (or a loss) and then reap the profits on the "complements". To follow this model, the PLC vendors should make the PLC very cheap (ie: a MicroLogix 1000 for $99) and then expect to profit from the cables and programming software.

When Nintendo dropped the price of the GameCube from $149 to $99 they had a near 40% increase in volume immediately. Games still sell for $29-49 each. Sony & XBox grumble Nintendo must be lossing money on every console sold, but guess what ... ;^)

- LynnL

On January 9, 2004, Lynn at Alist wrote:
<clip>
> In all of these other markets, the best strategy has proven to give the
> core product way at near cost (or a loss) and then reap the profits on
> the "complements". <

I think the term "core" product is a bit misleading. The "core" product is the one which makes money. The one you want to give away is the one which gets your foot in the door. The product you want to make money on is the one which you will sell repeatedly after you have established your market.

> To follow this model, the PLC vendors should make the
> PLC very cheap (ie: a MicroLogix 1000 for $99) and then expect to profit
> from the cables and programming software. <

No, you would sell the software and cables cheap, and make money on the PLC CPUs and I/O. You get someone to learn how to use your software, and hope this encourages them to try out your PLCs. This in fact seems to be exactly the strategey of some smaller PLC companies. Even the major companies will sometimes do this as an "introductory offer".

Setting a high price on the software creates an initial entry barrier. In setting a high price you are asking the customer to assume all the risk (i.e. they may not like your PLC once they try it).

If you charge a high price for your software, your PLC must either be very low risk (already be well known to the customer), or there must be a reasonable chance that it is technically superior or financially cheaper to the alternatives by a very large margin. PLC technology is fairly mature, so there isn't much room for technical advantage. Shifting the costs to a later point in time (when the customer is buying more PLCs) may make sense once you take risk into account.

> When Nintendo dropped the price of the GameCube from $149 to $99 they
> had a near 40% increase in volume immediately. Games still sell for
> $29-49 each. Sony & XBox grumble Nintendo must be lossing money on every
> console sold, but guess what ... ;^)
<clip>

Standard practice in the video console business has always been to lose money on the consoles and make it up on the games (including royalties on third party games). Typically, they need to sell 4 to 6 games per console sold to break even. Microsoft loses money on each XBox console sold, and so far they're not making it up on the games (which is why their games division has been losing so much money). Sony is believed to be breaking even on their console, as their hardware is better designed for manufacture than Microsoft's XBox (which is really just a low end PC with a crippled version of Windows 2000).

The problem in the games console business is the same chicken and egg problem I outlined above with PLCs. If you charged a high price for the console, you would have tough sell whenever you brought out a new model. You would be
asking the customer to assume all the risks of whether they will like it and whether there will ever be enough good games for it to make having the console worth while. Instead, the manufacturer assumes some of the risk by
subsidising the console sales and deferring their profits until the customer buys enough complements (games).

--

************************
Michael Griffin
London, Ont. Canada
************************

I believe that the answer may be more simple than most people think. The plc manufactures want to make profit on hardware because they are not always the ones doing the programming. I work at a control systems house in Beaumont, TX. I have noticed over the years with our local industry that they tend purchase their plc hardware from a vendor, but have their programming done either internally or by a systems intergrator. We sell both hardware and programming services, but the two don't always go "hand in hand". Today, it seems, everything is about profit. Plc manufactures want to make a profit by selling hardware and systems houses want to make a profit by programming. So in the end it is the end-user that usually has to pay for both.

Troy Gallier
Scallon Controls
troy.gallier@scalloncontrols.com

Actually, I think the explanation is even simpler. The PLC manufacturers have to recoup their substantial software development costs one way or another. The can
either sell or lease the software outright (leasing can give the end user a lower initial cost as well as provide a revenue stream to pay for support). Alternatively, they can factor it in to the cost of the hardware. But this doesn't make the volume buyers very happy. If I buy 1000 units, why should I pay 1000 times the programming costs a single unit buyer buys?

So the vendor has to choose who to make happy, and how. (Of course, this follows the "maximum profit" rule).

But it's us little guys who feel the sting, when we have just the one job (or worse, are called in to fix or enhance an existing system, and don't own the programming software already). I feel your pain. It seems everything costs money these days. (You know they've been working on how to collect so-called "micropayments" for internet software and services. Prehaps one day there will be a charge for each keystroke and/or mouse click)

Rufus

If you were to buy enough hardware at one time I am sure AB would give you the software. Of course, if you had a group of programmers developing a set of programming tools, help files, providing techincal support - would you want to be paid for it? Yes, it is about profit, isn't that what we all do, provide a service or function for profit? Of course you don't have to buy their software, just pay someone else to do it for you. The last VAR I worked for got their AB and Moscad programming tools for free, they sold a lot of harware, they also got very good deals on the IFix packages as well - because they sold a lot of systems. I don't know about you, but the investment is cheap compared to the cost of having someone else do the work for you and then not be around to support it. Plus, having the software in house gives you another service to sell to your customers and makes you a more rounded field engineer.

Matthew Hyatt
Technical Consultants
matthewhyatt@msn.com

Take all the letters of the English alphabet. Assign each letter to its position times 6 to create a simple code where A=6, B=12, and so on. Look at the words "Computer" and "Allen-Bradley" and substitute these values for the letters. Add up the values and what do you get?

666

Kinda spooky to think that now I spend half my work time programming Allen-Bradley computers!

It kind of makes sense too... the computer, after all, is the ultimate indulgence of the original sin... eating of the fruit of the tree of knowledge... oh no... my PLC5/80 just became self-aware...

P.C.
:)

Check out http://www.splatco.com.au
FREE software and firmware updates...

...why not just download free IEC 61131-3 programming tools and simulation?

Whre to go? Here: http://www.infoteam.de/index.php?file=article&mode=entry&numbe r=26

Dr. Brendel,

But will the code run on any real PLC?

Meir

I've Seen this subject over and over, and what exactly is the point that your trying to make with this statement? For usefull Usable Software in the PLC industry u PAY for it, there is no AD-HOCing it together,

Explain you debate??

Needless to say, I'd rather not pay anything for development software. However, as a PLC systems developer I look at the cost of this software as a tool to do business. For us it doesn't really matter since one software package will be used to develop many projects. I am sorry for the small manufacuterers with a few PLC systems and a large engineering staff who have to buy multiple copies and site licenses to satisfy their needs. Large manufacturers with systems numbering into the hundreds do not have the same problem of scale. Like I mentioned before, the development software is a tool like any other and the tool's manufacturer is entitled to set his own prices. In free market socienty, if a product's price is outrageous, a competing product will eventually emerge.

Hans Halpern, Anik Systems

Until there are viable alternatives, what choice do you have?
But, if companies and individuals were willing to invest just a very small amount of "sweat equity" into a shared solution you would have the option of using the sum of these investments at no further charge. Even though many seem to grasp the benefits of partnering with other firms, there is little recognition that many together can do almost anything with honest cooperation.
OSS provides the framework with the GPL to make this workable without fear of exploitation or other downside. You give a little and get a lot and open vast opportunities for code and experience sharing. All on the non competitive areas of your solutions. The status quo tends to isolate users so that all are required to reinvent the wheel and solve the same issues and the same information is sold over and over. Skipping this part of being in the automation
business simply has to improve profitability.

Regards
cww

Full Disclosure :^) http://mat.sf.net

Heck with that, I'd like to make more as a developer at $11.75. all programmers get the same rate, hell I know more than all of them. Including VC++ /VB/VBA Borland C++ Etc. etc. i'm sick of this.

I'm prob looking for a new job.

Your sentence structure is a little confusing, but are you saying that you're a capable, experienced industrial software developer and you make $11.75/hr??? If so, either your estimate of your own value or your employer's estimate is WAY off (like by a factor of three).

I agree, I have NEVER heard of a developer with those credentials making $11.75/hr. No wonder he is looking for another job!!!

Geez, I dont believe this post for a min. I mean a programmer is supposed to be smarter than that. If he got up to goto work as a programmer for $11.75/hr he got what he deserved.

Sweat equity is great if your looking to get back something for your effort, kind of like starting a buisness, everyone puts in long hours, works for peanuts, the brass ring comes when sell the business or do an IPO, I have yet to meet someone who does it for no ROI. I don't know anyone who works for free, if they do, they don't need to work in the firstr place. Unless your suggesting that we all volunteer our time to support this open and free program development tool, still by show of hands, how many software developemnt engineers and professionals out there are willing to work for free, say 300 to 500 hours per year for the next 5 years, oh, you get nothing in return, just the satisfaction that you created a development tool worth millions and will not get anything for it, nothing, nada, zip!

The reasons companies charge for this is because they have invested the time and manpower into the development tool. Our entire society and 99% of business' are founded around profit (money) and until this aspect of society changes - money goes away and everything is free, people and business' will charge a fair market value for their services. If you want or need something, ie... a tool, some software, music, a car, food, electricity, well you have to pay for it. You can choose to purchase these things or not.

Bartering is fine, but you still get taxed on the goods and services and from what I have seen, you wind up spending money anyways. Nothing is free, except the air we breath. I don't mind giving time to help others make a better life for themseleves, but I am not into giving away my engineering expertise and consulting services for free. Those are skills I developed with my own sweat equity, now I am reaping the rewards of that hard work and sweat.

MJH

Great Idea - I'm up for it.

As for not getting anything, I would expect that we would wrest some control of the industry and point it in the direction we want.

Most of the work has already been done, There are ladder and SFC editors already out there, add to this the comms already reverse engineered, all that is needed are plc specific compilers and we'd have it. Then the PLC manufacturers could compete on the quality of their equipment, rather than 'a locked in user base' with expensive software and experience of specific programs.

--
Marc Sinclair
http://www.germainesystems.co.uk

The Siemens S5 CPUs are extensively documented, including the memory maps and
the binary representation of each STL code. Unfortunately, this is not true
for most other PLCs.
--

************************
Michael Griffin
London, Ont. Canada
************************

Yes, that's the prevailing view. But I don't understand the no ROI part. If you recover the total cost of partnering with an AB or a Siemens, for example, and recognize that even the part of the cost your customer pays for directly could go to your bottom line, it would
seem like a fairly good ROI, especially with today's margins. And if done as a project for your company, I assume you would be paid. I don't understand this recurring "work for free" part. As it is, you get paid for your hours, any millions it's worth typically belong to the company. If the company invests effort in OSS, it really doesn't change anything except their bottom line.

Now, if you contribute on your own time, as many do, no $ ROI might be true. But some of us enjoy it more than say, Golf. But the real value of these platforms would be to the small and medium size companies and if they get together and share a little of their talent, the payback is far more tangible.

Regards

cww

Developing software requires time and people and both of them cost money.
Granted, some manufacturers may be overcharging, but they still deserve some
compensation. I guess you do not mind working for free, but when I write
software for a customer I expect to be paid for my services.

If your company invested in OSS and put you on the project would that square things? No one has suggested that the automation work for customers would be free. Suppose you had a "Software PLC" that belonged to your company that you could deploy on commodity hardware at no cost. Wouldn't projects using that potentially make more money for them and perhaps you? And wouldn't you be in a good position to really know it and support it? There are ways to do this where no one goes without. You really don't make money on the vendor's part of the equation, they do.
Right now, the vendors exist on the fact that rolling your own is not very economic for most shops. Not all, our hosts and I, in particular, find it doable at least. But most shops can't or won't so they pay up. But if you spread the cost of a solution amongst enough shops, it soon becomes more economic than buying the usual fare. So, you can use it to provide solutions in the normal fashion, except that you actually own it, can know everything about it, can fix it and can even improve it if desired. And you can't be forced to upgrade or be declared obsolescent or denied support or other BS like that. At that point it becomes much cheaper for you and your customers. Since it's based on Linux which shares the same attributes, is simply eliminates much of what is bad about the status quo. It would certainly have some problems, but now you have far greater control over how, when, and if you deal with them. Sounds like a good deal to me.

None of this involves working for free if the shops each take a tiny risk and invest a small amount for their future. And the collective smarts and experience in the trenches are far greater than any one company can point at developing a solution.

Now where am I thinking wrong?

Regards

cww

Year number 5 of this topic...

One last time, I get paid to keep machines programmed and running. My company supplies me the TOOLS of my trade. They pay for them not me, no tools, no work, no profit.

Our company core competence is paper making, mine is automation programming, and someone elses is automation tool building.

You act as if the software to program is coming out of YOUR pocket, focus on your core skills and I choose to know my machinery and a battery of tools to make it run better, faster, stronger.....

Rant on........

PS... ladder isn't dead nor Windows as predicted, lets move on.

Dave

Hi Dave

I am focusing on my core competency. I would like much better tools and a wider variety of tools to work with. And some significant variety in price point. And I would like systems that work together and reflect the advances in technology. Greater flexibility and extensibility and the ability to pick and choose for "best of breed" solutions. Knowing how each bit really works would be really helpful as well. Making the transition from Linux and FOSS to one or two automation platforms has been like going from a fully equipped machine shop to a rusty file and a vice. With a blindfold.

Regards

cww

Hi,

You're missing the point, the fragmentation of the industry is holding it back. A common point for programming, IEC1131 was the start, we need to take this a step further by removing the need for SPECIFIC programming packages. I am heartily sick of the "we only use XXX PLCs
because our technicians know (and have) the programming software (and leads). As a designer I want the freedom to use the best of the worlds' hardware. As it is I have to use the hardware manufacturer specified.

I envisage PLCs evolving to the point where they could accept (store and compile) the source code as simple text. leaving us, the programmers, to use any tools we choose. (paper - notepad - vi). The existing programming software producers could sell any number of front ends ladder or sfc, as long as it ended up with this exchangeable source
code. This would allow other people to produce software under whatever terms they wish.

The hardware manufacturers would then have to compete on quality and features, new manufacturers could enter the market easily and bring new ideas and competition.

We are all in working the gutter - but some of us are looking at the stars

--
Marc Sinclair
http://www.germainesystems.co.uk

> You're missing the point, the fragmentation of the industry is holding
> it back. <

Unfortunately, as much as this makes sense from a user/developer standpoint, if you look at it from the PLC manufacturer's it doesn't work. Since they (the manufacturers) are the ones making the programming systems, that's what we're going to have for quite a
while. -- The PLC market (unlike the PC market) is a (relatively) fixed size (growing, but not comparatively slowly) and so what we've got is the companies all trying to slice the same pie up with their piece being the largest. The other thing they're trying to do is keep the slice (customers) they already have... this means having proprietary systems that require customers to keep their
investment high, thus locking them in.

> I am heartily sick of the "we only use XXX PLCs because our
> technicians know (and have) the programming software (and leads). As a
> designer I want the freedom to use the best of the worlds' hardware.
> As it is I have to use the hardware manufacturer specified. <

You and me both!

> The hardware manufacturers would then have to compete on quality and
> features, new manufacturers could enter the market easily and bring new
> ideas and competition. <

Yep... see the problem?

Alan LeVezu
IDAC West, Inc.

Yes, exactly! Which surely leads to the conclusion that any solution will have to be based on a completely different paradigm to change the rules and break the deadlock.

This is where the Linux PLC idea came in. You won't see anything different from Big Automation because the same chains that bind their customers, hang about their necks. They have been trapped in the same "All brand X" trap and the way out is probably prohibitive in this economy. But with the most modest of support, collectively, users can
break the chains and have an alternative that is based on Open Stantards and software that _they_ own, running on the wealth of low cost, commodity hardware available. A very small amount of cooperation from the community could drastically change the course of events. And, once the chains were broken, very few would wish them forged anew.

Regards

cww

<clip>
> You're missing the point, the fragmentation of the industry is holding
> it back. A common point for programming, IEC1131 was the start, we need
> to take this a step further by removing the need for SPECIFIC
> programming packages. <

IEC61131 didn't really try to address needing a specific programming package for a particular PLC. It was simply an attempt to standardise the general look and feel of the common programming languages. To do what you have stated above would require standardising the actual run-time software.

> I am heartily sick of the "we only use XXX PLCs
> because our technicians know (and have) the programming software (and
> leads). As a designer I want the freedom to use the best of the worlds'
> hardware. As it is I have to use the hardware manufacturer specified. <

I doubt that you would avoid the above stated need to use customer specified hardware, as this is a spare parts and repair issue. This is no less true for PLCs than it is for valves. However, if all PLC hardware used a common run-time, you would not have to buy (and learn) all the different programming packages in order to deal with them.

> I envisage PLCs evolving to the point where they could accept (store
> and compile) the source code as simple text. leaving us, the
> programmers, to use any tools we choose. (paper - notepad - vi). <

Siemens PLCs evolved to this point long ago. You can export and import ASCII text for IL (STL) from (at least some of) their programming packages. You can't write in ladder logic using a text editor though, which is what most people would want.

> The
> existing programming software producers could sell any number of front
> ends ladder or sfc, as long as it ended up with this exchangeable source
> code. This would allow other people to produce software under whatever
> terms they wish.
<clip>

I think that to have what you really want would require:

a) A standardised file format for PLC programs. This would allow different programming packages to open the same files without running a "conversion" routine on them first. This includes the handling of symbols and comments, as well as the actual instructions.

b) A standardised "virtual machine" inside each PLC to run the resulting code. All "standards compliant" PLCs would accept the same binary byte codes and treat them in the same fashion. This would permit the programming packages to target a single run-time. Compatibility only at the source code level would still likely result in a separate programming package for each brand of PLC, as part of this package's job is normally to down load and debug the.

The greatest degree of compatibility would be for everyone to use the *same* run-time system, but this would probably only come about by the use of some form of soft logic system (possibly a GPL version).

--

************************
Michael Griffin
London, Ont. Canada
************************

Sure you can. I've been doing it on SLCs for ten years and counting now. I've even automated generation of some of the code (Word and Excel macros and VB code). I'll admit that RSLogix (the current RS product, which is supposedly derived from Icom's old offering) isn't quite as clean to do this with as APS used to be, but it still works just fine.

I believe that the latest iteration of DirecSoft (Automation Direct.com's package) now support ASCII code import/export as well. I saw something to that effect in the menu on the latest version, but haven't had an A-D project where it would have been advantageous to try it.

Indeed, and with the trend towards proprietary hardware becoming very much like a PC in architecture and resources, the X86 standard and the very egalitarian and guaranteed Open, Linux OS would seem to be an extremely rational and logical platform to start with. It would be hard to imagine better choices except from monopolistic or "customer control" viewpoints. If the people who can consistantly produce a new competitive, reliable, PC design every 6 weeks were focused on our market for X86 based PLC form factor hardware using existing and well established standards, all the criteria for change would be met and the industry could get moving again. It could be very close to economic to dump proprietary systems in many cases.

Regards

cww

Oh, you poor thing.....
To hard to learn something new ?? I worked with many different PLC's over the last 30 years, and you know what.... They're all basically the SAME.... Doesn't take a rocket scientist to figure them out.

Wake up and try learning something !!

When your TOP-DOG in a field u can charge whatever u want...

Until the vendors start offering your service.

Regards

cww

As the original author of this thread, let me clarify something.

To develop a PLC, one must design hardware, write an operating system and develop a programming interface. You cannot have a PLC unless you have all three parts.

With our company, the cost to develop our programming software is covered as part of the cost to develop our PLC hardware...therefore there is no additional or separate cost for the software.

I understand with other larger companies they account for cost and identify profit centers differently than we do.

But as the customer, you should be asking - how can you have one without the other. PLC programming software has only one purpose. So if you are buying the PLC... isn't the price of the PLC covering the development cost of the
programming software?

Just thought I would redirect the focus back on the original question.

God Bless,

Stephen Luft - President
Entertron Industries
3857 Orangeport Rd.
Gasport, NY 14067
Tel: 716-772-7216
Fax: 716-772-2604
web: www.entertron.com
wwjd - wdjs

As you said, some companies account differently for their R&D however it should also be noted that there is an ongoing R&D for most of the bigger companies and this allows owners of older CPU's to derive the benefits of
innovations on up to date programming packages they would otherwise not have been entitled to as at the time of purchasing a CPU they had already payed the relevant development portion.

If I compare Siemens first offerings of the Step7 programing package to what we have today, it is chalk and cheese. The Siemens programming package is of course also used for numerous other tasks such as PDM and programming of operator panels and text displays so it is perhaps not the most relevant comparison, however is an explanation of why it is additionally important for Siemens to market the Step 7 apart from the PLC hardware.

Cheers
Donald P

I tend to think of a PLC as a fairly ordinary embedded class computer with some really weird and unusual programming which forms a strange virtual system that you program in terms of relays. Which is to say that similar software will do the same thing for other, rather ordinary
computers. It's even not particularly challanging to write software that will do that for several different computers. Tying the two together is hardly necessary and if not a scheme to sell one with the other it is at least an artificial constraint. Considering that the hardware part may well be the most expensive small computer ever seen outside of NASA, generalizing the design to allow running on your choice of commodity hardware seems like an excellent passtime amd a boon for those paying the bills. Unbundling, as we have seen in many venues, is a great solution for many ills from the consumer's standpoint. If the hardware houses that produce high quality hardware in vast quantities inexpensively could see the market that quality unbundled software could create, we could address a far larger class of solutions not practical today. And competition in both fields would be greatly enhanced as you wouldn't have to make the whole package as the price of entry.

Regards

cww

Hi Stephen,

Rather than look at it from the developer/vendor point of view, look at it from the customer's.

Under your model, I, as a customer, realize that some percentage of my purchase price is going toward the programming software. There will come a point in volume where I don't want to be paying for what I've already paid for ten times over, and will want a discount reflecting the fact I've already more than paid for the development
software. Or I change to a vendor with a different model, who charges me for the hardware alone.

Amortizing your development costs over sold units overall is great for the low volume integrator.

However, the high-volume integrator may prefer the other model: buy the development software and only pay for hardware for each additional unit.

(The graphs for the breakeven points are left as an exercise for the reader.)

So it boils down to, whom do we cater to? The high volume user or the low volume user? Who would YOU rather cater to?

Additionally, you have to decide how you are covering your support costs for new users. The amount of support a volume user requires is certainly not proportional to the amount of hardware units purchased.

Unit one for both of them requires the most support. After that, support costs are negligible. Particularly for (e.g.) the OEM machine builder that is shipping 10, 100, 1000 or more identical units.

Rufus

Looking from the standpoint of the customer, and seeing your product, sorry AB wins

Why do you pay for PLCs for that matter?

We are working on an expanded program for a free release of automationX (http://www.automationX.ca). We already have a program for one year, 300 points at no-charge.

We've proposed to our board a free-release with IEC Function block/programming editor, the real time Soft PLC & database, and the HMI (displays, alarms, trends) in an object based environment.

I would like to see more people sit down and use our software and trust the PC's as comprehensive full scale PLC/DCS systems. Not just a application here or there with proprietary hardware doing the bulk of the work.

It would be a real eye-opener for those that do. If making a free downloadable verison of automationX accomplishes this goal, then that's what we want to do.

It will be interesting to see how popular this program will be, and if we do substantially increase usage.

Regards,

Paul Jager
President,
www.automationX.ca

Stephen,

There are a number of firms who make (or made) PLC programming software that are quite independant from the hardware maker. So how do you propose they are to make a living. On the other side due to some beta testing work I have some good insight into the operation of one of the major PLC makers and their software guys are not happy working for a hardware manufacturer, they feel (are)
misunderstood.

If you can make it work in your area - great, you have an advantage. I still long for Icom, they made great software, were responsive and nobody begrudged them for making lots of money.

Hugo

Yep. That's the way we see it. http://www.opto22.com

-BH

Actually, if all the vendors of the various PLCs would make their units compliant with ladder, C++, VB, assembly langauge text style programming, FBs, we could buy one general purpose programming tool (a cross compiler) and you could program your heart on your PC in a windows driven format (or whatever type of OS you have), download to any PLC the code you have written without having ot buy theie specific programming software. This will not happen for a least another 4 to 6 years, and by then the PLCs we use to taday will be so outdated that they will be boat anchors. By then of course the PLCs will 1/3 the size, 4 times faster, 4 times more powerful and will probably have pick and place graphical programming blocks for standard functions such as timers, PID control, I/O management and embedded communications protocols.

This already exists. B&R Industrial Automation makes a PLC that runs on Pentium Processors. I use them in my factory. They can be programmed in C and C++. They do charge for their IDE but the flexibilty of using C makes that 1500 bucks worth it. I have used AB, Siemens, and Omron. They have decent hardware but they lock you into proprietary languages. All controls guys that are not intimidated by high level languages and OOP should check this company out.

One thing is very clear. If you want to use software, you need to pay as its development comes at a huge cost. Also from Allan Bradely point, I feel its bad if they charge after a year any license fee. I will recommend you to use ABB or Siemens PLC where there is no license fee

Allen-Bradley (Rockwell) does what they want, and if you don't like it, go elsewhere! They are well paid for their marketing (and their products). The consumer CAN have the final say though.

Now that
-Westinghouse is only a name in a history book, -Square-D and Modicon are parts of Schneiders inventory,
-GE is the outfit that does jet-engines, locomotives, and labels on medical equipment
-Texas Instruments (who?) and ITE were outfits that were able to get some money out of Siemens,
Who's left in the USA?

It's simple competition.

AB users need to simply refuse to be railroaded. NAMM and other industrial associations need to quickly develop a VERY SIMPLE standard specification. One that demands backward-compatibility, modularity and/or scalability, and inclusion of programming software (and license) with each CPU. That's pretty simple.

If the puffin projects got some serious backing we'd see changes.

We also need some serious hacking of AB software. Maybe I just need to check WinMX or Gnutella or KaZzaA ...

You may want to have a look at the Horner PLC equipment. I have used lots of it (as well as lots of AB). It has more features than any of the others I have tried. Most models come with a built on display. This makes building applications very easy because the display software and programming software are the same package that use the same db.

The upper level models come with compact flash memory similar to the new compact logics except with the Horner you can:
1. Load programs to the controller
2. Save the programs to the flash from the controller
3. Save process data from the controller to the CF on .csv files that you can read with xl.

See http://www.heapg.com for more technical details.

The company is based in the USA.

The programming software for the controllers is free.

They pay for thier software development from hardware sales.

They also have a free 24/7 technical support hotline.

What do you think of these concepts? Refreshing isnt it?

Rod

There are alternatives. I personally can rewcommend the control micro systems Scada pack. The programming software is free. the technical support is very good. The unit uses industry standard modbus or dnp3 communications and by using available protocol converters you can talk to anything Alan Bradely has to offer. They also carry their own Scada software Clear scada which does a very good job of talking to their controllers.

Seeing that no one has posted here in a while, I figured I would bash AB for a minute.

Consider the Drive Explorer Software for $365-$385 (not the freeware version that does nothing, I'm talking about the "full blown" version that does nothing).

Compare it to Unisoft etc. by Emerson CT, BTW Free. Compare it to ConfigEd+/Lite by Parker/SSD drives, BTW Free.

I once heard an engineer say Delta Tau Data Systems motion controllers are designed by scientists for scientists, that made me think about my friends, AB, designed by fools for fools.

Do the world a favor and go buy a real drive/motion system and leave the AB to rot. They will eventually drop motion just like they did the CNC market and the Vision market...what's next reliance?

I agree fully, with your remarks about having to pay for yearly subscriptions etc..

Unfortunately it is the case, companies have to have a return on their investments (which is typically in the hundreds of millions ￜ) and therefore make yearly subscriptions etc.

However, normally the yearly subsciptions include updates (with Schneider) which i believe are very important. Those updates are not bug fixes they are for the most recent versions.

I am unsure about Allen Bradley but im sure it should be the same way, if not i would consider moving to another supplier.

As a small user of PLCs, the price of the software drives me nuts. Sales reps come around touting new hardware and its benefits. They give a price which looks quite inviting. Then once you've decided that it is something you are interested in, they drop the bomb. Sure I'd like to use the hardware, but I can't because I can't program it without the gazillion dollar software package. If I was using several of the same type of PLC in a plant, it would be quite easy to buy it. But, as a one off for a small company, it doesn't happen. The contracting company quite often decides what PLC it wants and I have to program it. I can't invest in every programming package a customer wants. If I add it to the price, the customer shops somewhere else, quite often at a vendor specific company that can spread the price over a larger number of installations. If any PLC company wants me to use their hardware, they should at least make it cost effective for me. Provide a basic programming package. If they want to have a multiplatform package for a premium that contains extensive support so be it, but they should at least allow smaller purchasers to at least access the features of the hardware they purchase. If giving the software away means adding to the price of the hardware, then so be it. I don't want to spend $1500 to program a $2000 PLC. I know programming costs $ but why should my small purchase have to support developement to keep the prices down for the larger corporations that have loads of PLCs installed. Then to top it off, I quite often have to buy a programming package to support an older PLC for which a programming package has already been purchased. The program is quite often on 3-1/2" floppy and can't run in todays Window environments or has become corrupted over time, and guess what, no support any more. "I'm sorry, you need our new xyz programm for $10000000000000000." I'd like to see a company step into the marketplace and do it right. If they offered their softwarw free with the hardware, they would blow the competition away for a few years until everyone caught on that it actually does work to operate this way.

Comparing the PLC programming to PC operating systems isn't the same either. I have the option to put any operating system on my computer that I want. I can use Linux or several others which are free, or I may purchase Windows or others which have a cost attached. I do have a choice. On a PLC, there is no choice. I have to pay the price for the software from the vendor that supplied the hardware or I can't use it.

All the automation companies invest a lot in R&D of softwares. How do we get them back?

There are man hours spent for generating the Software for every project. Company pays salary for them. How do we get them back?

When an automation project is Proposed, the software engineering cost is very much considered in the budget. And the same is projected to the customer.
So no shock when you are claimed for the software services, ok!!

PLC Editing Software- you generally get what you pay for. Control Logix has the ability to manage large projects effectivly. We just did a job with about 25 PLC ( Logix 555 )in one area, networked to 2 PLCs in a second are area, with 6 more Logix in a third area. All are attached via ethernet to a DCS. And we can dril down into any of them via RS Logix5000 from anywhere. Also the diagrams, tagnames i/o card info and status are all available online. and you can do online changes etc.

Most of the cheaper PLCs just can't do that with their software. so don't even try.

Do you want to read the health of i/o cards? Logix can do that, so can many DCS platforms.
But most cheaper PLCs do not support that information. I can charge people $75 an hour to troubleshoot cards in the field, or they can log in over Logix and see what is happening directly.

Lee Ward is right, if management has a $ 5 million process they do not mind spending $ 20K for software to do the job right. After all the President of Ford Motor Company just got paid $ 28 million for 8 months work, and Ford is going broke right now and laying of tons of people. Yet he is rewarded . So clearly companies do not care about $ 20K for PLC software. They deal in millions of $$ . I have installed dozens of cheap plcs and they work very nicely, after your fight with them a bit. Analog inputs seem to be the most problematic.

But- Essentially you get what you pay for.

This topic seams to drag on for years on our list... as well as the open debate.

Bottom line is I agree with this post... as someone put it on the list about PLC programming, chopsticks or Chopan (spell) both are piano playing. Same thing with PLCs, in order to have all the cool features of ControlLogix requires a huge outlay in support and R&D. You get what you pay for, it costs money to run huge development facilities and support places. I have done work with RA all the way back to AB days and ICOM before AB actually knew how to make their own software. The only way to support enhancements and updates and improvements... i.e. UDTs, User function blocks, 1163-3 support, etc. And anyone who has had RSLogix 5k since V1 knows how many IMPROVEMENTS have been made.

If you have ever been to Milwaukee or Cleveland and seen usability labs and their software facilities and the people working to make things better, you start to understand the costs. Open PLCs in my humble opinion will not make it for a long, long time as there is a big difference between PC users wanting free open source stuff and Engineers who, as this poster said, do not care what the software costs. It is a cost of doing business... and it is about 1/10th of the DCS world. Maybe we need to start OpenDCS first as that is where bigger costs are.

Bottom line is it costs money to make things safe and to support features, I get a little nervouse about running say an ethanol plant with "cheap" PLCs to save a buck.

My humble farm kid opinion...

PS: Lots of chopsticks players and PLCs out
there...

Dave

Yes. Open DCS would be an excellent for today's hardware and software capabilities. But don't say it too loud, or someone will implement it with Visual Basic on Windows and we'll have to listen to people saying OpenDCS is crap for the next 20 years. The talent pool would be a problem with few OSS developers interested in DCS. But AutomationX gives a glimmer of how this should be eminently doable if the MS folks don't poison the well. The average desktop, programmed properly, is far more powerful than many successful DCS platforms. With bad PC software, an old VAX would be a better choice.

Regards

cww

As we see, this is a long and ongoing discussion, with no easy answers. I like the ideas that Wuollet has expressed about an open platform. In the PC world, Linux and other applications revolving around the linux platform have developed into some very nice stuff. I could see that working in the industrial arena, if it were TRULY open. Still the sad reality is that you do get what you pay for, and the lower cost packages do not offer as much nor are they as robust and user friendly as the high dollar packages. most problematic.

But- Essentially you get what you pay for.

I'm not too sure about that. The best cross-platform C compiler in the world, bar none, is free. And it would be difficult to argue that the Linux that runs our new 6 million dollar press is worth nothing because it's free. And I would love to hear how I am losing out running Linux rather than Vista. It obviously serves all my needs and lets me do things that would be either prohibitively expensive or in many cases impossible with the spendy stuff. That is an absolute contradiction with the concept that you get what you pay for. You get what they want you to get when you pay for it. I feel totally under equipped when I sit down in front of Windows. It has nothing unless you pay for it and the equivalent to my free Linux installation would be at least tens of thousands of dollars in the shrinkwrap world. That is why I find that argument rather silly. It's all a matter of perspective. There are very few high buck applications that I find impressive and fewer still that I could justify spending _my_ hard earned bucks for. I could, quite comfortably, do all that I need, or want, to do with what I can get free. I will use what is provided, but the difference between the most expensive and the least expensive options for PLC programming, for example, makes it hard to rationally justify the high priced spread. My situation may well be different from yours, but it's not _that_ different. Supporting a dozen brands of PLCs does wonders for your perspective.

Regards

cww

I'm sure that an astonishing number of man hours are lost worldwide due to having the to rewrite and debug logic for so many different PLC brands. Machine builders and system integrators shoulder the cost of supporting so many PLC brands, but in the end we all pay for it.

I don't typically have to write code for all of them. Whenever I have a choice(new work), I use AB or AD to keep things sane. But, just to connect to and maintain the varieties we have requires an unbelievable array of spendy gadgets and weird connectors and the PC software mess is unbelievable. This accounts in part for my very dim view on the lack of standardization, besides the fact that it's just plain stupid.

Every vendor writes software as if it's offering is the only thing you will ever run on your machine and I don't think any two can use the same cable. Some brands require a different lashup to talk to each model. To look at the big picture, one could easily come to the conclusion this was all planned by lunatics or anarchists to destroy industry. But it's passed off as "innovation" and tolerated as "competitive". And some deluded individuals even praise and "celebrate the differences". Imagine how much would be accomplished if pipefitters or mechanics had to deal with such "competition" between vendors.

Regards
cww

They do........................have you ever used an ODB scanner on a vehicle.

Every manufacturer implements the "standard" differently. And I do not think you can compare "pipefitting" to industrial automation. That would be like comparing a house to the international space station.

Dave

I don't know ... I'm bad at mangling quotes, so I looked this one up.

Alfred North Whitehead [Introduction to Mathematics (1911); English mathematician & philosopher (1861 - 1947)] said, "Civilization advances by extending the number of important operations which we can perform without thinking about them."

Its only my opinion, but I think we ought to be aiming for exactly that (Curt's pipefitting analogy) as industrial automation progresses.

I know what he's talking about regarding the multiplicity of cables. I'm up to about 40 *different* programming cables/comm adapters to support various PLCs, HMIs, motion controllers, and whatnot in our plant, and since some of them (for instance, standard DB-9/DB-9 "straight through", standard DB-9/DB-9 'null modem', Ethernet patch cables, etc.) are used for several different interfaces I'd guess we're supporting more than 50 types of gear.

It is interesting to examine the history of how this multiplicity came about, but as automation technology matures we need to be shooting for simplification. I'd be a very happy camper if all I needed to do was carry around, say, a single hunk of fiber optic cable, and know it would connect together all my X's to all my Y's without pain and anguish.

Yes, but that's wrong too. And they have cleaned that up a little bit with ODB2.

Regards
cww

And THAT was the promise of IEC-61131 .. the only hope is that everyone uses 3S software and keeps the file formats the same .. and then I woke up ....

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

Basically the problem still exists but a practical solution is nowhere to be found. We really need the equivalent of the IBM PC and ANSI C for the PLC world.

True enuff Bill .. IEC was supposed to be the Ansi C.. but the hardware guys wont let it happen. Crater tried with the Puffin Project .. at the end of the day people just want stuff that works..

Until the rest of the world catches up with legacy pensions, and high wages, and the 1/4 to 1/4 profit mentality, we'll be in tough.

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

You don't want to wish that. It takes about six months of sitting in a cubicle littered with 2000 or so caffinated beverage containers to fully understand how to work the symbolic debugger of just one ANSI C compiler implementation. IEC programming enviroments are a walk in the park compared to that.

I think most engineers here have seen enough computer programming languages or PLC instruction sets to pick up a new one up within a few hours or days. It's the development environment that takes time to understand and that problem is not solved by a common language.

Sorry - I was misunderstood.. I was more referring to the generally accepted way of programming, instruction set, compatibility between compilers, etc.. not that control programming should be as funky as C programming...

I have reviewed many software packages, and I would agree that the interface can be challenging. IEC based packages arguably provide a similar interface. The target hardware quirks is what I find the most 'uhhhh' factor:)

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579

I believe what Mr. Pollard meant was that ANSI 'C' is a good example of a programming standard that actually works. You can take a program written in ANSI 'C' and re-compile it with a different compiler on a different platform, and have it compile and run with little or no change to it. This is what people want to be able to do with PLC programs written in ladder or IL.

Tru enuff MG... Thx :)

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Look at the products page for Trinity Integrated Systems @nowhere to be found' ;-)

First of all I do support dozens of PLC's.

Second, it is not my money.........and

Last, if there was only one PLC (openPLC), then everyone would be an expert (your theory) and you would make $1.26 per hour (on good days).

Maybe that is fine with you......................but once again
Curt.............my 7 or 8 or 10 years on this list and we keep having the same old arguements...........over and over.

In the meantime I've made a fortune letting someone else pay for the tools for me to use and I just keep solving their problems with the tools they buy me. Whether it is Seimens, Fanuc, AB, ABB, GE DeltaV, Provox, I/A or any of the other 100 systems I have touched. etc., it is the process knowledge that is worth money, knowing the paint sets (and they are all virtually the same when you get outside the box) just raises that bar (er um paycheck).

Companies need someone to hold responsible for their issues and Open has no someone, I still think (and have been correct for 10 years) that it will not catch on as people want to make money and get paid for their services. Maybe
year 11 will bring the big change (I doubt it).

I am a painter, the paint set isn't that important to
me......................It costs me zero and I actually enjoy learning different systems (sort of sick).

PS: We will be having this conversation again, and again, and again....................

Dave

There doesn't have to be only one PLC, I just would like to see them compete on who could make the _best_ PLC with a particular world interface rather than the much simpler task of making the _only_ PLC with a particular interface. We simply don't need any more functionally identical diversity.

Regards
cww

I agree that PLC software is often grossly overpriced- however the difference,for example, between RSlogix and DirectSoft is very similar to the difference between $3500 and $350. RSLogix is a far better, more user friendly package. I feel like I'm being robbed every time I buy something from AB, but the product (especially the software) is far superior to its cheaper brethren.

What's your time worth?

The price paid for good software is returned many times over if it saves hours of programming time. The extra time it takes to program with junky software more than makes up the difference in cost between them. Multiply that by multiple projects and the expensive software gets cheap real fast.

Not to pick on GE, but the Versapro and Cimplicity software suck compared to RSLogix. That goes for most of the other programming packages I used as well. Obviously, I haven't used them all, so the observation is a bit of a generalization, but in the long run I believe I more than make up the cost difference by reducing the programming time significantly.

There are a lot of 3rd-party software companies that make their living creating enhancements to existing software. They manage to sell it by demonstrating a ROI in labor savings. Note companies like ECT schematic development program that ran on top of an Autocad license. That's a double license whammy and it was still sold as cheaper (faster, error elimination, panel layouts, BOMs, etc.) than doing schematics in Autocad alone.

What's your blood pressure meds and mental health worth? I have purchased RS Logix out of my own pocket (no company re-imbursement) and don't regret it for a second. The frustration saved alone is worth it to me. But, different strokes for different folks. If you are happy with what you are using, then "don't worry...be happy." And have fun with whatever cheap (to buy - expensive to use) software you are using.

Another perspective.

Bruce A.

RSlogix is without a doubt the cream of the crop as far as programming packages for PLCs goes.

I can say that with some certainty having used a lot of them.

Some are really awful, others merely poor. Some like S5 are truely a challange to even use at all. Others hold a lot of promise (S7 and Concept come to mind) but never seemed to ever mature like they might have.

On Apr 28, 2007 7:48 pm, Bob Peterson wrote:
> RSlogix is without a doubt the cream of the crop as far as programming packages for PLCs goes. I can say that with some certainty having used a lot of them. Some are really awful, others merely poor. Some like S5 are truely a challange to even use at all. Others hold a lot of promise (S7 and Concept come to mind) but never seemed to ever mature like they might have.

CWW: Hi Bob,
S7 seems to me to be the logical extension of S5. These are a very different take on usability. They must make sense to someone. I am not that person.

On Apr 28, 2007 5:15 pm, Bruce Axtell wrote:
> What's your time worth?
>
> The price paid for good software is returned many times over if it saves
> hours of programming time. The extra time it takes to program with
> junky software more than makes up the difference in cost between them.
> Multiply that by multiple projects and the expensive software gets cheap real fast.

CWW: I don't know that everything other than RSL is junky, actually I find them all somewhat unstable, but most are productive enough once you get used to them. I think RSL is really popular with Windows fans but some others are at least as productive if you can type and are used to keyboard accelerators. I can't really say bad things about the DirectSoft stuff, it's pretty fast for me after a few projects. The
Mitsubishi stuff is still pretty clumsy for me partly, because they use different terms that I would expect.

Bruce Axtell: Not to pick on GE, but the Versapro and Cimplicity software suck compared to RSLogix. That goes for most of the other programming packages I used as well. Obviously, I haven't used them all, so the observation is a bit of a generalization, but in the long run I believe I more than make up the cost difference by reducing the programming time significantly.

CWW: I agree on the newer GE software. But I can really move with the old LogicMaster90 Many Windows fans dislike it, but once you know the keys, it goes pretty fast. I've kinda settled on a solution. I won't buy any GE hardware that won't work with LM90.

Bruce Axtell: There are a lot of 3rd-party software companies that make their living creating enhancements to existing software. They manage to sell it by demonstrating a ROI in labor savings. Note companies like ECT schematic development program that ran on top of an Autocad license. That's a double license whammy and it was still sold as cheaper (faster, error elimination, panel layouts, BOMs, etc.) than doing schematics in Autocad alone.

CWW: You can do much the same if you try to reuse elements and putz a little with AutoLisp. I don't use AutoCad anymore. It's pretty hard to justify unless you are selling equipment. I use XSchema or QCad on Linux and QCad works on Windows too. Schematics are really pretty simple CAD. The list and BOM tie in is nice if you have it. It wouldn't save me a lot of time these days.

Bruce Axtell: What's your blood pressure meds and mental health worth? I have purchased RS Logix out of my own pocket (no company re-imbursement) and don't regret it for a second. The frustration saved alone is worth it to me. But, different strokes for different folks. If you are happy with what you are using, then "don't worry...be happy." And have fun with whatever cheap (to buy - expensive to use) software you are using.

CWW: I have it, at the companies expense, and there is a stocking AB distributor nearby. So, I use it. If you have AB PLCs around, you really don't have any choice. But in my consulting business, I'd have to have a lot of work lined up before I'd buy it and pay the protection racket to keep it up. If someone absolutely demanded AB and I could make it a line item, that would be fine. But you have to really make some money with AB equipment to come out ahead. I would prefer that I make more money per job than RA. Bidding both ways, a lot of folks would
probably like the AD price better than the AB price and the end result would be the same as far as I have seen.

Regards
cww

I think Dave Ferguson has a pretty good viewpoint on this subject. Sure everyone would like an open standard, everyone would like the PLC manufacturers to be better and more open with the ability to use a "world interface". We have to remember though that companies like Modicon, AB, Siemens, et al, and their expensive R&D is what has enabled us, thus far, to work in the automation field and make fairly decent money while doing so.

Without their innovations we might still be wiring lots of relays. This discussion isn't going away- It's probably a healthy thing. But one has to ponder "Is it changing anything?" And so, let the discussion continue......

In reply to Kevin Cooper: I don't see what R&D has to do with language standards. Few if any of the vendors are doing any R&D on programming languages.

I believe that the real problem with this ongoing situation is that customers are losing a lot more from it in wasteful duplicated training and lost productivity than vendors are gaining from locking in customers. This is a net economic loss, not just a re-distribution of revenue.

Automation software is stuck in the equivalent of what was the early 1960s for the computing industry and will remain there until some very deep rooted problems are addressed in this industry. Every automation project involves re-inventing the same wheels over and over again in different proprietary languages. The development of specialised re-usable libraries and techniques which have been the key to advancement in computer programming is not happening in PLC programming because there are no common languages to express them in. The shear wastefulness of it all is appalling.

I would have to say that given the current situation, even a bad standard that was supported by everyone would be better than no standard at all.

I agree that we are stuck in time, and something needs to change, but I disagree that a bad standard is better than no standard. I don't see that IEC-61131 is visionary by any means, but rather it is a collection of loosely coupled band-aids that is trying to appease the masses but really doesn't please anyone fully. The reason people use standards is that they are good ones, and someone leads the way, and the rest have to follow.

There are so many added features and legacy crap thrown into IEC that reading the standard is rather sickening. For instance, who really uses all of the action qualifiers within the SFC language? Its set up to do machine control in the low level, but everyone I've talked to says things like "SFC is good for high level control", which really means: "SFC is piggy and resource heavy, so only use it for high level organization."

The late 70s and early 80s was a time when brilliant engineers and programmers crafted a lot of groundwork and were able to get paid well for it. Management didn't quite know how to get their claws on software at that time so things were able to flourish in the underground of corporations. Now with tight budgets and poor investment in R&D, how are things going to evolve? I think we are at a crossroads, but I really don't know which way things will go.

~Ken

In reply to Ken Emmons Jr.: I probably phrased my previous message poorly. By a "bad standard that everyone supported", I meant a standard whereby even if the language features were not ideal, it was at least a standard that was used identically by everyone. A standard can be improved over time. At present, we really don't have one as just about anything can be called "IEC-61131-3 compliant".

I do not agree that "the reason people use standards is that they are good ones". There are many cases where it is less important that we have an ideal solution than it is that we have a common one. Think for example of railway gauges. "Standard" gauge isn't ideal for all applications, but the advantages of having a common gauge usually outweigh the disadvantages of a less than ideal gauge for any individual line.

Of course I would prefer a universally accepted "perfect" standard, but that doesn't seem to be on offer by anyone at this time either.

As for whether "SFC is piggy and resource heavy", that is an implementation problem, not an inherent characteristic of the language. The problem with many implementations is that the particular target PLC was never designed to directly support SFC, so the missing PLC functionality has to be emulated with large blocks of IL. The quality of any auto-generated code is usually very poor when you have a large semantic gap between the language and the underlying platform.

SFC is a form of Grafcet, and so isn't anything new. Indeed, nothing in IEC-61131-3 was supposed to be new. It was supposed to just winnow down existing practise to a smaller consistent set. That unfortunately, didn't happen.

Actually Michael this thread is about "Why do you pay for PLC programming software?”. I was simply trying to make the point that it would be great to have a free, open, and standarised plc programming platform. The reality though (for now) is that it isn't happening. With the divergence of this discussion it is apparent that it won't happen soon. At present the best plc programming software that I have used has probably been the most expensive, while the worst has been approximately the least expensive. Obviously development costs have a lot to do with this. It seems that no one really wants to develop a package that programs everything, has every bell and whistle, and is wide open allowing others to tinker- all for free. A primary difference in the plc market and the pc market is that there aren't millions of programmable controllers sold everyday. Not everyone has them, or even knows what they are, so it's a bit of a niche market.

In reply to Curt Wuollet: I've used QCad for electrical schematics. It most definitely does the job. However, what is "XSchema" that you refer to in this context? The only reference I can find to it is as an XML "Document Definition Markup Language", which I am sure is not what you intended to refer to.

As an aside (and ever further off topic), my opinion on how standard electrical schematics *ought* to be done is that the simple standard stuff should be automatically generated from the BOM list, not the other way around. That is, I should be able to fill in a spreadsheet with all the devices and the I/O addresses where they will be used, and the schematic software should make the drawings for me. Simple drawings could be auto-generated by merging standard blocks into drawing templates. You would still need CAD software for the non-routine drawings. Things like I/O drawings though are very simple and repetitive, but make up the bulk of a drawing set. You may recall discussing this several years ago on this list.

I agree with your statement regarding schematics. I personally don't generate schematics for IO, but rather have an IO list that, when needed, refers to schematics for things that are not point-to-point. Having schematics that detail terminal block A-1 wires to Terminal block B-34 is really difficult to read, but in a table it is easy to refer to.

Wouldn't it be great if someone had the time and inclination to craft something like this in the OSS world. With QCad or some other OSS software package as the basis, a fairly barebones framework might just be the "Stone Soup" needed to get some folks each adding a gadget to allow mere mortals and sole proprietors to have powerful automated drawing tools. You might get snuffed by Autodesk, but I'm surprised there isn't more OSS CAD and verticals work.

Regards

cww who barely has time to read this list anymore.

In reply to Curt Wuollet: I have too many projects on my plate already at this time to look at doing something like this (automatic schematics generation). I took a quick look though at what is available to work with.

There appears to be someone who recently (about six weeks ago) started a project on SourceForge which seems to be somewhat related. The project description is: "Interkonekto is a program which draws interconnection diagrams from tabular data read in a set of text files. The input layout model and generated output drawings are DXF files, compatible with the original specification from Autodesk." There's nothing there yet, as he has apparently just started on this.

Independently of the above, I looked at what would be involved to do a project like this. The most obvious thing to do would be to let the user create "template" drawings with "dummy" block devices (e.g. sensors, actuators, etc.) using an existing CAD program in DXF format. These would have all wires, etc. already drawn in. They would also create drawings of I/O devices as blocks.

The user would then separately create lists of I/O devices together with the I/O addresses, the pages they want them to appear on, and the templates they want to use for each page. The program would go through the list, make copies of the template drawings for each page, insert the device blocks, renumber the wires and devices, number the pages, etc. This is more or less what most people do manually with their CAD software already.

Ideally, the substitutions would be done without the program trying to understand the actual drawing contents, except for re-writing the wire numbers and device names. The most difficult (or at least time consuming) part of this would be learning enough about the DXF format to do this properly.

Also ideally, the user created lists would be in a standard spreadsheet file (ODF ISO/IEC 26300 format is the obvious one). There is a python library called "py-odftools" which may be usable for this. The reason for using a spreadsheet to enter the data is that the concept is you are creating this list anyway for use in a BOM.

The above is more or less what I had in mind, but as I said I already have too much to do to look at it for at least a couple of years. If anyone else wants to give it a try though, they are welcome to use the above ideas.

I think that Allen-Bradley and Automation Direct could learn a lot from each other, but I don't think Allen-Bradley's products are better than anyone else's. I use both platforms. Logix has features I wish DirectSoft had, and DirectSoft has features I wish Logix had.

Aside from the features, there is no reason you should have to purchase separate software to communicate with your controllers after having already been raped on the price of programming software. Getting RSLinx to communicate with a controller can be a real pain. It's a breeze with DirectSoft. Rockwell gets away with it, which is exactly why they continue to do it.

You get a hell of a lot more for your money with Automation Direct controllers and hardware than you do with Allen-Bradley. The only reason I use Allen-Bradley is because they are the company's standard for use in the equipment I work on. I used solely Automation Direct in my previous department.

You also get free Tech Support from Automation Direct. Allen-Bradley wants you to pay a crapload for tech support, two craploads if you want nights and weekends. I've been saying "to hell with A-B" for years. :)

I think Cutler-Hammer is releasing a new line of controllers that should prove to be some good competition for A-B and A-D. Only time will tell.

Chris

On May 20, 2007 3:03 pm, Chris wrote:
I think that Allen-Bradley and Automation Direct could learn a lot from each
other, but I don't think Allen-Bradley's products are better than anyone
else's. I use both platforms. Logix has features I wish DirectSoft had, and
DirectSoft has features I wish Logix had.

[rap] Maybe you could list some of those features. I have found the Logix
software can do just about anything, but often the capabilities are not well
documented, and sometimes not real obvious.

[chris] Aside from the features, there is no reason you should have to purchase
separate software to communicate with your controllers after having already
been raped on the price of programming software. Getting RSLinx to
communicate with a controller can be a real pain. It's a breeze with
DirectSoft. Rockwell gets away with it, which is exactly why they continue
to do it.

{rap] the version of rslinx used to communicate from logix to processors is
included with the package. there is no extra cost. I get frustrated with ab
software from time to time. Most of the frustration is the poor
documentation and the abysmal search capabilities of the knowledge base.
just about every problem can be easily fixed if you can find the right tech
note, but finding the right tech note is a whole lot harder than it needs to
be. but if it was easy, there would be far less reason to pay for tech
support.

[chris] You get a hell of a lot more for your money with Automation Direct
controllers and hardware than you do with Allen-Bradley. The only reason I
use Allen-Bradley is because they are the company's standard for use in the
equipment I work on. I used solely Automation Direct in my previous
department.

[rap] I am not sure that is true. A lot of people compare apples with
oranges when they do price comparisons between AB and AD. Having done it
several times, I can tell you the hardware cost is not as far off as you
seem to be stating. And if a company is already using AB, the costs to
switch (training, spares, etc.) is not something to be trifled with. On most
projects a 5 or 10% difference in PLC hardware costs is not a big deal.

[chris] You also get free Tech Support from Automation Direct. Allen-Bradley wants
you to pay a crapload for tech support, two craploads if you want nights and
weekends. I've been saying "to hell with A-B" for years. :) I think Cutler-Hammer is releasing a new line of controllers that should
prove to be some good competition for A-B and A-D. Only time will tell.

[rap] The eaton line of PLCs seems like a heck of a deal. when you do not
have to support old products, you can do a lot.

In reply to Chris: The people who program PLCs all day long, and the people who program them once in a while often want different things from their programming software. The same goes for people who work on a few very large programs versus many small ones, or for people who build machines versus people who have to maintain them. Pretty often, the sophisticated features that some people like in their large, complex programming packages are exactly the features which other people hate the most.

And there is the need factor. The only thing RSLogix does that I need, is to program AB PLCs. Is that need worth 10x the price? Invalid question
really, because there is no $350 way to program AB PLCs. In the end, since all of the programming tools are mutually exclusive, the question really is: Is using AB worth much higher cost in every category than using say, Koyo? Will the total bundle do the job better, faster, cheaper? In most cases, I would say no. From scratch, definitely not! Until you consider the lock-in factor. If you must interface with AB or you have a plant full of AB, there is no question and no choice. I think that is why many people use AB. Most of our equipment suppliers, including those with some very large, complex, and expensive systems use something else. Mostly Siemens or Mitsubishi. And our latest big system uses no packaged PLCs at all, they use powerful computers running Linux, RTLinux or an RTOS. Apparently they did not find the value in using AB, so it's probably not worth paying 10X more in many cases.

Regards

cww

OK, Curt I will bite:

Lets throw in 200 analog loops, 15 drive systems, some motion control robotics and a bunch of "structured text" interfacing to an upper level ERP system and some batch and oh some backward compatability, some weigh scales. Add company wide spare parts and training for all of the shift workers to work on all systems.

I will take the AB solution and its cost over Koyo or AD and its cluge to pull this all off.

TOTAL COST OF OWNERSHIP not initial cost, and I can find 1000 AB experts in 10 minutes but not 1000 Siemens or Koyo in the US within driving distance of me. I will compare company wide TOTAL COSTS any day for our paper mill of roughly 75 interfaced systems. Now if you are a little skid supplier, maybe a different story, but it is still up to who you are selling skids to.

If all you need is a knife have at it, if you need a screwdriver, corkscrew, earwax remover and a toothpick... give me a McGuyver knife.

Right tool for right situation and future expansion.

Have a great day:

Dave

With all those loops, an ERP interface and scales scattered about, I can think of a lot better tools than PLCs to do this. But that's me. With all that analog and ports for scales and a dedicated Windows machine to run the interface bits, the AB solution would be kind of a kludge also. None of those are strong points for PLCs as opposed to a few 300 MIPS PCs in a cluster for a lot less money. And it would solve the question of PLC programming software. But, a kludge is in the eyes of the beholder.

Regards

cww

Curt:

Ah yes but who supports it.....................in the middle of the night.

You obviously have not done a large complex interfaced Controllogix project because if you had, you would not make such statements IMO. If you know what you are doing and design for total cost, you will have a hard time coming up with a better solution to tools set, and I have done many, many of them.

We should focus our opinions on things that we are familiar with not just "fighting the man". People turn to this list for more than opinions Curt.

Dave

I've experienced Rockwell's support in the middle of the night, and
I would much prefer something _I_ own all the information on.
In fairness, they can know very little about a particular system so
it's not their fault. But that means you are still going to get a phone
call, even if something of theirs is broken. In a pinch, I can get a PC
at WalMart and chances are it will run Linux, even old Linux. Or
if I'm really annoyed, I can press my bosses PC into service and
go home. Panelviews tend to be far less available in rural MN on
a good day. Believe me Dave, I understand your point of view and
I hear the siren song "let us take care of you" and lower, more softly,
"bring your checkbook". And, yes, you can do systems that way and
be successful. But there are other ways to do a system that have
other advantages. I have done systems "from scratch" and haven't
had the issues you worry about to any larger extent. In fact, those
considerations are the least of my problems. My biggest, no, _our_
biggest, problem with automated systems, is that someone else
(hopefully) has the information we need when it goes queep. Let's
take a poll on that. Show of hands? Anyway, I am seldom allowed
the time it takes to get that information. It occurs on different levels
so that even if I designed and built the machine, if I used packaged
systems, I still have that problem. If there's a comms problem or
a strange error or things don't work as advertised, I'm DIW. The
solution to that problem is obvious. Some people we buy machines
from are really good about realizing this and we get source. I try
to make it a deal breaker, but I'm not always successful. But
even then. there's a lot we can't know about the machine. I get
to fix the machines the vendor has given up on, when the other
choice is to take the loss and buy a new machine. This situation
is almost always because information is not available. Often
the problem turns out to be something that would not be a
big problem if the information was available. So, it's not very
effective to buzz about total cost of ownership, etc., the
really expensive part, the part that causes downtime and
even junks workable equipment, is the part that you don't
know. Your most expensive machines are the ones that
you know least about in any realistic cost analysis. Your
analysis is from the front end. Mine is the actual reality.
Secrets cost money, lots of money, and it's the invisible
elephant in the room that nobody talks about. It's not
"the man" I have a problem with. It's that their control
of information to maximize profit causes great harm
and expense to the people who pay me. Systems you
can know are a better long term investment. Open
Systems aren't necessarily the best way unless they
are extensively documented, but they are a better
way down the road and from an overall perspective.

Regards
cww

The analog control is very good and also built into the drives, the controller, and distributable. The motion is embedded, the ERP interface is embedded in the 61131 language set. Batch instructions (ISA 88) are built in, and sequencing is built in. And it is backward compatable to all of my old IO going back to 1980 (probably further), there are cable mappings to tie to my old Provox I/O. Aliasing ability to leave replaced controllers from other manufacturers documentation itact, ability to build and protect my own instructions, create my own data types, class based modules etc...............optimized data concentration of communications etc.

One software for all of the variouse forms of controllers...............etc. hard to beat without a kludge.....

Oh, and the Electricians are familiar with it and we have spare parts...............I will compare the TOTAL COST OF OWNERSHIP long term any day.

This is not your daddys PLC 5.................when you really dig into what this platform (Controllogix)is intended for, you will have a hard time coming up with a more complete solution but then that is just me.........what do I know. But then again if you are doing islands of automation stand alone with no interfacing then stick to the Yugo, but if you want to race......get the Corvette.

Dave

&Yeah, our electricians converse about that stuff in the first
paragraph all the time. :^). But yes, Controllogix is much
closer to what is needed than a PLC5 or a SLC. And AB
has done a reasonably good job of hiding the complexity,
which is their stock in trade. The problem is that at some
point the investment in AB knowledge is nearly what you
would have to have to simply do it yourself and use best
of breed OTS components. I submit that, other than the
system designer, a great number of the people involved
will never understand most of the system, if my experience
is at all typical. And you know nothing about the system
software because it's secret and you depend on AB for any
insight, which insight can be mighty handy when everyone
is out of ideas.

My point is that we are approaching the point with many
systems where the traditional advantages of PLCs are moot.
The number of people who have authoritative knowledge of
the systems is about the same as if they were full custom. At
that point, being able to know the whole system is a large
advantage. And I'm not talking about being able to check
the IO lights to find bad devices. Either way becomes
complex for a large system. At some point, well written
source code in a small language like C becomes much
more readable than huge blocks of IL or function blocks,
especially if some paranoid locks portions turning them
into inscrutable black boxes. In the end, you are going
to need a systems engineer for systemic issues and as a
practical matter, production and maintenance resources
are unlikely to be able to resolve all but the simplest
issues in a reasonable amount of time.

This is really about how to apply computers with 21st
century capabilities to complex industrial automation.
As you have no doubt noticed, big automation has
begun to diverge greatly on how to do this and keep
their flocks on board. This is a huge problem for
them as an awful lot of the flock really don't want
to become computer scientists. Pointer math,
indirection and object orientation are not
modeled well with relays. Well, maybe OO.
Pretty soon they will not be able to shield you
from much of the complexity, they will be it.

My viewpoint is that you will need to expend as
much time and effort to effectively use the new
systems as you would to become a C programmer,
and becoming a C programmer doesn't marry
you to a single vendor. It also lets you understand
the _whole_ system, provided you use Open
Systems.

What they are counting on is that familiarity and
comfort with past products will convince practicians
to stick with the devil they know, even through a
subordinating and underinformed learning process
for knowledge that will be largely non-reusable.
This is the new, even more powerful lock-in as
very few people will want to repeat the experience.
I am faced with the necessity of eventually learning
several of the new paradigms, the worst possible
case. Being a C systems programmer will help me
a lot more than all the ladder logic and product
knowledge I possess. So from my perspective,
it would be simpler and more cost effective to
use the same knowledge over and over again
than to try to cover a dozen divergent models.
But, marrying one company, for better or worse
is another way to spend more time automating
things and less learning them. If you can work
with only that one company, your position is
viable. If that is not an option, my perspective
begins to make a lot more sense. One thing for
certain is that automation is going to become
more balkanized rather than less, and the walls
are going to get harder to climb. Open Systems
may well be the only practical way to be a
generalist and not commit to a single vendor.
As an industry, I predict most will handle this
by simply walking down the chute provided
with the occasional moo or bellow perhaps,
but no thought of escaping the inevitable.

Regards
cww

In reply to Dave: You have used the term Total Cost of Ownership (TCO) a few times in this argument, so I thought I would point out a few things about it. The follow reply is rather lengthy, so I hope it adds some light to this conversation.

FIrstly, I understand that most people believe that pre-existing stocks of spare parts (which you mention) are not supposed to be part of the TCO calculation. This might be counter-intuitive, but for cost purposes these are assumed to be assigned to your current investment. Many people would also exclude training costs, as long as the amount of training required for either one is broadly similar (because training may be subject to a fixed annual budget anyway, or for other reasons).

Secondly, for smaller applications a simple PLC doesn't usually have any significant "ownership" costs outside of the original capital costs plus any recurring costs corresponding to maintaining the programming software. The latter factor (programming software) by the way can be significant enough for some brands of PLC that it can be cheaper to replace an "oddball" PLC than it is to buy software for it.

Thirdly, any genuine TCO is valid only for a specific application at a particular point in time. That is, in your application AB may have a lower TCO, while in Mr. Wuollet's applications, Koyo may have a lower TCO. You have to look at it case by case.

Finally, I wouldn't use the term "Total Cost of Ownership" if you want people to listen to your points seriously. You may not be familiar with the history of the term, but TCO originated in the IT industry. There it has been abused to such a degree that is considered by most people today to be more or less synonymous with "nonsense". In particular a certain large software company (I am sure that Mr. Wuollet could fill you in on the details of who) has been publishing numerous studies that "prove" their product has a lower TCO than their main competitor when everybody's experience has shown otherwise (for most applications). Since TCO is so sensitive to the initial assumptions made, you can prove just about anything you want by setting the assumptions. The analysis company that originated the term is primarily known for churning out "independent studies" that will prove whatever it is you pay them to prove (i.e., PR mascarading as fact). It is one of these concepts that sounds objective in theory, but is very subjective in practise.

I believe you have some valid points, but I would approach the analysis in a different way. Instead, I would use a more qualitative approach. I would start by listing the technical requirements of each application. For the larger applications, I would list the actual requirements (number of analogue loops, communications, interfaces, memory capacity, special function modules, math instructions, etc.). For the smaller applications, I would just list a range for I/O count and (if applicable) communications capabilities.

I would also look into whether the large and small applications should be considered separately from each other rather than linked together. That is, since you may end up with two completely different (and possibly incompatible) models anyway, then you might question whether both size ranges really have to come from the same vendor.

Once you have the technical requirements, then you can usually narrow the choice down to a few possibilities. You have to be careful doing this though, as it is very easy to let your own prejudices overrule your reason. I learned to program PLCs on AB hardware, so at one time I was judging other brands according to whether they worked the same as AB or not. When I was later exposed to Omron and Siemens hardware for a while, I found that a lot of my preconceived notions about them were wrong.

When you have your list of candidates narrowed down, then you can start to look at cost. And yes, initial capital cost is very important. If the cost of spare parts is really such a major consideration, I have to ask why do you need so many spare parts?

If you need a number of expensive special function modules or CPU models which have a long lead time for replacement, then I would assign them as spare parts for those specific machines and not count them into the general spare parts "pool". This adds a lot of clarity to your accounting for spare parts cost (general spares are items you use on a more or less constant basis, while the "special" items are more like insurance, which you hope you will never need).

Next, you have to look at the specific business considerations. What is the distributor like in your area? What are the real delivery times for the items you will actually use?

As for cost of programming software (the original topic), then this is something that needs to be seriously considered. At one time, programming software was something that you bought once and then simply used for the next 10 years. Lately however, it seems to have become a significant ongoing expense with a support contract required to be able to obtain the updates necessary to be compatible with the ever changing hardware.

Again, it is useful to divide this into use cases. For the sake of example suppose a plant has 100 PLCs, consisting of 5 large ones and 95 small ones. We might decide that between the needs of maintenance and engineering we need 4 copies of programming software. We might also judge that 90% of the use of the software might be on the smaller PLCs, and 10% on the larger ones (the smaller improvement projects might be done in house, while the larger ones might be contracted to outside resources).

Having looked at all this, we decide we need 1 copy of the software for use with the larger machines, and 3 copies for the smaller ones. If the cost of a software package is the same for large or small PLCs, then we find that 75% of the cost is for the smaller PLCs. So in other words, we have a strong cost incentive to look for low cost programming software for the small PLCs. Add several generations of hardware with corresponding incompatible software to the mix, and you have multiplied to cost as well.

In other words, when considering the cost of programming software, it may be more important to give greater weight to the smaller simpler cases than the larger ones.

So to sum up, we might have:

- Capital cost. Keep in mind this is important because it is something that gets spent on every single machine.

- Cost of spare parts. If this is a large cost, then something is seriously wrong. Also, don't get hung up on existing spares if you are considering making a strategic switch. Making a bad decision in the past is no excuse for continuing making it in the future.

- Business considerations. How good is the local distributor?

- Cost of training. Training might be necessary for the larger PLCs, but many of the smaller, simpler ones it might be reasonable to expect your personnel to learn whatever they need from the product manuals, plus a bit of practise in their spare time in the shop (small PLCs are cheap enough that you can set one up for this).

- Programming software. This has become an ongoing annual expense. You should look at how to minimize this by considering the use cases for small and large PLCs separately.

I would like to add some points which I forgot in my previous reply to "Dave" on this subject. Several more factors to consider about programming software costs are:

First, high programming software costs can have an effect on your ability to work with machine builders or integrators on smaller projects. Since programming software has now become a recurring expense rather than a one time cost, many smaller companies will only purchase the programming software when they have a specific project to budget it against. The software might then be used once, and then be out of date before they ever have another use for it, so they don't consider it to be an "investment" in the same way they would consider a machine tool to be.

A $5000 additional expense may not be a major factor in a $250,000 project, but it is for a $25,000 one. For smaller projects, this tends to limit the companies you can deal with competitively to those who already happen to have the software because of projects for other customers. This in turn has (probably unquantifiable) costs associated with having less than optimal solutions from a narrow pool of suppliers.

Secondly, if a copy protection system such as a dongle or a software "key" is used (these are common for the more expensive software), then you have to track these (and deal with the possibility of theft for installations on shared computers in a maintenance department). You also have to account for the risk of additional equipment downtime if the copy protection system becomes defective and you can't run the software. You are only going to discover you have a software problem when you actually need the software, so the need for the software and the failure of the software to work are very likely to coincide.

The third point to consider is the overhead costs of purchasing and tracking software licenses. If the software is provided free of charge, then the tracking costs can simply be ignored (just have several copies on hand and install them when and where necessary).

If however the software licenses have a cost beyond a simple charge for the media, then you have to track when and where each package is installed, what optional packages are installed where, the version level of each installation, the expiry date of each support contract, etc.

The tracking, budgeting, purchase approval, and paperwork costs all add to overhead. The higher the total software cost, the higher the overhead costs tend to be because as you cross certain monetary thresholds, you generally tend to require higher and broader levels of management approval, who in turn require ever more paper work justifying the expenditure (i.e., prove absolutely for each piece of software that purchasing it will save money in the fiscal year that expenditure is associated with - oh, and make sure you budget for this 18 months in advance). If however the costs are below a certain threshold ($200 to $500 is typical), then the financial approval process often falls under a much simpler process requiring minimal approval.

As long as we are talking about "total costs", then the above items should be considered as factors in our decision as well.

I agree..................Yes these are all part of my definition of total costs. We use automated tracking software, we have an internal database (a cost), we monitor it. We use "network" versions of most of the software with asset management software for "check in, check out" of licenses for portables.

To sum up, if you are a onezy, twozy OEM, or small systems location, it is a different arguement for total cost. When you are as large as we are with systems from a few I/O to systems with max I/O remote counts and numerous interfaced systems..............the TOTAL COSTS change.

My arguement in this case (Ours) RSI makes sense and with their newest systems (Logix inside) it makes even more sense.

On the other hand if you can support numerous one-off systems of varying fly by night vendors or Operating systems that the masses do not yet understand....................have at it. After all it is your money.

Have a great day.

Dave

see comments interspersed below pertaining to the May 28, 2007 2:10 pm by Michael Griffin:

MG: I would like to add some points which I forgot in my previous reply
to "Dave" on this subject. Several more factors to consider about programming software costs are:

MG: First, high programming software costs can have an effect on your
ability to work with machine builders or integrators on smaller projects. Since programming software has now become a recurring expense rather than a one time cost, many smaller companies will only purchase the programming software when they have a specific project to budget it against. The software might then be used once, and then be out of date before they ever have another use for it, so they don't consider it to be an "investment" in the same way they would consider a machine tool to be.

[rap] While there is some truth to this, it is also true that most of the time, the cost of bringing people up to speed on a plc system they have never used before dwarfs the cost of the programming software.

MG: A $5000 additional expense may not be a major factor in a $250,000
project, but it is for a $25,000 one. For smaller projects, this tends to limit the companies you can deal with competitively to those who already happen to have the software because of projects for other customers. This in turn has (probably unquantifiable) costs associated with having less than optimal solutions from a narrow pool of suppliers.

[rap] IMO this is not an issue. There are a bazillion companies that can do small projects like this. If one of them does not want to do it in AB, there is another one down the road that can.

MG: Secondly, if a copy protection system such as a dongle or a
software "key" is used (these are common for the more expensive software), then you have to track these (and deal with the possibility of theft for installations on shared computers in a maintenance department). You also have to account for the risk of additional equipment downtime if the copy protection system becomes defective and you can't run the software. You are only going to discover you have a software problem when you actually need the software, so the need for the software and the failure of the software to work are very likely to coincide.

[rap] this has never been a major issue anywhere i have worked, or with any of the many customers I have worked with. at worst, it is a minor nusiance as long as you suport is up to date. all the software venders that use copy protection have means by which you can get back online very quickly, with a few exceptions.

MG: The third point to consider is the overhead costs of purchasing and
tracking software licenses. If the software is provided free of charge, then the tracking costs can simply be ignored (just have several copies on hand and install them when and where necessary).

MG: If however the software licenses have a cost beyond a simple charge
for the media, then you have to track when and where each package is installed, what optional packages are installed where, the version level of each installation, the expiry date of each support contract, etc.

[rap] how is this any different than tracking other capital assets that may need maintenance over time?

MG: The tracking, budgeting, purchase approval, and paperwork costs all
add to overhead. The higher the total software cost, the higher the overhead costs tend to be because as you cross certain monetary thresholds, you generally tend to require higher and broader levels of management approval, who in turn require ever more paper work justifying the expenditure (i.e., prove absolutely for each piece of software that purchasing it will save money in the fiscal year that expenditure is associated with - oh, and make sure you budget for this 18 months in advance). If however the costs are below a certain threshold ($200 to $500 is typical), then the financial approval process often falls under a much simpler process requiring minimal approval.

MG: As long as we are talking about "total costs", then the above items should be considered as factors in our decision as well.

In reply to Bob Peterson (Tuesday 29 May 2007 17:53:29):

> MG: First, high programming software costs can have an effect on
> your ability to work with machine builders or integrators on
> smaller projects.
<clip>

> BP: While there is some truth to this, it is also true that most
> of the time, the cost of bringing people up to speed on a plc
> system they have never used before dwarfs the cost of the
> programming software. <

The problem I am describing is one I have had to deal with. Small, simple PLCs don't typically take that long to learn (especially if you don't use any of the esoteric features). I've never had someone object to having to learning a new PLC (in fact they usually said they would look forward to the opportunity).

These small machine builders said though they didn't want to waste their time on a quote they couldn't be competitive on because they would have to purchase the programming software specifically for that job. They weren't willing to cut their margins to pay for the software either (and I wouldn't want to be doing business with someone who was looking for ways to make up the loss). They were generally more concerned with the cash outlay than the manhours.

I would be asked if I could "give" them a copy? (answer - no, that's not legal, or it's copy protected anyway). Could I lend them a copy?
(answer - no, I don't have a spare one). The problem was eventually solved when the PLC vendor we had standardised on came out with a low cost programming package for their small PLCs.

These problems didn't occur for larger, more complex PLCs. Larger PLCs go into larger, more expensive machines, so the cost of the programming software was a minor item in the total quote.

> MG: <clip> For smaller
> projects, this tends to limit the companies you can deal with
> competitively to those who already happen to have the software
> because of projects for other customers. This in turn has (probably
> unquantifiable) costs associated with having less than optimal
> solutions from a narrow pool of suppliers.
>
> BP: IMO this is not an issue. There are a bazillion companies
> that can do small projects like this. If one of them does not want
> to do it in AB, there is another one down the road that can. <

You can find someone else, but your choices are narrowed. I would rather deal with the best companies for the job, rather than just the ones who happen to own a particular software package. This is a cost.

> MG: Secondly, if a copy protection system such as a dongle or a
> software "key" is used ..., then you have to track these ...
> You also have to account for the risk of
> additional equipment downtime if the copy protection system becomes
> defective and you can't run the software.
<clip>

> BP: this has never been a major issue anywhere i have worked, or
> with any of the many customers I have worked with. at worst, it is
> a minor nusiance as long as you suport is up to date. all the
> software venders that use copy protection have means by which you
> can get back online very quickly, with a few exceptions. <

I didn't say the problem was insolvable; I said there were associated costs. We were after all discussing hidden costs. The point was to highlight these hidden costs so that they are taken into account when selecting a PLC vendor.

> MG: The third point to consider is the overhead costs of purchasing
> and tracking software licenses.
<clip>

> BP how is this any different than tracking other capital assets
> that may need maintenance over time? <

See the point above on hidden costs. The discussion was about exposing all costs (it started with Mr. Ferguson's description of Total Cost of Ownership).

I love the reply.............reminds me of the "Apple arguement", its almost like this is my first trip off the boat. I have been doing this for 27+ years..........I understand total cost of ownership (and I do not use the muffled IT version of the term). Just becaue the term became a fashionable buzzword in the last few years and has been fudged, does not lend value to the concept. I do not HIDE costs in my version, I do not need to qualify which things count and which do not. Your explanation sounds like the IT version, most people this and most people that. Beancounter magic.

Just because I use the "buzzword" does not infer some NEW meaning that IT or the accounting dept. has brought forth.

When deciding on a plant and in our case corporate view of these systems, we take into account, initial cost (capitol), support costs, spare parts, support contracts, personel costs, training, and on and on. Most people hide, sluff, lie etc. Most systems have a cost benefit curve that spirals downward after instalation because they do not see this as living and breathing for its lifetime, it gets hidden in Maintenance department costs, or human resources etc. A quick example is Alarm Rationalization, most put it in and "Let her RTF, (Run to Failure). But the bottom line is if we did not have vendor "A", HR or Maintenance or Operations would not have to spend money supporting it, therefor it is a TOTAL COST.

As to the costs of support etc. This is a product in my opinion of flashable hardware being so prevelent. Because we can "enhance" controllers, we do and therefor version creap. Also as we move PLC control into the DCS arena, we incur the same issues those systems have with features etc. IMO Rockwell has gone a long way in backward compatability and the Logix platform (drives, PLC, etc) with its one software programming etc. has helped eliminate some of the arguements presented.

Bottom line, whether we like it or not, someone way back when decided on some equipment for our company. We can argue their descision all day long, but the bottom line is we are invested. So therefor we have legacy equipment to talk to, and spare parts, and an investment in training.

In the AB case, we have access to local support (if needed), or national support. And we can get on Google or Monster and have 250 people who have worked with it before. We also have MS based PC's and can get 500 people who can work on them if needed. Management wants that "safety valve" of being able to get someone if we cannot get it running and like it or not Linux people are not everywhere counter to this lists argueing.

Now I agree if you are a mom and pop with a few systems, it changes the arguement. But at a point af scale, it becomes something that MUST be considered. Most do not and most suffer with a hodgepodge of systems from the cheapest vendor.

Point in case the municiple water or sewer plant. I have been in many and they are a mess. The main reason.................LOW BIDDER. Initial cost instead of total cost.

I do not want nor will I be able to sell a system that I can not prove there is a large support structure behind. Even if we rarely use it. We need a one size fits all whether small or large system as in the end we must support them all. This means we use controllers that are way over powered in small systems because in the end the total costs are cheaper than being down at thousands of dollars a minute.

Lastly [MG]:"Finally, I wouldn't use the term "Total Cost of Ownership" if you want people to listen to your points seriously"

.....you assume people are not listening, from e-mail replies, I would argue it is the opposite. On this list for at least the last 5 years it is the LOUD minority that does most of the speaking, a few of us may know better.

Dave

I reply to DAVE FERGUSON (Monday 28 May 2007 14:15:53): My replies are
in-line with your comments.

> I love the reply.............reminds me of the "Apple arguement", <

I'm not sure what an "Apple arguement" is.

> its almost like this is my first trip off the boat. I have been
> doing this for 27+ years..........I understand total cost of
> ownership (and I do not use the muffled IT version of the term).
> Just becaue the term became a fashionable buzzword in the last few
> years and has been fudged, does not lend value to the concept. <

I suggested avoiding the term "TCO" because many technical people
simply stop reading when they see that phrase. While the concept is a
valuable one when properly used, the term itself has fallen into
disrepute because of its misuse by certain advertising and marketing
efforts in the IT industry. The same thing has happened to other words
and phrases in the English language. You have some points to make,
and I am just suggesting that you make them in a different way.

> I do
> not HIDE costs in my version, I do not need to qualify which things
> count and which do not. Your explanation sounds like the IT
> version, most people this and most people that. Beancounter magic. <

I suggested using a qualitative approach to the analysis for several
reasons. The first is that the hardware and software must meet the
technical requirements or else there is really no point in
considering it further. Cost calculations are pointless in those
situations.

Another reason is that in most cases people have to base their
decision on incomplete or imprecise data. Some of this is due to the
inherent problem that you are trying to predict future costs of
hardware you have no experience with, not quantify historical costs
for obsolete hardware. This applies to costs of business
relationships with new vendors. Trying to come up with precise
numbers from imprecise data is pointless. You are better off making
it explicit that you are using your judgement and making guesses
based on uncertain information.

One of the problems with TCO is that it is very sensitive to the
assumptions you make. These assumptions though get buried in the
details of the analysis while a seemingly solid and authoritatively
precise looking number comes out the end. This is in fact why certain
marketing departments are able to abuse TCO so much.

> IMO Rockwell has gone a long way in
> backward compatability and the Logix platform (drives, PLC, etc)
> with its one software programming etc. has helped eliminate some of
> the arguements presented. <

Now this is what I call a "qualitative" evaluation. If you have
equipment that has a long service lifetime (15 years or more), then
this can be a very compelling argument. You may need to replace some
PLC components over the life of the equipment, and dealing with a
vendor which has a history of maintaining backwards compatibility may
be important. If the equipment has a shorter projected life (5 to 7
years), then it may be less important.

> In the AB case, we have access to local support (if needed), or
> national support. And we can get on Google or Monster and have 250
> people who have worked with it before. <

This is another "qualitative" evaluation. It is also something where
the importance depends upon your particular situation. Large, complex
installations may need an "expert", especially if you are using a
special function module. The smaller simpler PLCs however are usually
not difficult to understand even if you've never seen them before.

> Now I agree if you are a mom and pop with a few systems, it changes
> the arguement. But at a point af scale, it becomes something that
> MUST be considered. <

There are two sorts of "scaling". One (which you seem to be referring
to) is where you have a few very large systems. The other sort is
where you have many smaller ones. Both have their own problems. In
many respects, a large number of small systems is more difficult to
manage than a few large ones. Each however tends to be a reflection
of the types of manufacturing processes being controlled.

> Most do not and most suffer with a hodgepodge
> of systems from the cheapest vendor. <

The "hodgepodge" and "cheapest vendor" problem is something that I've
seen more in companies that have grown very quickly. A small company
can often muddle its way through chaos, while larger ones cannot.

> We also have MS based PC's
> and can get 500 people who can work on them if needed. <

And I can guarantee that 499 of them aren't worth the cost of a phone
call. It's no good talking to people whose only experience is
installing MS Exchange servers or doing VB database clients. You need
someone who understands what you are even talking about when you are
describing a factory automation problem. That narrows the pool of
expertise down considerably.

> Point in case the municiple water or sewer plant. I have been in
> many and they are a mess. The main reason.................LOW
> BIDDER. Initial cost instead of total cost. <

The way I phrase this is "low price is not the same thing as low
cost".

> .....you assume people are not listening, from e-mail replies, I
> would argue it is the opposite. On this list for at least the last
> 5 years it is the LOUD minority that does most of the speaking, a
> few of us may know better. <

I'm not sure just what point you are trying to make here. I haven't
at any point said that the decisions you made with regards to the
equipment you are using are wrong. You are perhaps mistaking me for
someone else. I have just said that I believe that the decisions you
are applying to your situation don't necessarily apply everywhere
else. If you can find somewhere in this thread where I have said
anything against AB in particular, I would be quite surprised.

I have though said that I don't think a "TCO" calculation is the best
way to conduct an evaluation in most cases. For most people, a
qualitative approach is better provided they are willling to put
their preconceptions aside because it avoids putting a false
precision on uncertain data. If you have a good set of historical
data that can be different. Few people though have access to this
sort of data for multiple vendors.

You seem to be under the impression that I am arguing against
standardizing on selected components. Nothing could be further from
the truth. I've *written* equipment standards to do precisely this.
The only resistance I've ever seen against this principle has been
from machine builders and system integrators who like to push their
favoured suppliers because they get a better discount from them or
because they happen to have spent a lot of money on programming
software from that vendor. If a customer doesn't take control of the
situation, then they eventually end up with a plant that has one of
everything in it.

I've been programming PLCs, and DCSs system for quiet sometime. I have a saying for AB: "You can buy better, but you are not going to pay more."

I have to agree that software price has gotten out of control. They added so many features and tools and it goes on. Most of the time I just need a software to program the PLC. I don't need all the fluff that they are trying to sell. Sell a PLC give the software to program it.

Please give an example of "better for less". I haven't seen a system that performed better that Allen Bradley for less expense. If you are a DCS programmer you should really not be complaining about AB. DCSs are historically outrageously expensive. For example, a simple 8 point digital input card from Emerson is 50-100% more expensive than a 16 point input card from AB. So if want to talk about bloat, there is no richer environment than the DCS environment in which to find a target.

I agree 100%.................

Besides AB my other Major Skill Set (if there is such a thing) is Emerson DeltaV and my last major project had $200K just in licenses, let alone the software, the hardware and the Engineering and start-up. $1.5M project............this is nuts.

This is why AB has hired 200 former DCS programmers to go after Emerson. And version 16 is a good start in getting this business.

But I also agree AB is not cheap but I have not worked with a more complete system and a larger knowledge base in the US.

Dave

There is no comparison between a PLC & DeltaV. If you do not care about your process disruptions and process variability, then the loss of money does not matter to your company, then go with a PLC.

DeltaV will increase your production and keep your process running more reliable and reduce process variability in the product. This is what makes Companies money and not cutting corners with their control system operating the process.

All I can say to you is, bring it on, but you will never even touch DeltaV.

Ken

That statement is not verfiable. DeltaV system 'can' be very good, but so can well engineered PLC systems.
The real issue imho is the quality of the application engineering - the platform is less important in my opinion. And yes it is just as possible to make a complete mess of DeltaV projects as it is with PLC's.

Francis
www.controldraw.co.uk

Francis is absolutely correct on this one. I have installed PLC based systems which have stayed up for years, and I'm currently quoting to
*REPLACE* a DeltaV system with an Allen Bradley SLC500 system.

Now, I'll grant you that the DeltaV system was completely screwed up from the the beginning, and the guys who put it in were out of their league. But still, the customer is about to have a fit to get rid of it, and I'm certainly not going to risk the job by quoting him something he doesn't want.

--
Michael R. Batchelor
www.ind-info.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

843-329-0342 x111 Voice; 843-412-2692 Cell; 843-329-0343 FAX

I agree with you and your answer.

I work with both a lot and I can pretty much do anything in either DeltaV or Controllogix... I have yet to run across anything unable to do yet and we have some fairly complex stuff.

P.S. I used to think DV was the ticket... now I am a larger ControlLogix fan. And as I have said over and over on this list... "It is not the paint set but the painter."

Dave

I think this is a dead wrong answer. It is not the system but what you do with it.

I have DeltaV systems and Controllogix PLC systems and you cannot tell them apart (intentionally). We designed the same look and feel into each. And yes we are doing some "trick" "DCS" stuff in that old PLC. :)

This reply shows ignorance on the part of the poster. An "old iron" view of PLCs. Get out there and find out that your cheese has moved and the two worlds have merged in the middle now.

After all the DeltaV is just an Intellution HMI on top of a controller... been there and familiar with both.

Dave

Ken you made the statement “There is no comparison between a PLC & DeltaV”, with which I agree 100%. I have been involved with several implementations that engaged some of the country’s “premier” programmers. I have never been more under-awed as I was with DeltaV

I am generally underawed by the capabilities of any of the DCS systems I have played with yet they do have some features that are worth having, that a typical PLC/SCADA package does not implement very well. One of these things is enforcing uniformity in the way functions are handled. Alarm handling is much improved in the latest versions of SCADA packages I have worked with (like WW and RSView32) but they still have some way to go.

I do think the SCADA packages run rings around your typical DCS for data logging and access to the logged data.

I certainly feel sympathy for people who have 40+ different PLC / cable / software combinations to support. I'm at about 25 myself. In ten years of being a "controls programmer", Logix is the best solution I've got right now. Yes, cost counts. Yes, purchasing continually fights with Rockwell on pricing, especially when our customers tell us they are paying less than we are for Rockwell parts. (We're an OEM.) But it's a pretty darn good solution.

This isn't to say that there aren't other perfectly good ways to do things. I've got systems in the field running on Windows, and while my company has never shipped a Linux system I've seen plenty of them. Modicon seems to have vanished off the face of the earth, and now Siemens is the "other brand" we get requests for all the time. Does this make life diffuclt? Yes. What could solve it?

1) Every device should have an Ethernet port. Not as an option, but as standard. "But hey!" I hear you cry, "they can't just put free Ethernet ports on everything!" Someone can check me on this, but I seriously doubt that a serial UART is cheaper than an Ethernet MAC. Get rid of serial ports, put Ethernet ports.

2) Everything with an Ethernet port should have TCP/IP support. Throw UDP and SCTP in for good measure. Make sure there's a Web page for status and configuration. This should be obvious, but it's worth stating.

3) The top level protocol is the problem. It seems we're down to EtherNet/IP and ProfiNet as the majors. Modbus/TCP is still my favorite, but it looks like it was just a stop-gap for when Ethernet first started on the factory floor. I can live with this, except for one major complaint about ProfiNet (see 4 below)

4) Everything should be multi-platform. This is a serious failing of ProfiNet, which is based on DCOM, which is NOT a nice cross-platfrom protocol. I'm also talking about the programming software. I don't care if you use Java, C++/Qt, Ruby, or hand-coded assembly, but by god make sure it runs on Windows, Linux, and Mac. Pick a good way of doing this and you'll get all 3 for the price of 1, plus a bunch of other platforms like handhelds.

5) Funny how everyone's talking about "standards," when in fact there are only a handfull of companies that make PLC programming software. Obviously some of the big boys roll their own, but a lot of the small players are re-packaging a licensed product. Examples are InduSoft and CoDeSys. I find these both to be similar to Siemens Step-7. So really the only time I have to switch my thinking is going between Rockwell and anybody else. But I vastly prefer Rockwell.

Well, that was probably a completely pointless diatribe. I guess I just like the sound of my own typing. But I meant every word of it.

-James Ingraham
Sage Automation, Inc.

Really you mean Rockwell is the best solution you have been exposed to. There are manufacturers out there that are light years ahead with vastly superior real time Ethernet solutions.

Gazsi: "Really you mean Rockwell is the best solution you have been exposed to."

Absolutely. I would LOVE for someone to come along and show me a better system.

Gazsi: "There are manufacturers out there that are light years ahead..."

That one I'm going to disagree with. While there may in fact be someone out there I haven't run into, there certainly aren't any MAJOR players that "light years" ahead.

Gazsi: "...with vastly superior real time Ethernet solutions."

No Rockwell platfrom currently support any flavor of real-time Ethernet. However, this isn't really an issue for me. I've got quite a bit of discrete I/O and many variable speed drives running on EtherNet/IP with no problems. No, I wouldn't be able to do co-ordinated motion at 100 micro-second updates. Fortunately I don't need to for my applications.

Also, note that I said that Logix is the best "solution" I have found. I'm including hardware, software, and communications. I'm including controller, HMI, drives, I/O, and, yes, motion control. Importantly, I'm also including marketing.

-James Ingraham
Sage Automation, Inc.

Gazsi please give us an example. I've been looking for someone who is light-years ahead.

I keep hearing that kind of thing too. Snap I/O was presented that way to me by a number of people. Yet a customer of ours with thousands of Opto22 NODES in use, recently asked us to add some means of remotely resetting the ethernet adapters because they have had several that went off into never never land and refused to respond to the host.

Hi James,

Just wanted to point out that PROFINET does not mean you have to use DCOM. There is one appication within PROFINET (which is CBA = Component Based Automation) which uses DCOM but all the rest of PROFINET is not. Like I/O, motion control, safety, etc. PROFINET stacks and Dev-Kits are available on a variety of platforms from different vendors (Hilscher, Softing, GridConnect, Siemens...).

Hope this helps,
Karsten Schneider
PROFI Interface Center

Wow, it took me quite a while to read through all of the replies. Many valid points were raised, as well as some not valid issues. IMO, the first issue to deal with is PC based PLC control. Right now, and until a PC is as reliable as a PLC, this is a BAD idea. MTBF rates for PC's are worse than for PLC's. Secondly, dealing with GPL based products, there are liability issues in many industries that preclude management from trying "new" options. I also saw many references to ideas like sharing code, etc... In the interest of saving time and increasing productivity. This is a good idea, but, it would end up a lot of people using pre packaged code because it is easier, not truly better for the bottom line.
Automation when applied to manufacturing, packaging, etc, IMO is about inoovation, being the guy who through his ability to see into the process pull out extra productivity here and there. I get paid very well, but not because I am proficient with AB, Modicon, Seimens, Etc. I get paid well because my ability to find solutions is NOT dependent upon the platform I am using. SOme platforms make it easier to do things, some not so easy. But the bottom line is being able to deliver the solution. Improving the customers bottom line. I constantly challenge people I work with to find better ways to do things, to improve throughput. I dont see the problem with the toolsets we have, but the persons using the tools do not have the proper background to truly be an automation engineer. I personally think that every controls or automation engineer should be required to spend at least 1 year as a plant electrician or instrumentation tech so that he has a grasp on reality. So he has a better understanding of the REAL world. Yes, I am all for better tools. We live in a world that is moved along by the flow of money. Learn the processes you are working with.... Not just the tools.

Hi Nik,

> Wow, it took me quite a while to read through all of the replies. Many valid points were raised, as well as some not valid issues. IMO, the first issue to deal with is PC based PLC control. Right now, and until a PC is as reliable as a PLC, this is a BAD idea. MTBF rates for PC's are worse than for PLC's. <

Says who? With what documentation? And you would have to qualify "PCs".
The printing industry is non-typical in that they do a lot with PCs and
I've been
impressed both favorably and non-favorably. In comparison with say, brick
PLCs some PC setups compare very favorably. PLCs have a readily
discernable advantage over your desktop or notebook running Windows
for sure. But I have seen some running Plan9 or various RTOS or Unix
derivatives that I've never had to mess with. And I've had good luck with
Linux although it's too soon to tell for recent versions. And I had a
raft of
memory failures with the AB bricks. So, it's not that simple. A lot of PLCs
are very close to a PC in PLC clothing. The electronics inside are nearly
indistinguishable these days. Get rid of the HDD and add a quality power
supply and the difference would probably be moot for most applications.

> Secondly, dealing with GPL based products, there are liability issues in many industries that preclude management from trying "new" options. <

The same could be said for their most litigious commercial brethren.

> I also saw many references to ideas like sharing code, etc... In the interest of saving time and increasing productivity. This is a good idea, but, it would end up a lot of people using pre packaged code because it is easier, not truly better for the bottom line. <

Every time you program a PLC you are invoking pre packaged code.
Each token generates the same code. There's nothing wrong with
reusing code if you understand it and it does what you need.

> Automation when applied to manufacturing, packaging, etc, IMO is about inoovation, being the guy who through his ability to see into the process pull out extra productivity here and there. I get paid very well, but not because I am proficient with AB, Modicon, Seimens, Etc. I get paid well because my ability to find solutions is NOT dependent upon the platform I am using. <

That's exactly the point. The product sold is not the PLC hardware or
software
but the solution. So why the emphasis on vendor A or B? And if an
alternative
runs the same and saves everyone money, how does that affect the product
sold?

> SOme platforms make it easier to do things, some not so easy. But the bottom line is being able to deliver the solution. Improving the customers bottom line. I constantly challenge people I work with to find better ways to do things, to improve throughput. I dont see the problem with the toolsets we have, but the persons using the tools do not have the proper background to truly be an automation engineer. I personally think that every controls or automation engineer should be required to spend at least 1 year as a plant electrician or instrumentation tech so that he has a grasp on reality. So he has a better
> understanding of the REAL world. <

I think they should have even broader experience than that.
The problem with many automation types is that when all
you have is a hammer, everything begins to look like a nail.
So a PLC becomes the solution for every problem even if
a lot simpler and less expensive solutions exist.

> Yes, I am all for better tools. We live in a world that is moved along by the flow of money. Learn the processes you are working with.... Not just the tools. <

I can automate a given process many different ways. For some, a PLC is
ideally suited. But once you get beyond relay replacement and start
dealing with the physical world, serious compute resources and extra
electronics can make things much simpler. There are ways to attack
such problems with PLCs but the add-ons tend to be pretty weak and
run at PLC speeds. It's much easier to integrate PLC capability into
say, my machine vision system than it is to do the reverse. And add
a dozen barcode readers, a fast network, etc. and the PC with the
right software becomes a much better fit.

Regards

cww

In reply to Curt Wuollet:

With respect to what is the essential difference between a PLC and a PC, we had a discussion about this point on this list back in 1996 where Dick Morley (considered by most people to be the "father" of the first PLC) had the following to say about it: "I guess that the original concept of a PLC is that it is programmed with proprietary languages with proprietary tools and controls I/O through a proprietary protocol or bus system. It was even then a computer, but was not called that since it might scare off the user base, since they were not very 'computer literate' at that point."

Hi Michael,

I was speaking to reliability in that context, but the "just add ladder" system was and is a great help, to a point. And I, for the most part, can empathize with people who just want the simplest way to instantiate logic. After all, I never set out to become a programmer, it's what I needed to do to get my hardware to do anything useful. As far as it goes, ladder on PLCs is great and much, much easier than when I was writing in assembler or even machine code to make a microprocessor and some other chips test things. And it's pretty straightforward using graphical tools with ladder diagrams, possibly the easiest, most intuitive thing for a logical mind.

But then I used the existing tools on some very large and complex systems. Ladder logic is not for big programs, IMHO. It gets really hard to remember a few thousand lines. And then there were many blocks of IL. Guess what? IL is just a little worse than assembler. I was back to programming on my hands and knees. For a system of that size, well-structured C or Pascal or just about anything else would be easier to understand and work with than the "simple" PLC program. Add in a couple modules that are actually programmed in C and where is the advantage that PLCs provide on a small scale? And for C, all I need is vi. :^) At some point, you are going to need to become a programmer to deal with large systems. Once you have a library built with the low level stuff, there's not much difference in the complexity and code is at least as easy to read. If you're not scared of computers. :^)

Regards

cww

In reply to Nik Kinze (Tuesday 29 May 2007 21:16:12):

> Wow, it took me quite a while to read through all of the replies.
> Many valid points were raised, as well as some not valid issues.
> IMO, the first issue to deal with is PC based PLC control. Right
> now, and until a PC is as reliable as a PLC, this is a BAD idea.
> MTBF rates for PC's are worse than for PLC's. <

This depends upon what you are calling a "PC". For some people, this means the same sort of computer hardware they have on their desk, with the same operating system and similar software. I can agree with you if that is your definition.

However, many people simply mean a computer on which they can load their choice of software rather than being limited to a set of firmware packaged by the hardware vendor. There are "PCs" which are indistinguishable from traditional PLC CPUs. There are other "PCs" which are fanless, diskless, computers which should have MTBF rates
which are similar to traditional PLCs. Traditional PLCs derive their reliability from low component counts, low power consumption (which means low heat dissipation), and no moving parts. There is nothing magic about them however.

The main advantage of traditional PLCs is that they are a pre-packaged solution that requires no preparation before you can use them. If your problem fits what they do well, they are difficult to beat. The problems come when you try to make them do non-traditional things.

> Secondly, dealing with GPL based products, there are liability
> issues in many industries that preclude management from trying
> "new" options. <

GPL is just a software license that happens to give you more rights than most other licenses. Some vendors will offer you a choice of licenses (GPL or commercial) for the same product (MySQL is an example of this). No software vendor however will accept "liability" for your mistakes. Almost none (I can't actually think any offhand) will accept liability for their own mistakes. Read the license agreements that come with all software. You might pay someone a lot of money but they won't even promise that there is anything on the
disk. They generally offer no warranty and limit their liability to the cost of the physical media (typically less than a dollar).

> I also saw many references to ideas like sharing code, etc... In the
> interest of saving time and increasing productivity. This is a good
> idea, but, it would end up a lot of people using pre packaged code
> because it is easier, not truly better for the bottom line. <

Reusing code is the best known means of improving programming productivity and reducing errors. It requires standardised languages however, which is not something we see in the automation industry.

<clip>
> Automation when applied to manufacturing, packaging, etc, IMO is
> about inoovation, being the guy who through his ability to see into
> the process pull out extra productivity here and there. I get paid
> very well, but not because I am proficient with AB, Modicon,
> Seimens, Etc. I get paid well because my ability to find solutions
> is NOT dependent upon the platform I am using. <

I agree that we should be able to concentrate on solving the actual manufacturing problems. Unfortunately, many people see the particular skill they are selling as being their ability to manipulate the programming package of their choice or understanding the instruction set of a particular PLC.

<clip>
> I personally think that every controls or automation engineer should
> be required to spend at least 1 year as a plant electrician or
> instrumentation tech so that he has a grasp on reality. So he has a
> better understanding of the REAL world. Yes, I am all for better
> tools. We live in a world that is moved along by the flow of money.
> Learn the processes you are working with.... Not just the tools. <

The best PLC programmers I have seen are the ones with the background you have described. They understand what it is that people need to be able to do with their machines. The worst are the ones who see "programming" as something which stands on its own apart from the application. The same general principle applies to mainstream computer programming by the way, so this isn't something unique to our industry.

>Wow, it took me quite a while to read through all of the replies.
>Many valid points were raised, as well as some not valid issues.
>IMO, the first issue to deal with is PC based PLC control. Right
>now, and until a PC is as reliable as a PLC, this is a BAD idea.
>MTBF rates for PC's are worse than for PLC's. <

Nik, this is only true for non-industrial PC hardware! For instance... have a look to the control systems / displays of locomotives. Here are a bunch of PC compatible systems involved...
with remarkable MBTF rates.

>Secondly, dealing with GPL based products, there are liability
>issues in many industries that preclude management from trying "new"
>options. I also saw many references to ideas like sharing code,
>etc... In the interest of saving time and increasing productivity.
>This is a good idea, but, it would end up a lot of people using pre
>packaged code because it is easier, not truly better for the bottom line. <

I would only use LGPL based software for low level interfaces...

>Automation when applied to manufacturing, packaging, etc, IMO is
>about inoovation, being the guy who through his ability to see into
>the process pull out extra productivity here and there. I get paid
>very well, but not because I am proficient with AB, Modicon,
>Seimens, Etc. I get paid well because my ability to find solutions
>is NOT dependent upon the platform I am using. SOme platforms make
>it easier to do things, some not so easy. But the bottom line is
>being able to deliver the solution. Improving the customers bottom
>line. I constantly challenge people I work with to find better ways
>to do things, to improve throughput. I dont see the problem with the
>toolsets we have, but the persons using the tools do not have the
>proper background to truly be an automation engineer. I personally
>think that every controls or automation engineer should be required
>to spend at least 1 year as a plant electrician or instrumentation
>tech so that he has a grasp on reality. So he has a better
>understanding of the REAL world. Yes, I am all for better tools. We
>live in a world that is moved along by the flow of money. Learn the
>processes you are working with.... Not just the tools. <

Yes, why to study hammers if not knowing which nails they are good for? :)

Best Regards,
Armin Steinhoff
www.steinhoff-automation.com

Here, here... I agree 1,000,000% and have been shouting this same thing for many years on this list. My point exactly, solve problems not build tools or be biased by one tool or the other, they are just hammers, go hit some nails.

Dave

I am not understanding what is the problem. Isn't software part of business cost?

A awful lot of posts in this thread say something like "Good software costs money to make, you idiots! You don't expect an accountant to do your taxes for free!"

Curt has pointed out that there are counter-examples. An awful lot of the Web is running on Linux-Apache-MySQL-PHP (also known as LAMP). The GNU Compiler Collection (gcc) is in extremely wide use in an extremely wide range of applications. But let's but aside the viral, communist, whack-job GPL / FSF stuff for a moment.

Here's a partial list of development software that for-profit companies give away, with or without the source code:

Sun:
-Java Run-time Engine (JRE)

-The Java Developer's Kit, containing the JRE, compiler, run-time, debugger, deployment tools, and more. (Solaris, Linux, Windows, and Mac)

-NetBeans Integrated Development Environment. (Anywhere Java runs)

-Compilers and other dev tools (C, C++, and Fortran) for Solaris and Linux.

-The Solaris operating system.

IBM:
-Lots, but most notable is the Eclipse Project(a clever dig at Sun, if you'll notice). At it's heart an IDE, Eclipse is so big now it's hard to describe. Other companies also contribute finacially. (Windows, Linux, AIX, Solaris, HP-UX, Max)

Microsoft (yes THAT Microsoft):
-Visual Studio Express Edition for C++, C#, Visual Basic, etc. (Windows only)

-.Net / Common Language Runtime (CLR) (Windows only)


The Java Virtual Machine (JVM) and the CLR are at least as complicated as the internal software of any PLC.

Would anyone like to claim that ANY industrial automation software they have EVER seen is superior to Visual Studio or Eclipse?

Oh, another thing. I have dozens of routers, wireless access points, and stand-alone print servers they I deal with. EVERY SINGLE ONE OF THEM has a built in Web page for configuring and monitoring, without needing a special cable or special software.

The idea that "Nobody makes software for free" is patently false.

-James Ingraham
Sage Automation, Inc.

In reply to James Ingraham: To make a few minor corrections to some of the statements you made:

- Linux, Apache, GCC. Most of the active developers are paid by large and small companies (IBM, Intel, HP, etc.) to work on them.

- MySQL, PHP. MySQL is owned by MySQL AB. The main backer for PHP is Zend Technologies, whose other products are based around it. The main developers are employees of these companies. Having a "free" product does not preclude basing a successful business off it.


Eclipse is probably the best example of what you are trying to talk about. Most companies creating development tools for large scale software development base their products around Eclipse. Because the base Eclipse system has a free license, no one company can take control of it against the will of the other parties. This means everyone's interests are equally protected while they can still compete against each other on a level playing field. The Eclipse license allows these companies to produce their products as proprietary plug-ins (i.e. Eclipse itself is free, but a lot of Eclipse plug-ins for special functions are non-free).

Contrast that with Microsoft Visual Studio, which is a proprietary product controlled by a single company (Microsoft). There are companies producing add-ins for Visual Studio, but Microsoft can pull the rug out from under any of these companies at any time if they feel their corporate interest is better served by this (as happened recently for example to a small company producing unit test systems). Basing a product on Visual Studio is inherently risky as you are essentially handing over control to another party whose interests may not be the same as yours.

From the investigation that I have done, I believe that it would be possible to produce a PLC programming system as a set of Eclipse plug-ins. A ladder editor would be a plug-in, as would cross referencing, compiling, downloading, etc. An IL editor might be just another syntax for the regular editor, or it might be another
plug-in. CVS (or subversion, or whatever) integration would be already present (etc.).

There is nothing to stop any PLC vendor from deciding to base their next generation programming software on Eclipse. They don't have to get anyone's permission to do this; they can just go ahead and do it. There is also of course nothing to stop them from charging for each
plug-in. However, it would open the market more to third party plug-in providers or free plug-ins, so in that sense this would probably be a step forward.

Although the cost of programming and configuration software is prohibitive, I actually do not mind paying for both the hardware and the software. Where I take issue is with (especially AB although I am sure others are the same) the cost of technical support. When I have already paid an arm and a leg for software and hardware that supposedly works and for accompanying manuals that supposedly tell me how to put things together, I am expected to open my wallet again for technical support. Why is it that the equipment and software do not always work the way it is implied in the manuals? Other vendors, for automation equipment and other types have indicated that I get free support forever.

Just about the only thing that proprietary software and the policies that accompany it do better than FOSS is to transfer money from your pocket to theirs. Unfortunately, this overriding goal tends to be in direct conflict with the users typical goal of knowing enough about the product to productively use it. This gets particularly bad for old products (often just a year or two) when they won't even sell you the information you need. That's why I like FOSS. I get the source, I get the information, and they are both mine for as long as I need them. No one can make them obsolete or bend you over the barrel. I'm not sure what's so whacked about that, it simply meets my goals rather than theirs.

Regards
cww

Stephen, here's an even simpler answer... because of our litigious society it's best to "do business" with corporations having very deep pockets!

Just search the web for recent lawsuit settlements!

Phil Corso

Check out Siemens Step 7 Lite for programming S7-300 PLCs. Unless Siemens has added functionality to it recently, it is limited to the 300 family and it does not do Profibus/Profinet. But it is free to download at: http://support.automation.siemens.com/WW/view/en/24372175
And it will program using the S7-Basis languages of ladder, function block diagram, and statement list.

A thread that runs for almost 6 years... Must be something that keeps us busy. Well the facts are these: if you want to use a PLC, you should prepare to pay anywhere between $400 to $1800 for the software. If you want to use an operator panel, another $30 to $400 for software.

Then the hardware. Somewhere between $1000-$3500, depending on your wishlist. Some vendors have $99 PLC's if you want something REALLY cheap.

Why these prices? Some people - vendor related - claim that you get what you pay for. Well, if we look at the microcontroller business, all the players (Microchip, Atmel, Luminance, Freescale, Zilog, etc.) offer their software for free. That's right: for nothing! And you get an integrated development environment, and that means: editor, assembler, in-circuit-debugger support, programmer support, and best of all: a simulator. All incorporated in one software package.

Their policy is to sell hardware, and make it as easy as possible to use that hardware. A microcontroller sells for $5-10, so you must sell a lot to justify that, and so they do.

Robustness? Well, that is only for the HARDWARE, because ladder-language is quite simple to implement. Open your PLC and you will see what that means: opto couplers, varistors, snubbers, DC-DC converters and RFI end EMI filters. I/O modules are normally coupled to the bus by means of 573 or compatible bus-buffers.

Why does my last client force me to use Siemens? Well, he paid a lot of money on licenses, programming cables, converters and so on, so he feels obliged to keep on using it. My project files measure 1.8Mb for a 40 rung program. The project file for the operator panel (12 text lines with 8 variables) is... 13.6Mb. Sorry guys, but this is ridiculous.

For a former project I used AutomationDirect. 80 PLCs plus operator panels. Everything worked fine. No hang-ups, crashes or other troubles. Has been functioning for 8 years now. Project files are 360Kb for a 3000 instructions program.

By the way, AutomationDirect - formerly Koyo - used to build PLCs that where relabelled as General Electric (you can mix them, I tried it) and... Siemens!!! So robustness is no excuse.

Does anybody know why the unifying IE11000 language did not provoke cheaper universal programming platforms? The industry does not want to give up such a profitable business?

Greetings,

Edward

In the past few years, I've had the chance to use many PLC brands, which is somewhat unusual as most places tend to stick to one. But I don't see at all the differences that justify the disparity in cost. I've been "auditioning" small PLCs for individual machines and integrating them into cells and I'm moving towards AD as well. The reasons might surprise fans of the high priced brands. One is that, for what I am doing, the "advanced" lines are way overkill. Another is that AD generally understands that you wouldn't be buying it if you didn't need it and they have a track record of getting stuff shipped and on site when you expect it. Their other gear is pretty carefully selected not just for cost, but to do the job reliably. I have AB support locally and that's about it. I find AD's support more useful and I don't get shaken down for it. Of course for other people, who have different needs, the big bucks may be worth it. But the biggest point is that I have found AD's small PLCs to be _much_ more reliable than the Micrologix series. Yes, the AD software isn't as kewl as RSLogix, but I have far less investment in supporting their entire line than AB or Siemens. For some reason the spendy guys can't seem to ever use the same setup twice, and when you support several ages and types, you need cabinets full of expensive adapters and crap. A couple of simple cables, which they give you the diagrams for, and which use standard and readily available connectors, fit all the AD gear I work on. That's the way it should be, as the other crap offers _no_ advantage that I can see. In general, if the AD PLCs won't do it, there's a much better way to do it than with a PLC. So it is the total package and the thinking behind it, that has to align with what I am trying to do. The software is important, but what good is the most convenient software when you need it all the time to recover and replace failed units (AB)? Or if using the software is a lot bigger project than the job you are trying to accomplish (Siemens)? I like the balance struck by AD and the value. The spendy brands should examine their value proposition in comparison.

Regards

cww

I have 98 AB processors all either PLC-5 or Controllogix in about a 2-1
ratio with the PLC-5's being slowly phased out. They are all networked
together and have yet to have the following Curt quote happen...........

" but what good is the most
convenient software when you need it
all the time to recover and replace failed
units (AB)?"

I have had one processor failure in 19 years that was not recoverable and
this was the only "non-human" related failure I can think of in 19 years.
It was a recall chip failure that was a firmware issue.

But then again I do not use the "cheap" stuff. Let's not talk about
INITIAL cost of stuff and talk about lifecycle cost and productivity
costs. I pay more, but then again I have a single vendor training and
spare parts and backward compatibility. I cannot afford to find the
Siemens expert, the AD expert, the guy who can hook up the Brand - X skid
and on and on. We choose to run 24/7/365 with roughly 2-4 days long downs
a year. We have had a total mill down roughly 8 times in my 19 years there
where you could effect the total mill processors.

But then again this is a Paper Mill that cannot afford minutes let alone
hours of downtime........................................

Write back in 19 years and tell be about costs and failures, until
then................more FUD. YOU GET WHAT YOU PAY FOR........LONG TERM.

Dave Ferguson

Hi Dave,

> I have 98 AB processors all either PLC-5 or Controllogix in about a 2-1
ratio with the PLC-5's being slowly phased out. They are all networked
together and have yet to have the following Curt quote happen...........
>
> " but what good is the most
convenient software when you need it
all the time to recover and replace failed
units (AB)?"
>
> I have had one processor failure in 19 years that was not recoverable and
this was the only "non-human" related failure I can think of in 19 years.
It was a recall chip failure that was a firmware issue. <

I haven't had any such problems with the larger
AB PLCs either, But I have installed and replaced
at least 8 Micrologix in 3 years. Just recently I've started replacing them with Mitsubishi FX PLCs because some of the replacements were acting up. Your recollection on processor failure is as it should be, it just shouldn't happen. I'm not especially fond of the FX or it's software, but I can't justify buying a product with that kind of reliability issues. And these are small point count applications that aren't really economic with a SLC even it I had the room. I had the local support team look at it and tried the suggested filter and grounding, etc. I wish the AD in this class came with sensor power, they have better availability than the Mitsubishi, I can never get the lowest point count models from Mitsubishi.

> But then again I do not use the "cheap" stuff. Let's not talk about
INITIAL cost of stuff and talk about lifecycle cost and productivity
costs. I pay more, but then again I have a single vendor training and
spare parts and backward compatibility. I cannot afford to find the
Siemens expert, the AD expert, the guy who can hook up the Brand - X skid
and on and on. We choose to run 24/7/365 with roughly 2-4 days long downs
a year. We have had a total mill down roughly 8 times in my 19 years there
where you could effect the total mill processors. <

Yes, but when you are building a compressed air
economizer or some other low point count app you won't get the work if you propose a $2k PLC.

> But then again this is a Paper Mill that cannot afford minutes let alone hours of downtime........................................
>
> Write back in 19 years and tell be about costs and failures, until
then... more FUD. YOU GET WHAT YOU PAY FOR... LONG TERM. <

No FUD, I can get you the AB case #s.

Regards

cww

In reply to Dave Ferguson: The Koyo PLCs have been around for a long time, and they've seemed pretty reliable in my experience. Their smaller PLCs (which are their main sellers) are also pretty simple and quite conventional. I doubt anyone would need an expert to figure them out. The smaller Siemens PLC (S7-200) series are similar in that respect (although the S7-300/400 can be quite complex). If someone has trouble understanding either of these, I wouldn't let them near an AB Micrologix either.

I had an interesting conversation with a Rockwell person, who had been around for a long time.

He commented that it used to be that they (and others) used to build stuff with XXXX years of mean time between failures and that the components were of shall we say "A much higher class and lifespan than today".

He commented how now all of the vendors and electronic components are in his word "Off the shelf stuff" that will not last like the old stuff.

We were discussing how I had equipment that was 20+ years old and still running and that we had no plans of removing some of it. He said that people today are still assuming that the stuff they buy now is made the same. He said that a lot of stuff is built with the expectation that it will be swapped out in 10 years or less. I think there are a lot of people in for a big surprise down the road in obsolescence.

PS: He pointed out that it was everyone's stuff not just theirs...

Dave

In reply to DAVE FERGUSON: I've never personally had any complaints about the quality of AB's hardware. But then Mr. Wuollet's problems seem to be just with their latest smaller PLCs.

As for stuff lasting 10 years or less, that is a reasonable expectation for smaller PLCs in a lot of industries. The machines they go in end up being scrapped or rebuilt in about that time frame because that is how long the product they are manufacturing is in production. The problems I see with some PLCs (without naming any brands) is when the hardware doesn't even last a few months or falls about when being installed. And it isn't necessarily the "cheap" brands where this problem is the worst.

Even if the design is good, a lot of automation companies (perhaps all now) have outsourced production to whatever subcontractor bids the lowest. And sometimes the cheapest is pretty shoddy.

There is a big market in counterfeit electronic components in certain countries that assemble a lot of electronic goods. The counterfeit components are sometimes completely fake. Other times they come from the genuine factory, but are defective scrap parts that were salvaged and repackaged or lower spec parts that were relabelled. In some markets, up to 30% of the electronic components are salvaged scrap or relabelled.

The purchasing people handing out contracts to subcontractors know what is going on, and they know why they are getting a lower price. So do the people they work for, all the way up to the top. They just cover their eyes and pretend they don't know what is going on and collect a nice bonus for finding a cheaper supplier. When the problems come up later, they get blamed on "the supplier" or "its QC's fault for letting it happen". It's never the fault of the people who actually made the decision.

Dave - not that I know much about it but Rhos will also make a big difference. Solder without lead, is proving to be a big deal breaker in the contracts of longevity!

As with everything else we are in a throw-away society!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

The Koyo is way harder to understand than AB. To work with Directlogic you have to have a clear understanding of numbering systems, i.e. octal, hexidecimal, just to be able to figure out the inputs. At least with AB all you have to really understand is an integer and you could get by. I have never touched a Siemens but come on... how hard can it really be?

It depends on where you are coming from. Having a computer deal with decimal integers is actually quite a high level function. Octal is a little strange for those late to the party. But you have to understand hexadecimal to get far in AB as well. Siemens organization, with all the more bizarre bits of indirection and OO is far more complex, even for trivial programs. Not necessarily bad in itself, but far more complicated than it needs to be for most PLC fare. It's like assembly programming. Programming a Z80 with a flat map is just a lot more fun than dealing with x86 segmented addressing, etc., etc. The burden on the coder is much less.

Regards

cww

The point to the argument is that no matter which PLC you use, there is a learning and maintaining curve. Some info is transferable, and if you are just adding a "rung" an input and a coil, most should be "fairly" straight forward.

But At 3 AM, with what you think is the proper laptop, proper software version and copy of the program and comments and the proper cable and write-up, having 10 different types of skid controllers can and does become a nightmare (been there done that.)

So sometimes having a lot of "cheap" controllers isn't so cheap. We have chosen to use a couple of standard controllers from a single or small list of manufacturers. And although there are a couple of instances where we have Porsche's for getting groceries (way overkill), the benefits of spare parts and the tax consequences of the spare parts, training, experience, software, cables, and long range obsolescence and UPTIME far outweigh the money we save short term by getting the "deal of the week."

Just the way we have chosen to do things. We also standardize on one industrial switch, try to standardize on PC's (harder) and laptops (still harder) and DCS, discrete valves, control valves, transmitters etc. Sometimes we fight with vendors and pay much more to get it "our way" but again UPTIME is paramount for us and we cannot afford very often to have even a little skid go out on us as it may feed something highly needed to run.

Do we see the short sighted "bean counters" all the time trying to fight us, you bet. But we have had at least for a long time, a management that recognizes that sometimes the short term budget gain, may burn you later. Usually with the projects we do, the control system is such a small, small part of the overall project cost that it really is peanuts to us (most of the time.)

I have experienced the short sighted "low bidder" mentality, and I will take what we do over those 3 am or all day Saturday nightmares that the "low bidder" bean-counter at all costs, short term thinking create. I also will take off-the shelf programming when it makes sense over "custom" programming in some obscure language by the one guy we have stuff as inevitably, he leaves, moves to a different position, had it on another computer etc. By sticking with major vendors, we can have expertise, but can also find 200 guys on Monster, at some Integrator or down the street.

If we go with 50 one-offs, good luck.................

Dave Ferguson

Hi Dave
I don't disagree with all your points, but you are basing the whole works on price. That is not why I am looking elsewhere for my small PLCs.

Cost and value are certainly factors, but the
Mitsubishi units I am installing in the interim are actually more expensive than Micrologix. And I don't think it's quite accurate to class Mitsubishi as a bargain basement company either.  I don't classify Koyo there either
seeing as they have been a premier supplier
to many big names.

It's about reliability. And the training issue is a red herring for me as I wouldn't hire anyone who could only use one brand of PLC. In my situation that would be ridiculous as we support many brands.  The spares argument kinda
works the same way in my situation.

I suppose if you're all AB then it works for you to be all AB and it certainly makes them happy. But what do you do if you need a product they have problems with? Should I write off the failures because it's AB? No can do.

Regards
cww

I'm sorry, but I have to disagree with this. Neither the Koyo nor any of the AB line is "intuitive" in the sense of a infant suckling. They are learned skills, not intuitive understandings.

I will freely admit that there is a cultural componant to what we find easier to learn, i.e. it's easier to work with something that "looks like" something else you already know. If you grew up in the TI world then the Koyos look like a home run king.

How hard can a Siemens be? No harder than a Koyo, or an AB, or a Mitsubishi, or an ABB, ya-da, ya-da, ya-da. They're all different, and they all do some things well and other things poorly.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

Part of it depends on how GUIfied you are also. But there are good and bad of all genre. Step 5 and Omron's old stuff, most would agree are kinda nasty and don't flow logically.

RSLogix is about the best Windows implementation I've seen, they take the best advantage of features for prompting and flow. Many of the others show more signs of being Windowfied DOS programs. Some of the old DOS programs are easier to work with than some of the newer Windows offerings IMHO.

I prefer Logicmaster to _any_ of the new GEFanuc offerings which share some traits of Step 7. Since I am usually interested in the ladder, I like software that is written to deliver you there.

I don't like the program broken up into dozens or even hundreds of files. None of these can prevent me from using the software, just liking it.

Again, it's like other programming. I could do everything in assembler, given enough time and patience. I greatly prefer C as it's much less fatiguing. And the higher level languages gloss over too much detail. I've thought about this quite a bit lately as I wonder what the next step in automation programming will be. Perhaps a "machine description language" where you state what you want to do and standard block are put in place. Who knows?

Regards
cww

You mean we may catch up to Forth? Everything old will be new again.

MB

I kinda liked Forth, but I'm better now. It was one of the better "ROMable" languages for the Z80.

Regards
cww

I like Forth too, but I can't figure out a way to actually use it. The basic concepts are brilliant, but it is very difficult to master. You have to learn to think differently, which is never easy.

Bill

Curt:

I hate to admit it after 10 + years, but I actually kind of agree with you here.

Mark this day.

PS: Had to throw the kind of in there.................. : )

Dave Ferguson

Curt,

I have long thought of using C++ with RTOS for machine control and wrapping commonly used functionality into objects. Picture a pneumatic
cylinder with hall effect limit switches on both ends of travel (90% of motion we use at my company). You could instantiate an object called
"CylinderWithLimits" or something like that. You could even define timeouts and things associated with waiting for the cylinders to hit the end stroke switches, and even have it generate error messages and such. Imagine a program that looks like this:

SomeSequence() {

// Extend method extends the cylinder, waits for switch,
// generates timeout message if not actuated.
// Method could also check for common issues
// such as switches wired in reverse, etc.

TransferCyl.Extend
InsertCyl.Extend
InsertCyl.Retract
TransferCyl.Retract
}

Who could argue that this would be difficult to read, while still understanding the functionality? Of course you would have lots of object instantiations in some setup code, but you only have to do that once per project (or when adding new mechanisms).

Of course, you can do the same in ladder (and I have, in a more manual way using function blocks), but in the end there is more debugging and code entry. I currently use Mitsubishi PLCs with the IEC programming software (using ladder with function blocks) because they have the fast IO, fast CPU, and other supporting hardware/software such as analog IO, communication, and such in a small modular package (The Q series PLC).

If I could have the same package programmed with a high level language and RTOS with drivers to handle all IO, life would be good. Unfortunately with rolling your own controller using PCs you have to deal with drivers for every peripheral, and it needs to work seamlessly with your RTOS as well, which is not trivial. Then there is the potential for hardware/software interactions with multiple vendors. I wish I had an answer, but things are not quite there yet in my opinion. If anyone has any suggestions, I'm all ears. :o)

KEJR

You can do something very close to this now in AB Controllogix Version 16.

The ability to build custom function blocks and custom data types in whatever language under the covers you chose (of the 4 (of 5 6311-3) languages).

I have done this a lot, so you can build a standard motor or valve type (object) and have all the code written the way you like it and then punch out instances of them. If you change the master, they all change (or not if you chose). Once you create the FB you can use it as a ladder object or a function block, but when you open it (available or you can make it view only or lock it out all together) it could be written in ladder, or FB, or SFC or structured text, which is very close to a C-like language. In fact I have some hydraulic cylinders written just as you described below... by creating my own data type, I am able to access "parameters" just like this davesvalve.zso (open limit) or davesmotor.mz (motor final control element) or davesmotor.mi (motor indicator) or davesmotor.mcas (motor control auto start or davesmotor.mci (motor control interlock), etc.

Very handy and very close to what you speak of and yet if I want to use the logic as ladder (which the plant floor gets) then I can and embed the logic inside the "ladder" for the more "complex" parts.

P.S. You can also do this in DeltaV (pretty closely).

Dave Ferguson

Thanks Dave,

I'm glad I'm not the only one doing this out there. I am doing very similar with Mitsubishi IEC developer (not supported in the US, but it is going to become the next Mitsu platform globally with the next release this year, or so I'm told). I wanted to use RSLogix, but at the time they didn't have the custom FBs. How is RSLogix with regard to timers within user defined function blocks? Mitsubishi gets weird about timers when the function block is called like a subroutine, or should I say, when it doesn't get called (i.e. not scanned). I've had to configure most of my function blocks using timers to be "macro" function blocks that compile to inline IL. I would hope Rockwell handles it better.

~Ken

Sorry for the late reply was on vacation...

No there is no issue that I am aware of, I also checked with someone else if they had any timer issues inside a custom FB. There are none we are
aware of, they work fine, I use them for my fault logic for custom motor and valve control and they time fine...

My friend uses them in simulation blocks he has built and they work fine.

Dave Ferguson

Step 7 from Siemens has had this capability all along.

So has Concept for Quantum (Schneider/Modicon) PLCs.

This method is easy to program and read, but difficult to debug and diagnose. What do you do when you call TransferCyl.Extend and nothing happens?

A major reason that ladder logic is so popular is that it replaces extensive diagnostic routines. Instead of built in diagnostic routines, you just give the customer ladder source code and let them read the logic and diagnose the problem themselves. Nothing is hidden.

I suppose you could put enough error messages in the code that the end user instantly knows what conditions are not met, but that is a lot of work to write and maintain.

Most high level computer languages do not display variable values while the program is running either. You must set breakpoints and your program is stopped while your outputs are still in their last state. (been there, done that) Or write more code to print values of all of the variables to a debug screen.

These are just a few of the reasons why most people just throw in the towel and use PLC's for direct machine control. PC's are better used for supervisory control.

Bill

Bill,

Thanks for the input, these are valid concerns. I think you are starting to get what I'm saying in one of your comments:

> I suppose you could put enough error messages in the code
> that the end user instantly knows what conditions are not
> met, but that is a lot of work to write and maintain.
It boils down to how you program. I have timeouts on everything. The machine *Never* stops without alerting the operator of something beign wrong. I have HMI touch panels on every machine for this reason. The nice thing is the operator has instant feedback which in most cases allows them to troubleshoot the machine quickly and get it back to running. You could have your message built and sent to the HMI by the controller by the object, something that would equate to:

"Transfer cylinder did not extend in the alloted time."

Where "Transfer Cylinder" is the descriptive HMI name set up in the object at initialization/Instantiation.

"Extend" and "retract" can be built in to the message (or use some other term that you initialize), or you could have custom fixed messages for both states of the pneumatic device. The possibilities are endless with a higher level language. Again, these things are programmed in initialization code, once, and 99% of the time never chang. It might be possible to auto generate much of this, using scripting tools as Mr. Griffin points out.

The monitor capability boils down to the capabilities of your RTOS and support software for the controller "system". You definitely need a system where you can monitor the state of threads and break into execution, step through code, etc. You also need the ability to monitor variables. I think for 99% of your initial concern, however, is handled by having a self diagnosing code will get you away from the need to monitor the ladder code directly.

I haven't seen a system that does everything I would ideally like, that's why I'm still using a PLC for most projects. As I said in my email to Mr. Griffin, however, the Epson Robot controller (RC+) does a lot of this already. If something like that were packaged in PLC hardware (right now it's a metal rack mount kind of thing with an industrial PC inside) with appropriate IO/communication modules things would start into the right direction.

~Ken

In reply to Ken Emmons Jr.: The problem with the sequence example in C++ you gave is that it doesn't show any conditions for initiating the sequence. It also doesn't handle auto/manual, sequence initialisation, etc. It also doesn't show how you would do multiple things in parallel. These are the messy details that tend to account for the bulk of the logic in a typical program. In fact, making the machine move is often the easiest part of the entire project.

What is really missing in PLCs are what is known in conventional programming as application frameworks. Frameworks go beyond libraries in providing an overall template for an application where you just have to fill in some details. You still have to know how to program, you have to pick the right framework for the job, and there is a learning curve for the framework itself, but it saves a lot of time when developing routine applications. For example, custom web applications (which is where most custom business programming is done these days) are moving to being done with things like Rails or Django.

As an example, consider the following. You have a machine whose mechanism consists of a number of pneumatic cylinders and MRS switches (which describes probably 90% of the machines in a typical factory). At the minimum you typically need initialisation, sequencing, fault detection, auto/manual control, and alarm monitoring. A lot of this could be fill-in-the-blank type configuration (especially fault detection and alarm monitoring).

You would still have to write the details of the actual sequencing, but that is usually fairly easy. You would also need different frameworks for different classes of machines (e.g. a water system versus a press), but again, most people deal with a narrow range of machinery and so would only need to learn a few templates.

Many people try to get some of the benefits of this by copying and pasting code. That however tends to import more complexity into their programs and they still have to hand edit most of the logic.

Unrelated to the above (the following has nothing to do with the programming frameworks I was describing above), your example doesn't really need C++ to operate. You could have a simple compiler convert that logic into Mitsubishi code.
>
>> TransferCyl.Extend
>> InsertCyl.Extend
>> InsertCyl.Retract
>> TransferCyl.Retract

You would need to add parameters which define what I/O to use, and what bits to use for sequence control, but the compiler itself would be very simple. You would need to define that TransferCyl and InsertCyl are of type "Cylinder". Type "Cylinder" would contain a string or strings (which you create) that holds the IL code for what you want a cylinder to do. The compiler then just goes through your sequence list and substitutes the parameters into the pre-defined string to create the code for that step.

Essentially, the compiler would simply automatically replacing the sequence description with a stored standard code template that you have created. Regular expression strings can be used to validate the sequence program (i.e. that you typed in valid inputs and outputs for the sequence).

The end result is an ordinary PLC program with most of the code being auto-generated. Someone looking at the end result wouldn't know that it wasn't all created by hand. Getting that into the Mitsubishi programming software is left as an exercise for the student.

Something like this could be written in Python or Perl (or possibly even awk) fairly easily. It is basically just a bunch of string compares and string substitutions to transform one set of text into another set of text. I suspect that this is more in line with what you are looking for.

Hello,

Yes, of course I agree that making the machine move is the easiest part, but, having said that, doing it with all of the error handling and recovery code is what makes it heavy and bug prone to do in ladder in my opinion. My example code would have to be used with an RTOS and need to have conditions placed around it, of course. I've done this in RTAI and Epson robot controllers already and it isn't that difficult. You have your code start up, initialize variables and equipment, spawn new threads to handle the parallel-isms, and then have a main program that controls when the parallel threads are executed (This can be a simple "If" statement, or an RTOS related Mutex/Semaphore/Signal thing that doesn't incurr a task switch unless the variable is true). Of course, multithreaded programming is difficult for the beginner to understand, but so isn't race conditions associated with PLC scanning. I consider myself a fairly advanced PLC user and I still get bit once in a while by a problem with the way the PLC scans and some stupid mistake I made. The difference is that in normal PLC programming the glitches caused by scan issues can happen *everywhere* in your code. With RTOS you write your architecture once and debug it. The code within that structure tends to be easily modified.

I've used both, done it both ways and there are benefits to each approach, certainly. I've done simple ladder with brick PLCs that did nothing but sequence on timers, to sequencing on switch input, to full error handling based on swith input with timeouts on everything. In my experience the PLC/Ladder/IEC approach is quicker for simple things, but more complex for other more complicated things. Changing the ladder code, especially where complex decisions are concerned is more involved. I can re-arrange lines of text and write "If" statements much faster than adding and subtracting sequence rungs, renumbering them, moving function blocks, etc.

On the other hand, PLCs are nice because you can "cheat" when you need a quick and dirty parallel routine, even within a POU (using IEC speak) that is sequential. There is no doubt that this is powerful and fast.

I like your idea regarding a preprocessor for Mitsubishi, but this is already done to some extent with the IEC Devleoper implementation. What you have to do is wrap the features in a function block and instantiate it every time you use one. It can be made to be close to the same thing by passing in predefined structures that "configure" the function block [object] for each instance. Or, you can use input variables to configure the FB. It just gets really repetitive and heavy to do it everywhere. Whats missing from your preprocessor idea is the debugging aspect, which, to me, is one great feature of most PLCs. Given infinite time you could run a PLC debug session by reading and trying to understand compiled IL, but its really not worth it. Getting in there and seeing what step of a sequence you are in, monitor and forcing variables and IO and seeing its effect on the code is essential.

In the end, I think it boils down to what you are more efficient at. If you need to write programs that are read and modified by people who don't know high level languages, then I guess my proposed approach is not valid for those applications. I stick to my guns, however, that human readable (intuitive) text programming is much easier to understand for the layman. What is more difficult is the layout architecture syntax that you describe. Are there really [a majority of] plants out there where people need to completely re-arrange architecture without consulting the engineer/programmer? My machine architecture almost never changes at that level (I'm struggling to think of an example) unless there are major overhauls/upgrades to equipment. Most of the time it is more like tweaks to delays, swapping the order of sequences, adding an operation, etc.

I appreciate your opinions, you bring up some good posts over the years of me reading this list. I don't know all the answers, which is why I brought it up, but I do know that the IEC implementations just aren't all they are promised and there are bound to be better ways for future systems to be programmed. You have to wonder with kids coming out of school having programmed in C/C++ and/or Basic if the natural order of things will change over time. My experience with programming Epson robots and their implementation of a multitasking robot with a "C" like programming environment is extremely rich. Its not without issues but I've been able to not only program the robot, but also entire rotary turntable machines operating in conjunction with the robot, without a PLC attached, and much faster than any PLC I've ever used. I'm not trying to promote them, Its just my solid experience with a text based language system that was done right for automation. If only they made it with a PLC like format with all of the available add on modules, and added object capability in addition to functions. ;-)

~Ken

In reply to Ken Emmons Jr.: My replies are in-line with your comments so that I can respond to each in turn.

KE:
> Yes, of course I agree that making the machine move is the easiest part,
> but, having said that, doing it with all of the error handling and
> recovery code is what makes it heavy and bug prone to do in ladder in my
> opinion. <

MG Reply:
This was the point I was responding to when I was talking about application frameworks. When you are looking at a particular class of applications (e.g. assembling parts on a dial table), a lot of things in the PLC code tend to be very repetitive from one machine to the next, with small differences in detail. That is, things like detecting faults, reporting alarms, editing and
selecting product recipes, etc. are usually very similar. They are usually *not* similar enough though to let you simply copy a program from one machine to another and just make a few changes (at least not without gradually evolving into an undecypherable mess).

An application framework would let you select the architectural characteristics (the overall design features which make a dial table different from a water purification system), automatically create an overall framework for the program, and let you fill in the details. The actual details of the alarm handling wouldn't be visible to you. You would simply tell the software things like "this is a cylinder, these are the limit switches for it, these are the messages I want associated with it, and this is the time limit on cylinder stroke", and the alarm system would take care of the rest.

The parts of the program that you would concentrate on the most would be the parts which make your application unique. There would need to be a number of different application templates, because no one template would fit all applications. You would also need to be able to develop your own templates, as it wouldn't be feasible to predefine all possible fields of application.

I'm not saying that I have a clear idea of how to do this at this time, nor am I saying that I thing that ladder logic is suited to this. I am saying though that I think this is the direction the industry needs to go in, in order to progress. I think the foundations for frameworks such as this would have to be built into the PLC or soft logic system to really make it work well, so I don't think it is something that could be easily added to existing systems.

KE:
> My example code would have to be used with an RTOS and need to
> have conditions placed around it, of course. I've done this in RTAI and
> Epson robot controllers already and it isn't that difficult. You have
> your code start up, initialize variables and equipment, spawn new
> threads to handle the parallel-isms, and then have a main program that
> controls when the parallel threads are executed (This can be a simple
> "If" statement, or an RTOS related Mutex/Semaphore/Signal thing that
> doesn't incurr a task switch unless the variable is true). <

MG Reply:
I don't think the OS needs to be an RTOS. It simply needs to be multi-tasking (unless some of tasks themselves really need to be real time).

KE:
> Of course, multithreaded programming is difficult for the beginner
> to understand, but so isn't race conditions associated with PLC scanning. <

MG Reply:
What the designers of ladder logic (and IL) dialects have done is to design a language that is "non-blocking". That is, the natural way of writing it is in a manner that allows it to "scan" continuously in a single thread.

I think that in order for your idea to achieve general acceptance, the language syntax would need to naturally takes care of these details. This way, the compiler would be able to fill in the details by itself, and also catch a lot of the possible programming errors.

KE:
> I like your idea regarding a preprocessor for Mitsubishi, but (...)
> Whats missing from your preprocessor idea is the debugging aspect,
> which, to me, is one great feature of most PLCs. Given infinite time you
> could run a PLC debug session by reading and trying to understand
> compiled IL, but its really not worth it. Getting in there and seeing
> what step of a sequence you are in, monitor and forcing variables and IO
> and seeing its effect on the code is essential. <

MG Reply:
Actually, debugging would be the same as debugging any PLC program. The preprocessor idea is really just a code generator that outputs IL. Ladder logic is just IL that is written to follow certain recognisable patterns. In fact, the easiest way to create the code strings would be to write the
standard ladder logic that you want to reuse over and over again, convert that to IL, and then paste it into the code generator.

Once you had output your sequence for an application, you would work with it in ladder after that. It's just saving you a lot of routine typing when creating the program. It would also save you from a lot of routine typographical mistakes as compared to typing it all in manually. Anyone seeing it later though would simply think that you typed it all in by hand very methodically. You wouldn't use the code generator to make small changes to the PLC program. It is meant only for creating large new chunks of code
from scratch where there is a lot of code repetition.

This isn't as advanced a concept as what you were discussing, but it is something that could be applied today to almost any PLC. It would mainly be of use to someone who has to write a lot of fairly similar PLC programs. It is a feature that could even be built into the programming software.

KE:
> this is already done to some extent with the IEC Devleoper
> implementation. What you have to do is wrap the features in a
> function block and instantiate it every time you use one. It can be
> made to be close to the same thing by passing in predefined
> structures that "configure" the function block [object] for each
> instance. Or, you can use input variables to configure the FB. It just
> gets really repetitive and heavy to do it everywhere. <

The difference with the code generator is that you aren't creating a function block. The code is being inserted in-line. That code could call a function block of course, but it doesn't require one.

A number of SFC implementations are simply code generators. The code they generate though is usually very hard to understand, because there is such a large semantic gap between SFC and ladder. The code that is generated by the means that I am talking about above should be easily understandable, as it is really just human created code that is being automatically inserted.

I'm not saying the code generator idea is the answer to all your problems. I was just pointing out that it seems to address part of what you were looking for while still using the same hardware that you already have. It also gives some perspective on actually implementing the ideas.

KE:
> My experience with programming Epson robots and their implementation
> of a multitasking robot with a "C" like programming environment is
> extremely rich. (..) Its just my solid experience with a text based
> language system that was done right for automation. If only they made it
> with a PLC like format with all of the available add on modules, and
> added object capability in addition to functions. <

Industrial controls seem to be evolving to where I/O is mainly on a network, so the physical package the logic runs on is becoming less important (provided of course you use an open protocol). So, it ought to be feasible to
use a system such as you describe even if it isn't packaged into a PLC (you just really want something in a rugged and reliable embedded computer).

If we go back to your text example, I think the idea has enough merit to warrent further thought. What I don't see from your example is how you could handle parallel sequences with divergence and convergence without all the work of writing the code for launching a separate task. For example, consider your original example:

> TransferCyl.Extend
> InsertCyl.Extend
> InsertCyl.Retract
> TransferCyl.Retract

What if I want TransferCyl.Extend and InsertCyl.Extend to happen at the same time? We would need to add some coordination functions. They could work something like this.

Wait(TransferCyl.Extend, InsertCyl.Extend)

That however gets quite complicated though for non-trivial sequences.

We would need a syntax that expresses sequential and simultaneous operations. The following is an example which I am presenting for the sake of discussion.

If we wanted to hide a lot of the implementation details, then we would need to define a set of sequence data structures which could be passed to a class which took care of whatever needed to be done in order to execute the sequence (however that is accomplished).

For example, if "()" were to enclose operations that happen simultaneously, while "[]" could enclose operations that happen sequentially, then this could translate to:

Step1 = (TransferCyl.Extend, InsertCyl.Extend)
MainSeq = [Step1, InsertCyl.Retract, TransferCyl.Retract]

TransferSeq = Sequencing(MainSeq)
TransferSeq.Run()

In the first two lines we are assigning lists of steps to variables, which defines the actual sequence. In the third line we are instantiating a
particular sequence from a sequence class. In the last line we are running the actual sequence. There would need to be other class methods of course for stop, fault, single step, etc. The "Sequencing()" class would take care of whatever needs to be done to execute the sequences.

The above is valid Python syntax, but there are probably ways of doing the same in other languages.

All of this (application frameworks, code generators, sequence syntax) is all related in a way. Typical application frameworks usually include some sort of template language to define how the framework is instantiated. I think it
should be possible to use a sequence template language to automatically generate the details of the sequence logic together with all associated alarm logic etc., without straying too far from familiar PLC concepts.

I'm not sure that existing PLCs though are the best platform to implement this on. I think there needs to be some higher level architectural support so that some of these features are built in without having to add huge masses of IL code to implement them.

Hello,

In response to Michael Griffin:

You bring up good points with the framework. I don't know of such a tool to use for this, and my preference would be to have it be backed by the programming and monitoring software maker unless it can produce code that is highly readable. Something like Structured Text (ST) with human readable tags (instead of memory addresses an IO) would be nice. This is just my opinion, but IL is readable but somewhat difficult to understand at a large scale, especially when you are looking at an uncommented mass of instructions. It all depends on the target PLC I would think, which language is handled better (or even supports it).

As far as the code and changing order and making some things in parallel, one simple way is to have more methods such as this:

MyCyl_1.ExtendNoWait
MyCyl_2.ExtendNoWait
MyCyl_1.WaitExtended
MyCyl_3.ExtendWithWait

Or something similar. Of course we would have to figure out the language of it all to make sense for each object type, but it accomplishes the basic logic of what cylinders get fired in series and what is in parallel. I do now in a different way with ladder and blocking languages alike.

This is just my opinion, and please readers... don't respond with flame email, ;-) but I think blocking code is easier to understand than scanned code. What is missing, and I think you touched upon this, is the ability to break into parallel code and reconverge when you need it. In ladder it is quite easy, you make two sequences, trigger them, and then wait on them both to be done. What does get a little confusing is in the classic multithreaded model dealing with triggers and waiting on things to be done is handled by creating two threads, triggering them from a master, and waiting for them to be done. I'm not reall afraid of this, but I have gotten into debug sessions with this type of thing that can be confusing.

We can classify the OS or System as as being multithreaded for now and not get into OS details. I'd hate to diverge into a discussion about deterministic vs. non-deterministic and all that, its best left for OS discussions.

Now that we have said this, it brings up something I have long thought: Flowcharting is nice for organization, but crappy for detail work (IMHO). I personally like having flowcharts on some complicated sequences that branch and loop for understanding and documenting. Of course there is SFC and Steeplechase VLC that are touting this as a method for the outer structure of the program. For many reasons these languages are not always good for low level "detail" programming. What about using simple Flowchart like language to define your branching, merging, and looping, and do the guts in a "blocking" text type language such as I described (It could be modified version of "C" or whatever). Does this not do everything we need for machines?

I agree that existing PLCs would be a bad target for such a device for many reasons. I think the open remote IO almost gets us to a point of being able to run a standard embedded PC of sorts, but its not quite the same. With IO starting to run on Gigabit ethernet, I don't know if this is the case anymore. You still have to pick the right IO systems and tailor your software around them if you do your own software with open fieldbus IO. I've found that even [what should be] simple modbus TCP implementations impose single digit millisecond delays on things for no apparent reason. I know some "slice" IO systems, at least in the past, have delays in their serial piggy back "backplanes". I haven't done enough with fieldbus IO to tell if this is the norm, however. When dealing with high speed equipment imposing millisecond delays on sequences due to hardware limitations is not good. This is why we are using top of the line Mitsubishi with fast response input cards on the backplane. Not because we need it, but it saves us that much time on our machine cycle wich can pay off quickly. Maybe the answer is to have an embedded PC with multiple ethernet ports to handle all the different networks you are likely to have?

Thanks,
~Ken

In reply to Ken Emmons Jr.: My replies are interspersed with your comments below:

On April 23, 2008, Ken Emmons Jr. wrote:
> You bring up good points with the framework. I don't know of such a tool
> to use for this, and my preference would be to have it be backed by the
> programming and monitoring software maker unless it can produce code
> that is highly readable. Something like Structured Text (ST) with human
> readable tags (instead of memory addresses an IO) would be nice. This is
> just my opinion, but IL is readable but somewhat difficult to understand
> at a large scale, especially when you are looking at an uncommented mass
> of instructions. It all depends on the target PLC I would think, which
> language is handled better (or even supports it). <

MG: I don't think that what I have in mind would work too well with a conventional PLC. It could be packaged in an embedded computer that *looks* like a PLC, but there needs to be a lot more capability than just executing IL code. I think it would look something like the following:

First, the soft logic interpreter would be part of the overall framework and execute inside it, rather than the framework executing inside the soft logic interpreter. That is, the code which executes the IL (or ladder) logic would be a library which is part of the overall framework. This is why a conventional PLC wouldn't work with this idea.

The overall system would take care of things like scheduling logic execution, communicating with I/O, stop/program modes, etc. There would be a set of standard class libraries that would handle things like cylinders, conveyors, dial tables, etc. This set of classes could be extended and added to by the user to handle tasks that were not included with the standard ones.

These class libraries would be written in an ordinary scripting language, not IL. You would have to know *something* about programming to extend or add to them, but the learning curve would be fairly easy. Programming in the scripting language wouldn't be required to use the system (write PLC programs), only if you wanted to extend the system.

When writing a logic ("PLC") program, if you wanted to use for example the "Cylinder" class, you would need to import it into your program. The class would do nothing by itself until you filled in some details. If you opened it up like a function block or subroutine, there would be several sections inside which you had to fill in.

You would fill in some of them by writing some simple ladder logic. For example, there would be the start of a rung for "extend" which you would have to complete by including an output(s) plus any additional permissives you want.

There would be an alarm section that included logic which detected faults, plus any associated alarm messages. Displaying alarms on an MMI and acknowledging them would be handled by the overall framework, not by logic in the soft logic section. Whether those alarms were displayed on an graphics terminal, a web browser, or a mobile phone would be completely transparent to the PLC program.

Most of the class sections would be automatically created with some sort of reasonable logic or messages, so you would only have to change those things which didn't fit the default.

Once you have created this "logic object" (as I will refer to it), it could be used as you said, "TransferCyl.Extend", "TransferCyl.Retract", etc. There would also be "TransferCyl.Extended" and "TransferCyl.Retracted" to indicate the actual state of the cylinder (not to mention "TransferCyl.Faulted", and anything else defined by the class).

Logic objects would usually, but not necessarily be associated with inputs and outputs. You could also have logic objects which purely deal with internal logic, such as auto/manual mode changes, start-up, shut-down, etc.

Now, to contradict what I said previously, to aggregate these logic objects into a program, you would have two choices. One method would be to use it as an ordinary output instruction in ladder logic. In this mode, TransferCyl.Extend and TransferCyl.Retract would be like set/latch or reset/unlatch instructions in that they would be active if they were called and the logic stack was true. Of course you wouldn't specify an address (as this was already done), but otherwise you could use them

For example (in IL):

STR "StartButton"
AND "CycleStart"
TransferCyl.Extend

STR TransferCyl.Extended
AND "StartButton"
TransferCyl.Retract

(The above example by the way should appear as one instruction per line - in case the line wrap gets lost in this forum.)

The above allows people to use the capabilities of the system without straying too far from familiar ladder logic. It doesn't address sequencing though, which was your original concern. To deal with that, we need to add a set of sequence classes. These would include a "state" or "step" class, a "sequential" class, and a "simultaneous" class.

A "state" or "step" class would be a container class which collects a group of logic objects into a "step object". The step object would again include alarm messages which would supplement (or even replace) the messages in the logic objects. When all the logic objects in the step object were ready, the step object would itself indicate a "true" condition. For example (in IL):

# The control section activates the outputs.
- Control:
- STR "ON"
- TransferCyl.Extend
- InsertCyl.Extend

# The status section monitors the results. When all are true, the step is ready to advance.
- Status:
- TransferCyl.Extended
- InsertCyl.Extended

Step objects can be aggregated by means of "sequential" and "simultaneous" class objects. The difference between these two is that in one, each step proceeds one at a time in sequence and the sequence is done when the last step object is complete, while in the other, all proceed simultaneously and the object is complete when all step objects are ready. Sequential and simultaneous objects can be nested to allow sequences of any arbitrary size and complexity to be constructed.

The above would require a complete system that is designed around the concept. It isn't something that could readily be added to a conventional PLC. I have a pretty good idea of the overall software design to create this, and it would need to be loaded onto something more like a computer than a traditional PLC. It would also replace the traditional MMI panel, because the MMI logic would be integrated into the control logic system (the logic objects contain MMI components).

KE:
> This is just my opinion, and please readers... don't respond with flame
> email, ;-) but I think blocking code is easier to understand than scanned
> code. What is missing, and I think you touched upon this, is the ability
> to break into parallel code and reconverge when you need it. <

MG: In PLC applications, you tend to need to physically do a lot of simple things in parallel. It is more or less inherent to the application so the system should be designed around that. Ladder logic does this well. What ladder logic does poorly is coordinating these small details into sequences. But as the above illustrates, it is possible to readily extend the above concept to handle that explicitly.

KE:
> We can classify the OS or System as as being multithreaded for now and
> not get into OS details. I'd hate to diverge into a discussion about
> deterministic vs. non-deterministic and all that, its best left for OS
> discussions. <

MG: I agree, the concept does not depend upon RTOS versus conventional OS. Some applications might require a fast RTOS, but that is a separate issue.

KE:
> Now that we have said this, it brings up something I have long thought:
> Flowcharting is nice for organization, but crappy for detail work
> (IMHO). I personally like having flowcharts on some complicated
> sequences that branch and loop for understanding and documenting. Of
> course there is SFC <

MG: The problem seems to be that ladder logic (and IL) are too low level, while SFC is too high level, and neither concept is readily extended to cover the whole range. I think that SFC is an excellent design tool, but it doesn't extend well to the actual implementation. The problems of ladder logic in large programs are too well known to bother mentioning here.

There are similar problems by the way in conventional computer programming. There are a number of code generators which can create Java programs from flow charts (generally some form of UML). They work, but only in some very limited applications. Huge sums of money have been sunk into this problem without success, so it looks to be inherently unsolvable for the general case.

KE:
> I agree that existing PLCs would be a bad target for such a device for
> many reasons. I think the open remote IO almost gets us to a point of
> being able to run a standard embedded PC of sorts, but its not quite the
> same. With IO starting to run on Gigabit ethernet, I don't know if this
> is the case anymore. You still have to pick the right IO systems and
> tailor your software around them if you do your own software with open
> fieldbus IO. I've found that even [what should be] simple modbus TCP
> implementations impose single digit millisecond delays on things for no
> apparent reason. I know some "slice" IO systems, at least in the past,
> have delays in their serial piggy back "backplanes". <

MG: From what I can tell, the problem is the limited capability of the communications hardware in most PLCs and their I/O racks. I've seen delays of over 100 msec. in remote I/O racks in older PLC hardware. I've also seen similar delays in many PLC rack backplanes (in the same rack as the CPU even!) once you get away from simple digital or analogue I/O. This is why small cheap shoebox PLCs can often outperform large expensive rack style PLCs in many applications. Several years ago I cut approximately 15% off the cycle time of a set of machines by replacing one large PLC with several smaller ones (one per machine).

KE:
> I haven't done
> enough with fieldbus IO to tell if this is the norm, however. When
> dealing with high speed equipment imposing millisecond delays on
> sequences due to hardware limitations is not good. This is why we are
> using top of the line Mitsubishi with fast response input cards on the
> backplane. Not because we need it, but it saves us that much time on our
> machine cycle wich can pay off quickly. Maybe the answer is to have an
> embedded PC with multiple ethernet ports to handle all the different
> networks you are likely to have? <

MG: Some networks (e.g. Ethercat) use special hardware in the I/O nodes to cut I/O delays without adding excessive cost to the I/O.

Even with standard Ethernet though, you can get good speed provided the protocol is simple enough that the software doesn't have to work too hard to decode it. I have done PC applications with using I/O modules which had a simple Ethernet protocol, and reading the inputs or writing the outputs took an average of less than 0.75 msec.

There are a few other things that make a difference as well. One is whether multiple I/O nodes are polled in parallel, or one at a time. If they are polled in parallel, the total time for a poll is the time the slowest node takes. If they are polled one at a time, then the total time is the sum of all of them. This can make a *big* difference.

Another thing is how simple the protocol is. Older RS-485 (or proprietary media) based networks were often limited by network bandwidth, so some protocols were designed to limit how much information they would transfer. For modern Ethernet though, the bottleneck is usually inside the I/O module itself rather than in the network bandwidth. This means that a simple protocol can outperform a complex one because it requires less work from the I/O module logic (field devices have to be designed with cost and low power in mind). Sending the state of all the inputs in a module at once can actually be faster than sending the state of just one.

When you have a lot of bandwidth, brute force and simplicity will usually outperform a "clever" protocol.

Just thought I would put my two cents in:

Upon changing jobs three years ago I was introduced to Beckhoff Automation's PC control platform,and their programming software, Twincat. After using their software/hardware for the past three years I would much rather implement a new control system using this than I would any other PLC/PC control manufacturer. The only reserve I have to making that statement is that I have never used S5 or S7 but from my discussions with the OEM's (who previous used S7 but changed due to flexibility and price) who installed our equipment they are somewhat similar in functionality but Twincat is more open, flexible, and overall more user friendly. Another plus is their software cost. When you purchase one of their industrial pc's or embedded industrial pc's (much less than an AB Control logix processor) you get one licence for their software which will reside on that pc, which will obviously controlling your equipment. For your maintenance and engineering personnel the Twincat development software is free of charge you only are required to purchase a license for the runtime ( so only one license required per PC actually running equipment) I think this is fair. Hardware costs are also what I feel as "reasonable", definitely cheaper than AB or Siemens. I am not trying to make a big sales pitch (although it sounds like it) but if anyone is interested in a more open, cost effective, and still reliable platform then I would suggest at least giving them a look. You can download a full version of twincat including runtime for free from their website. http://www.beckhoff.com

In reply to brian: AB used to use octal addressing. That didn't stop AB fans from claiming that the way those PLCs worked was only right way of doing things.

The Koyo PLCs are pretty typical Japanese style PLCs. They were also sold at various times under the GE, TI, and Siemens labels. The present Siemens S7-200 series are pretty similar to the Koyo, except they use IEC style addressing and dropped the older BCD style instructions (Koyo has both natural binary and BCD instruction sets). All of these are reasonably simple. As to whose is the "best" is a matter of splitting hairs.

The Siemens S7-300/400 is very different from the Siemens S7-200. The S7-300/400 *are* very complicated, and the programming software is very large and complex (I believe this is the software Mr. Wuollet was referring to as requiring more work to use the software than to write the PLC program). If you've never done anything with an S7-300/400 or an S5, then you haven't seen a complicated PLC.

Yes, Step 7/S7-400 is the epitome of abandoning the virtues of the classic PLC.  It isn't much simpler than using an assembler and a good macro
library on the same hardware.  It's pretty complex when you are doing the programming and can be really tedious figuring out what others
have written, especially since fans of the beast like to alternate between ladder and instruction list. A large program may have a whole screenful of blocks and you jump around a lot.

Finding a particular bit of logic and rounding up it's data can take a long time, especially if you don't use the stuff every day.

Regards
cww

It's really interesting, why do we pay more?
$99 PLC with RS and TCP/IP stack + the C language on the board are all we need (in 99,9% of projects). The misstandardisation and the close architectures look like a key for right answer.

Might work for some situations but many automation porjects need to have something a little easier to debug, test, and modify out on the plant floor.

For a simple system that can be shutdown to relaod a program, and you have an experienced C programmer available to do any programming and debugging, the $99 answer may work OK.

For factory floor systems where you need the ability to do online programming, debugging, and testing by plant electricians, it is an awful choice, no matter how cheap.

I do not propose to use the C language as a programming tool, just as a perfect and sufficient means to create "OPENability" of PLC.

BTW, the C language is not more dificult than ST (a Pascal-like) or IL (an assembler). Obviously, they do not meet requirements the control programming set.

--
Best regards,
Vladimir

Although I agree with you to a point, why pay for software (Hey I am human too. :>), I can easily justify the cost. Sure it would be nice to only pay a couple hundred for the software, but with AB RSLogix software, we show customers how to save hundreds of thousands of dollars using the RSLogix 500 and 5. (Because we teach our customers how to minimize downtime which saves the TDC. See http://www.DowntimeCentral.com)

Allen Bradley's RSLogix has features that other PLC vendor software does not have or is too difficult to use, that if thought by the right instructor can save you the kind of money mentioned above.

So that is the main justification for the software price, but for those who can not see the intangible, $1k software is only 10% of a typical $10k PLC System installed. Then your next system, and next, and next no software required if you stick to standardization while purchasing future PLCs. So if your facility has 5-20 SLC 500 and or Micrologix, the RSLogix software is only a fraction of the cost. (Plus other vendors can include software price, hidden within their equipment PLC hardware cost.)

Now for Controllogix and RSLogix 5000, the above does not apply. Because the RSLogix 5000 is a new type interface leaning (catering) towards the higher level software programming languages that IT people understand and electricians are overwhelmed by. Also the annual fee, but that is insignificant compared to the downtime caused by the huge learning curve and social barrier caused by the RSLogix 5000.

To stray a little from the software cost topic and better explain what I mean by "Social Barrier" (because it is interesting :>), I'll explain what most of you already know. The workplace for a PLC pre-RSLogix 5000, was you install a machine, and unless if breaks down, you pretty much did not mess with the PLC. When it broke down, an electrician would use the PLC and his 10-30 years electrical experience to troubleshoot. Typically he would find a electrical/mechanical problem and fix it or have a mechanic fix it. To modify an exsiting RSLogix 500 or 5 program, the electrician was well aware of safety and reliability issue being noted before he/she would make a change. Work with the OEM when needed, base on the electrician's experience.

The new social barrier is that with Control Logix (RSLogix 5000) industry is finding the need to bring IT into the picture. Because of the Ethernet management primarily, but also to help with the learning curve of the new interface that caterers to computer programmers, not ladder logic programmers (electricians). The barriers are that typically IT people do not have 10-30 years experience with electrical work or the machine. Also I fear the concept that IT changes typically do not have real word, real time effects that can damage man or machine, they may be more prone to those kind of mistakes. (Which stresses the importance that IT get more real world training before let lose on th PLC. But additionally when a machine does go down, now you have the IT guy, the Electrician and the mechanic. So simply put, 33% more time to repair and chance for error. (Actually it would be higher when you take a TDC mentality. Because of a much increased chance for personality conflict, lack of hierarchies, procedures, authority, communication and understanding.)

Just wanted to get my two cents in. And no offence intended towards the IT people, they are some of our best PLC training students. Just stating what most already know, they need more electrical and PLC training for their new job responsibility. :>)

I think that if we're looking for a system for my plant I have to consider all the options and prices, of course, but also the learning curve and how easy is to programe the PLC for me and the maintenance people.

AB is more expensive than Omron and others, but it's very easy to create a project because the software do a lot of things for us in the background and everything is quite integrated. AB products are very easy to communicate between them.

Siemens or Modicon are as much as expensive as AB, but their software is more difficult to use and the communications aren't as fast to implement.

Depends on your plant's philosophy, you might want to spend time (money) doing some job that with other software could be faster (cheaper) but with a cheap software OR spend little time in learning and developing but more money in software.

The first example is cheaper at medium term, but the latter is more cheaper at long term... it depends on you...

The real answer is that most places don't need all that many software licenses, and the cost kind of fades into the general overhead. Its just not as big a cost as the cost of using some software that is less expensive, and not having the engineers and techs up to speed and loosing production when
something goes wrong.

The hardware cost of all the brands is very close, especially at the OEM and larger user level.

I agree that the initial cost of the software licenses do not have much impact. But, when an OEM like AB publishes 17 versions of RSLogix5000 that have to be in 'lock-step' with the controller's firmware, you run into some problems. If you're into making stuff work, being on the phone all day with the purchasing department, the distributor, and the OEM to sort out your licensing and support agreements is not pleasant.

I agree with you that this can be painful but it goes for most of the vendors now. When you have flash able ram in all of these controllers, all of the vendors are starting to "lock step" you.

One thing on the Logix side, after version 10, you can have multiple "versions" of the software on the computer so that you can talk to all regardless of the version.

Dave

You've seen a plant with a philosophy? :^)

Regards
cww

I agree with a lot of what you said but I have a little different take on the RSLogix 5k and ControlLogix.

CLogix supports the 61131-3 (4 of the 5 languages).

The languages supported are Ladder, SFC, Function Block, and Structured Text.

None of these are really IT languages but structured text comes closest. Structured text programming like languages have been around in PLC's forever IE S5 Siemens. Now if you say in AMERICA ladder for electricians is "normal", I would agree. But SFC has been in PLC 5 forever, Ladder of course goes without saying and Function Block is not there for the IT folk, it is there for the Process people (DCS folks) who are moving over to the PAC (Programmable Automation Controller) world.

I think that the inclusion of these languages is not per say for an IT function but for flexibility of things like motion control, Process Control, batch control structure, etc. I can still do all of those things in PLC 5 but I find Clogix far easier to use. As with anything, if you do not comment and write good structured code, no one will be able to troubleshoot, not the Electrician, Engineer not the IT guy. I have been a part of some European programs that are extremely efficient from a "programming" point of view, bit shifting, etc., but noone can fix it when or if it breaks. That has nothing to do with the PLC but the programmer.

As always I claim it is the Painter and not the Paint set.

Dave Ferguson

Hi All.

Nice debate.
Well, I have used Omron (Old DOS based), AB (500 & 5000), Siemens (S5&S7), Opto22, GE Fanuc and Beckhoff.

I currently suggest Beckhoff for every replacement not only because the software is free, but also because they support almost every fieldbus you can think of. It's simple. It has 7 languages which are IEC 61131-3. The support is great. The documentation I would say needs a little bit of a touch up, but pick up your phone and there is always someone to help. All there components are well priced as well. On top of that their new embedded systems offer the power of PCs and the robustness of Standard PLCs. The software is easy to use, quick, you can monitor as many pages as you want, upload, download, online changes, hundreds of FBs to help. (You can also create your own FBs and functions. Also you don't have to pay extra fees for extra functions in the software. And the entire range of Beckhoff only uses one software. Not like RS500 or S5 where now you have to change your hardware and software and pay for it because they're discontinued. I have to say when I first used it like most things that are new I was hesitant to use it, but the Beckhoff guys helped me in my first project with them and I have never looked back. In fact when I install other systems I feel really sorry for all the SIs who have to use other products and have to worry every time they buy from a company if the firmware is going to be okay.

That's my 2 cents. Let me know if anyone needs any details.

Waz

I am confused...............are there 7 61131-3 languages. I was under the assumption there were only 5.

Just curious.

Dave Ferguson

Ok, here is my 2 cents. A&B's software is way over-priced. Here's why I think this. A&B's software runs on Windows. A&B charges $1100+ for software. Microsoft charges $200 to $400 for a complete OS, that takes years to develop and test? So A&B is telling me since their software is $1100+ that it is more complex than the operating system that it runs on. "Ya right". Also the programming language that they are using costs less than their software.

This is right off Microsoft's web page:
Visual Studio 2005 Professional Edition - $799

So how can A&B justify their cost
if Microsoft can sell a complicated OS for under $500 and a complete programming package for under $1000? There is no way that A&B can tell me that their software is worth the price you are paying for a name. "The software should be part of the support for their product at no cost. There are lots of companies that offer their software for free and that is the way it should be."

I would never pay over $1000 for any software.

I certainly don't want to get into a fight defending either Microsoft or AB, but your analogy is flawed.

In a commodity market, like 4-40 screws, the materials and production cost are significant to the cost of goods sold, while the design and engineering of the "product" are secondary to the cost of the design of the tooling to manufacture the product.

In the software world the materials and production costs are lost in the noise of the system compared to the design and engineering of the "product." (In these examples Windows and RSLogix) The vendor has to recover the costs *SOMEWHERE* in the market scheme, either in the price of the hardware - as for companies that give the software away for "free" as an inducement to get you to buy the hardware, or by charging for the software directly. Obviously since Microsoft doesn't really sell "hardware' (game boxes and keyboards aside) they can't recover the cost of Windows, Office, or Visual Studio in the sales of the hardware so they must charge for the software directly.

Let's work with round numbers on a scale we can all think about instead of trying to look at real sales figures. Never mind the fact that neither Microsoft or AB are going to give me a quick peek at their books.

Assume that MS Windows is magically exactly 1000 times more complicated than RSLogix, and takes exactly 1000 times the production effort to produce. Also assume that somehow both MS and AB magically have identical overhead.

Now assume that the market size for the MS products are 100,000,000 units, while the market size for RSLogix is 1,000 units. (Certainly not exact numbers, but I think it's a credible wild guess.)

Now, if you scale the production costs (based on effort - remember we pretended Windows was exactly 1,000 time more complex than Logix) and then spread them across the pool of customers to amortize the costs, you see that Logix costs 100 time more per unit sale to produce. Wow, maybe Logix is a bargain!

NOW FOR THE KILLER REVELATION

Fudge these numbers around any way you want, but the truth is that the invisible hand of the market sets the price. If everyone stopped buying Logix, the price would plummet, just like the companies who "give it away for free." If everyone stopped buying Windows the price would plummet. For both products, once the return crossed the threshold where the sales no longer offsets the cost to produce the product would vanish.

The market, and only the market, controls these prices. Arguments about the production costs are moot. They might make you feel better, or make you angry. And while it's true that MS does enjoy some ability to manipulate prices because of a monopoly position, the market willingly gave them that monopoly because they met customer needs adequately. Perhaps they didn't do a stellar job of meeting customer needs, but they did an adequate job in the face of other reasonable contenders, and people voted with their dollars.

AB is the same thing. They do have a lion's share of the US market, and they got there because people voted with their dollars. I have never once had an AB goon squad show up at my building and break out the windows simply because I got P.O. at them and didn't pay the support bribe that year. And one of my biggest customers is making a concerted effort to rip out all of the AB and replace them with Seimens across all their plants in the US and Mexico, so AB isn't holding on to the market. But guess what? The Siemens software costs money, too. Does that mean they are secretly in cahoots with AB to rape the customer for software? Not on your life. The Seimens guys I've met would like to cut AB's throat and hang the dead PLC carcases on pikes in front as a warning in every plant they can. But the marketing model stands because the customers find it adequate and pay the price, either willingly or grudgingly. But the invisible hand of the market rules the roost.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

In reply to Michael Batchelor: I don't want to express an opinion on whether AB should sell RSLogix for less money, but I think some of your comparisons are a bit off.

I will leave your example of Microsoft Windows aside, because it doesn't really fit the sales model for PLC software. Microsoft sells very few copies of MS Windows to individual purchasers. Most of their sales are to a handful of large PC OEMS (HP, Dell, Lenovo, Acer, etc.) or volume licenses to large corporations. I could of course take the opportunity to point out Microsoft's 90% profit margin on MS Windows, and how they achieve this despite their notoriously vast and ineffectual bureaucracy, but that would be beside the point.

For small sales volume boxed copy software (which is a better comparison to PLC programming software), the numbers that I have seen are that typically about 70% of costs are sales and marketting. The other 30% is split evenly between development (writing software) and general overhead (paying the rent, managers, bean counters, HR people, etc.). Development costs usually include licenses for third party libraries, development software, third party copy protection software royalties, development hardware, etc., so that "development" share isn't all just programmer salaries.

For speciality software that sold in the $100 range, distributor mark-up was typically about 50%. That's just for putting the software on a shelf and selling it. For $2000 software, the size of the mark-up is going to depend upon what is expected of the distributor in terms of sales effort and initial support.

Compare this to just writing the software and putting it up on a web server for download. Sales and marketting costs - zero. Physical packaging costs - zero. Distribution costs - negligible. Copy protection and license enforcement costs - zero.

So, when you are selling software, it turns out that in the typical case most of your costs arise from the things you have to do to sell the software, not the things you have to do to write the software. The PLC companies that give their software away probably aren't losing as much money at it as you may think. Not charging for software means they have avoided a lot of the costs in the first place. Some companies in other industries (outside of automation) have in fact found it to be cheaper to give the software away than to sell it.

Michael,
I agree with the bulk of your argument. However:

1. I don't think the "price would plummet" if "everyone stopped buying" software that doesn't have suitable substitutes (MS Windows & RSLogix). Sure MS and AB would make a lot less money, but consider that selling *already developed* software represents a nearly vertical supply curve (since, as you pointed out, the incremental production cost is nearly zero).

<clip>
>NOW FOR THE KILLER REVELATION
>
>Fudge these numbers around any way you
>want, but the truth is that the
>invisible hand of the market sets the
>price. If everyone stopped buying
>Logix, the price would plummet, just
>like the companies who "give it away
>for free." If everyone stopped buying
>Windows the price would plummet. For
>both products, once the return crossed
>the threshold where the sales no longer
>offsets the cost to produce the product
>would vanish.

2. Arguments about production costs are not entirely moot - they have a strong impact on the supply curves of substitute goods. The textbook example is jet production or large defense contractors. The market exhibits monopolistic behavior because, in some cases, it's only big enough to support one vendor. To be more concrete, if I could write even a slightly inferior alternative to Windows in my spare time - you'd bet that I could undercut the heck out of Microsoft. But you're right - companies are about making a profit and that has everything to do with supply and demand and little to do with how much they've "invested".

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com
"Design Simplicity Cures Engineered Complexity"

In reply to Nathan Boeger: Plenty of people have written better operating systems than Microsoft for less money. Having a better product and selling for less doesn't do them much good though, because Microsoft controls the major distribution channels on OEM PCs. If a PC OEM offers a software product which completes with one of Microsoft's, they lose their MS Windows co-marketing discounts.

How it works is that a PC OEM pays 'x' per copy of MS Windows. That price is high enough that they can't compete with other PC OEMs. If however they meet certain criteria, Microsoft refunds a portion of 'x', effectively giving them a lower price. If however they don't meet Microsoft's criteria, then they don't get the refund. They then either have to swallow the price differential (which is not easy on their thin margins), or charge more money for their PCs (and so lose sales).

Some of the things that PC vendors are *not* allowed to do are:

1) Sell the same hardware offering both MS Windows and a competing OS.

2) Sell similar hardware with a competing OS at a lower price. What they have to do is either just charge more, or else bundle that PC with additional hardware which raises its effective price.

3) Sell the hardware with the price of MS Windows broken out as a line item, or sell the hardware with MS Windows as an extra cost item. (Although in some countries PC vendors have to offer this due to local laws).

Some of the major PC vendors have recently been seeing how far they can push things and are offering things like Linux on some models. A lot of the PC OEMs have been burned pretty badly by the MS Vista fiasco, and are starting to flex their muscles. Things haven't gone far enough though for Microsoft to push the big red "nuclear war" button *yet*.

Apple gets away with it with OS/X because they sell it on their own hardware through their own distribution channels. Server sales are also different, because Microsoft has only ever had a minor position on servers and so just doesn't have that kind of leverage in that market.

So, to sell your hypothetical OS, you would either need to establish your own hardware and distribution channels (like Apple), or sell to people willing to build their own PCs. The first option is not that easy. The second option is probably less easy considering that most people who are willing to build their own PC hardware would rather just put Linux or BSD or OpenSolaris on it. Your third option would be to sell to people who are willing to buy a PC from an OEM and then install your OS on it, and so effectively paying for a copy of MS Windows *plus* a copy of your OS.

The point of the above is that having a better or a cheaper product is often not enough by itself to be successful. You have to have some means of getting it to customers. If one or more established vendors control the distribution channels, or control some other "toll gate", then your product would have to be vastly superior to overcome those barriers.

In the automation industry, the "toll gates" are network protocols and programming software interfaces. This is why the big automation vendors want to control these things. With CAD software, its the drawing file formats, which is why AutoCAD wants to control the DWG format.

That argument has little basis. Microsoft sells orders of magnitude more money worth of software than AB - it's a matter of economy of scale. In nitch markets vendors sell lower quantities of software, typically at higher prices. If someone could profitably sell a better product for such industries at a more favorable price they probably would.

To determine if the software value is worth it for you, simply weigh the cost versus benefits considering alternatives.

I don't see how you can reasonably expect a top notch piece of software to be included, updated, and supported for free in this specific industry. I am a fan of the idea and open source. Too bad such things don't currently exist for us.

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com
"Design Simplicity Cures Engineered Complexity"

It's even more elementary than that. The reason
AB/Rockwell sells it's software for that much money is that you will pay that much money.

I don't buy the support, upgrade, etc justification. Most of their products could easily be the product of a small software house and in case you hadn't noticed, support is a profit center for these guys.

Every other Windows application has all the same
issues and most have a much more aggressive churn rate.  If they can float the "cost of business" justification for their outrageous pricing, they've got a lot of people fooled. Visit any local ISV and ask them if they would like the business for half the margin.  And others with nowhere near the revenue levels of AB/RS do give the software away and support it free as well.  Let's get real. The cost to replicate a a package is a lot closer to $5.00 than $5000.

Support is billed separately and exquisitely expensive, unless you use it a lot.  If they aren't making scads of money, it's because they aren't efficient enough to be in today's software business.

Regards
cww

Damn, seems like every time I turn around Curt and I agree on something.

--
Michael Batchelor
www.IndustrialInformatics.com

Surely it's all about the value of the return.

Someone once told me they happily paid £1000 for an early calculator, because it had a square root button, and it saved them hours of design time every day.

And way back in the 80s, we once wrote some software for an engineering company for doing their gear calculations. It allowed them to do a design in five minutes when it previously took them a week at the drawing board. Not unsurprisingly, they were very happy to pay over £1000 for it.

You have to view the programming software as a means of improving the productivity of the end user's automation - and it's either worth buying it or it ain't.

Don't forget that before programming software, we had to buy programming terminals - and they cost a lot more than $1000 (as well as weighing a ton - anyone remember the T50?!). ICOM started out as a two-man company; they reverse-engineered the protocols and program structure and developed a far superior (and much cheaper) programming tool compared to these dedicated terminals. The reason it caught on with automation companies is because it very quickly paid for itself many times over. A similar thing happened here in the UK with Siemens S5 in the 80s.

When AB realised their terminals couldn't compete with PC-based programming tools, they tried developing their own and when they failed horribly (APS!), they simply bought ICOM - and succeeded (at least for a while) in keeping the excellent team together. My bet is if anyone thought it would be profitable to "do another ICOM" and produce an independent, commercially viable programming tool, it would have happened by now.

It hasn't, because developing and supporting progamming software IS expensive. The reason MS can sell Windows for $400 is because they sell MILLIONS of copies. PLC users don't present that kind of market, so the costs have to be spread among fewer buyers.

However, one underhand trick the PLC manufacturers do pull is to keep their comms protocols secret these days. For example, back in the 80's, the DF1 protocol was published openly - anyone could design a program for any device to read and write PLC data through a plain old serial port. For the more ambitious, ICOM used to sell a C library so your DOS applications could talk via a KT card. No more. You HAVE to buy RSLinx. This is the kind of profiteering that the PLC manufacturers should be made to feel ashamed of: ethernet hardware costs pennies and TCP/IP protocols are open to the world - unless PLCs are involved. Then you are back to buying hardware and software costing thousands.

An interesting debate indeed.

To the last 2 posts... you get what you pay for!! No question... and please don't forget that free software supports the sale of 'MY' hardware... be careful... no disrespect to the freebies out there... but you do it for a reason!

I worked for an Industrial software vendor in the late 80's. Microsoft has sold more software In the time it has taken me to type this message (even with 9 fingers!! - right Walt!!!) than the leading HMI vendor sold in the whole year!!!!!

That’s why... and by the way the support burden of the industrial guys is painful... seems that if someone pays 3000 bucks for software they are entitled to a 10 hour phone call...

Really!!!! Its about economies of scale... and function. Whatever you use - pay it... and be happy about it.

Wanna go back to the days of sealed terminal keyboards, cassette tapes, and no editing???

Sorry had a bad day! :) Happy Thirstday to all...

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesign.com Manufacturing Automation www[.]automationmag.com

I agree totally with all economics of scale arguements, and have been touting it on this list for 10 years.........................

CODB

Cost of Doing Business

Dave Ferguson

True enuff Dave!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

They can simply justify it on the basis of demand and volume.

Microsoft can spread their costs over 10,000 times more customers. I am sure if you can guarantee Rockwell the same number of customers as Microsoft has, they will match any and all prices you quoted.

One is an Operating system on most (no bashing) computers and the other is a specialized software for a specialized industry.

Dave Ferguson

The sad thing is that should any other PLC technology start emerging it will probably be gobbled up by one of the big companies where the same sales tactics and support tactics will be applied.

I think we should look through the 'win-win' perspective.

If any PLC software redounds me, I can happily pay for it.

Also it should be nice if all PLC vendors document and open their any communication protocols to permit their customers to build their own software. This would be a better business model.

For example, OMRON is my favorite vendor with its documentation, I can develop my own ActiveX controls instead of using vendor's components. When my customers require simple applications, I don't pay for a huge software with unnecessary specialties for my project.

Also I have developed a freeware ethernet communication component for OMRON, and publishing it in my site. (http://indanotes.blogspot.com/2008/11/indafins-omron-fins-ocx.html) I believe that this not harms OMRON, encourages their customers to buy OMRON hardware for their low cost projects.

I think the best way is publishing detailed documentation.

$1200 for an automation software isn't really that expensive for the responsibility it holds right? Few hundred bucks you are looking at widely sold Windows Vista... Microsoft Office, Adobe Photoshop aint cheap either. I don't like the renewable license fee idea but an office worker probably cost more than that per month right?

There are things like patent, proprietary stuffs where the main purpose is so the holder can make profit out of it and other competitors cannot simply clone them. If the software can be easily replaced, of course it's good for end user but would be more competitive for suppliers.

The real killer is not the software license fee itself as you'r just paying $1200, but isn't it normal for suppliers to charge much more on slight modification/configurations?

Just buy it. If you want your bugs fixing, the software testing and updating, buy it. Free software is out of control.

Stay in control

<Just buy it. If you want your bugs fixing, the software testing and updating, buy it. Free software is out of control. Stay in control.>

That's an interesting point of view from someone who uses Windows. :^)

Isn't this just the dumbest argument ever.

When you write a program for a PLC or DCS or setup a SCADA system or commission VFD do you expect the customer to PAY you for your skill and your time?

It doesn't matter what skills anyone has or how much experience we all expect to get paid. It will not surprise me if the clowns who started this are the same clowns responsible for the stuff ups the rest of us have to fix.

Have any of us ever heard a good competant programmer complain about the cost of software, the way some of these clowns have? If your good enough to earn a living programming then you should have enough to pay for the software.

Hear, hear - I just bought a microprocessor for $3.75, and the compiler costs $1200. So what? Basic cost of being in the game. Get used to it!

Hugo

Another interesting point of view. It would have a lot more traction if a very large part of this forum weren't about very expensive software stuff ups that can't be fixed by you or me and won't be fixed by the "clowns" who wrote them. And it's "protected" by one sided licenses that absolve them of any and all responsibility, yet prohibit the user from doing anything besides attempting to use them.

What other product can you think of that gets that kind of legal freedom, even to the point that you are prohibited from publishing a review to warn others?

OSS isn't all about cost. I and many others would gladly pay prevailing prices for a product that can be fixed or changed to
meet unique needs. Or pay for support that actually attempts to solve problems with the software. For software that you actually own and can use as you will. Please tell me, honestly now, which model is unreasonable?

The current status quo is an extremely anti consumer model, possibly the worst example of corruption in a free market, where government enforces the unilateral interest of industry against the interests of consumers. Think about it, compare it to any other product. It would more properly be the policy of a totalitarian regime than a modern democracy, but money talks and this is a singular example of _no_ consumer protection allowed.

It is ridiculous to defend it with any argument that pertains to fairness. Especially yours. No one here has lost a dime to people who want to produce and distribute software more in the public interest. Those who do are free to compete fairly.

Regards
cww

Curt: You're arguing with people who claim that anything that is free is worthless. And they are offering their opinion to you for free. You can take that for what it's worth.

If anyone wants to pay me $1200 for this opinion, I'll gladly accept your money. If you have any doubts about the value of this opinion, then I'll offer to double the price to $2400 just to make it even more valuable. I even offer an annual service contract at a very attractive rate that will keep your opinion up to date.

Don't listen to any opinions that you might see elsewhere. They'll just cost you more money in the end. I have market studies that prove conclusively that this is the only opinion worth having.

Now I'll sit back and see if people are willing to put their money where their mouth (or rather, my wallet) is. Believe me, I worked very hard on this opinion, so I deserve your money.

Tony, there's a big difference between an end-user application and a required configuration tool for hardware. Note that the VFD's you mentioned often have free configuration software. True, PLC programming software is rather more complicated. That doesn't stop Visual Studio Express, Eclipse, and Netbeans being free. All are at least as complicated (and usually vastly more so) than the $5000+ PLC programming software.

By the way, making me pay $5K for PLC software is a bad business model. It means that I can't use your PLC on a one-off project, and I don't want to switch from my current vendor to your brand because it means I'd spend tens of thousands on licenses for my engineers and technicians without getting any improvement in my processes. It also puts you at a severe disadvantage against a company (e.g. Turck) that gives away their programming software. In fact, the original post was a troll / leading question pitching the fact that his company's software was free.

Direct cost isn't the only reason that "free as in beer" and "free as in speech" are better for me, either. Keeping track of licenses is a major pain. A laptop hard drive goes out, and suddenly I spend two days on the phone trying to get everything straightened out.

So no, this ISN'T "the dumbest argument ever." Software is one of the great enablers of productivity, and cost-benefit analysis is an important part of any modern company's business.

Tony: "If you're good enough to earn a living programming then you should have enough to pay for the software."

That's a nonsensical statement. Are you honestly saying that every software package is priced perfectly for every individual and company as long as they're competent? If so, a one-man online T-shirt shop should run SAP and Oracle, and write his business logic using Rational.

-James Ingraham
Sage Automation, Inc.

James,

I hate to put it bluntly but, I know who you work for and I know some of the history of Sage Automation. I suggest before you keep on about businees models you have a decent chat to Andrew and learn a few things.

I have worked in manufacturing (special purpose machinery) on projects as little as $20k. I now work in resources (yes I whored my self off to WA inc.) and have worked on multi-billion$ projects. When you did your businees degree and learnt terms like "business model" did you also learn about "economies of scale".

To a small project under $100k an RS5000 or Step 7 license is about %5 of the project cost. On a $1B iron ore project a license for each PLC is a fraction of a percent. Each trainload of iron ore earns about $1,000,000 net. Go have a good look at what production machines are worth and what they earn per hour, what you are talking about is near meaningless.

You want to talk about real money then talk about downtime. Most customers have very little of variety of PLC or DCS or robot, or VSD for the simple reason it saves on cost and the biggest cost is downtime. How many places does Sage work at where there is great variety of PLCs. Your client GM in Adelaide. What does their main line cost to be down. Or Ford in Melbourne for that matter. I know Sage works at both. How many differant type of PLC do they have or safety systems or other things? Its got nothing to do with licenses and everything to do with service/maintenance/downtime. Even better consider the tier 3 supplier who makes some little widget for Ford or GM. Do you really think when his machine is down and he faced with a penalty clause for failure to deliver that he is going to stop and worry about his PLC license.

If you doubt this go and have a good long chat with Andrew. Do you think he went from his garage to where he now is without learning the real value of things.

For the rest of you. Next time a client asks for a particular PLC, VSD, whatever and you don't have the software, ask to USE THEIRS. The main reason most specify these things is beacuse its WHAT THEY ALREADY HAVE and most importantly SUPPORT.

Tony-

You suggest (twice) that I should talk to "Andrew," but I'm afraid I don't know who that is. You also mention GM and Ford as clients of my company. To the best of my knowledge we have never done any work for either of them. Perhaps there is another Sage Automation that you are confusing us with?

Tony: "When you did your businees degree and learnt terms like "business model" did you also learn about "economies of scale"."

While I suspect this question is facetious and rhetorical, yes, when I studied for my business degree we covered economies of scale.

Tony: "To a small project under $100k...a license is about %5 of the project cost."

Five percent is huge. Even 1% (and a half-million dollar job is about normal for us) is certainly something that can make or break a sale.

Tony: "Go have a good look at what production machines are worth and what they earn per hour, what you are talking about is near meaningless."

In theory, perhaps. In practice, every customer I have will fight to get the initial price down as low as they possibly can, regardless of what the production will eventually be worth.

Tony: "How many places does Sage work at where there is great variety of PLCs."

This is a more interesting question than you might think. Quite a few of my customers specify the type of PLC, but not all. And even the ones that spec it inevitably have some odd balls. The overwhelming majority of my customers prefer Rockwell / Allen-Bradley. Still, there are PLC-5s, SLC-500s, ControlLogix, CompactLogix, MicroLogix (in various flavors). Some plants have switched brands, but lots of the old stuff is still around. One customer I have has a company-wide spec for ControlLogix... and then had two major projects that spec'ed Siemens.

Tony: "Do you really think when his machine is down and he faced with a penalty clause for failure to deliver that he is going to stop and worry about his PLC license."

He'd better. Because thanks to his stupid $5000 license he's about to get hit with a multi-million dollar penalty clause because the one laptop that had the right software went dead, and the floppy disk that the license came on is corrupted, and he can't get tech support to get his license fixed because the group that handles licenses doesn't work nights and weekends, even with a Gold Support Contract. Oh, and the install disks are fried to, but he can't just download the files over the web, he has to wait for the physical media to show up.

"Next time a client asks for a particular PLC, VSD, whatever and you don't have the software, ask to USE THEIRS."

How do I support the machine? They call me at 3 in the morning six years later, and I can't even look at the code.

I stand by the statement in my last post (on Feb 7) when I said that the DISCUSSION is worth having. Licensing, in terms of cost and execution, matters to PLC vendors, OEMs, and end-users.

-James Ingraham
Sage Automation, Inc.

Perspective again....
What if you are not making money selling machines but, instead have to support a dozen brands and a few decades of PLCs because you are in an industry where the machinery comes from vendors that have no reason whatsoever to standardize or to switch to your standard. A couple grand to do one upgrade is insane.

You are pretty much over the barrel. RSLogix is borderline worth the cost because I do a dozen or so new PLCs a year. But the majority of the equipment is something else and spread among everything from ABB to B&R to ERNI with some Mitsubishi and even Omron thrown in. This is a much different situation and the software cost is prohibitive. Not to mention the nightmare of getting every kind of DOS and Windows environment running and fixing crashes because every last one of these guys assumes their software will be the only thing you will attempt to run on the machine.

And relying on vendor service is untenable from a downtime perspective. I agree if you have the optimum situation it's not a big deal. If you don't, the current model is a major PITA.

Regards

cww

Sorry, but this is a piece of the puzzle regarding why manufacturing is fleeing North America.

It's hardly the only reason, but sometimes it's less expensive to pay lower wages to do by hand than to pay for maintenance on automation.

Stupid and sad, but true.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

In reply to Curt Wuollet: I've seen people tear out AB PLCs on brand new machines and throw the PLC in the garbage because it was cheaper to replace the AB PLC with another brand than it was to buy and maintain the software to support it.

On a related note, no doubt many people have noticed the low cost of "netbook" computers (less than $400), and how they seem to be more durable (solid state drives) compared to traditional laptops. I have to wonder whether it would make sense to give every maintenance electrician and technician their own troubleshooting computer instead of having them share one between them. At $400, its cheaper than a Fluke multimeter.

If you have to equip each one with $10,000 worth of software, then it's out of the question. If the software is free though, it's entirely a different story. The computer and software become just another routine tool instead of a special case (and management headache).

It's something to think about when you look at what hardware to buy. It's not just that the software is expensive. It's also that the cost of the software is dictating how you manage your factory.

I find it amazing that the people who laud the vendors who give their software away don't honestly come to grips with what is almost universally true. They give it away because they couldn't sell the crap in the first place.
When something is given away, what does that say about its value?
Profit centers don't exist to support products with resources when there is no realized payback.

You are very wrong, Orion. For example, the configuration software for Hilscher's Profibus adapters is better than HMS's, but HMS is the one that makes me pay for it.

You ignored quite a few examples of high quality free software that I and others mentioned. Visual Stuido Express, NetBeans, Eclipse, Linux, Apache, the GCC, Sun's Java runtime and JDK, OpenOffice.org... There are a lot free-as-in-beer applications out there that are superior to any program Rockwell or Siemens has ever sold at any price.


Orion: "When something is given away, what does that say about its value?"

I take it you didn't see M Griffin's post. To paraphrase, would it make you feel better to pay for them?


Orion: "Profit centers don't exist to support products with resources when there is no realized payback."

In the case of selling PLCs, it this HARDWARE that makes the payback. But without programming software, the PLC is a big paper weight. It's like buying a car, and then they say, "Oh, you want the steering wheel so you can actually drive it? That'll be extra!"

I cannot use Company A's PLC without having the software for it. Therefor, if Company A charges me for their software, it gives me a disincentive to buy their PLC.

-James Ingraham
Sage Automation, Inc.

You know, I don't like it either. But there is a lesson there. The RS of our world have figured out what the value of their software is. You and every one else who's thinking it would be nice if it's free better start thinking about what your value is in the equation, and start charging at that level or else you cheapen yourselves down to nothing. Yeah, it's tough asking for the fair value you are worth, but the sooner you get on with it the better for all concerned. (Hey, and it would finally kill this thread).
Hugo

Hugo wrote:

>You and every one else who's thinking it would be nice if it's free better start thinking about what your value is in the equation, and start charging at that level or else you cheapen yourselves down to nothing.<

The potential value of a project is determined by the owner, not the suppliers. This value is somewhat fixed. If one supplier sucks up so much of a project's cost that the other suppliers cannot add their own products or services to the cost, and keep the project within budget, the project just doesn't get done at all, and no one wins. You cannot just have everyone raise their price because one vendor thinks his products or services are immune to the owner's budget.

That's the interesting thing about this thread. There are many to defend the Major Vendors with their $400 serial cards and ridiculously spendy software and the protection racket after the sale where you get to pay for any of the numerous bugs they may have fixed and get some new ones in the bargain.

And the arguments are often that it somehow is akin to how we, the users and commissioners of systems get paid, as if pushing exorbitant equipment adds or relates to our value in building solutions. But, you and I get paid exactly the same for using a Koyo as we do for using an AB and except for rare exceptions, either will solve the problems that PLCs are good solutions for.

Yet few would insist that you should buy your PC from IBM or Apple because they have "found what they are worth". (Yes, I know IBM doesn't make PCs anymore) And PCs would still be $2500 if they did.
Most will agree that clones do just fine. And although it's still difficult to buy a PC without Windows on it, few would agree that Windows is worth what ever MS decides to charge for it.

I just wish that enough people would see the parallels to make the more "user friendly" competitors more of a threat. And make big automation actually compete on merit and customer relations. And make lock-in the exception rather than the rule. I just don't see a downside for automation people. The wasted money doesn't end up in our pockets.

Regards
cww

That's interesting too...
I find the free software I have is far more valuable than the extremely expensive drek I work with. For one thing the expensive variety always belongs to someone else and the FOSS is mine. If things change, as they are extremely likely to do lately, which has the greater value to me? Even if you have the illusion you own commercial software, that's only because you haven't read the license.

Regards

cww

Having some detailed knowledge of one of the major suppliers, I certainly can confirm that the largest portion of profit is made on hardware. However, while I was with that "major", and after being beaten up often about not making that same margin percentage on services, its not surprising that most majors charge for everything they can. The business model I operated under expects to make a similar margin on all the different areas of products and services they provide. This includes programming software. It is not a model that necessarily looks at the overall package and value to a customer.

The Rockwells and Siemens of the world have an installed base that they can depend on for continuing income, thus they can charge for software/services that some smaller suppliers cannot. The cost to change vendors (with the associated training and spare part support) is just too high except in exceptional cases.

All for profit businesses are designed and are expected to maximize shareholder value. End users are a part of a business activity only if the end user generates shareholder value. I guess I'm just saying that most any company will charge whatever the market will tolerate. If Rockwell Software can charge $1000, $3000 or $10,000 for the same package, what do you think will be listed on the PO?

Maybe opearting under a different business model would make additional money for a supplier but that is not something an established company is willing to do unless they are under duress.

By insisting on a little less one-sided terms, we could easily provide that duress and all would benefit.

Regards
cww

I have found that if I purchase my hardware from a company that sells reconditioned plcs, I can save aproximately 50 to 75% from Allen Bradley's list price. This way I can justify the software cost. The company I use is Tek Supply and they give the same 1 year warranty as AB. Their web site is www.tek-supply.com

Regards,
Bill