Why do you pay for PLC programming software?

C
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.
 
C
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.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

> 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
 
C

Calvin McGowan

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 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?
 
C

Curt Wuollet

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
 
G

George Robertson

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
[email protected]
(915) 366-4252
 
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.
 
M

Michael Griffin

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
************************
 
B
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
 
C

Chiron Consulting

> 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
 
V

Vladimir E. Zyubin

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:[email protected]
 
A

Anthony Kerstens

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.
 
C
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
 
G

George Robertson

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
[email protected]
(915) 366-4252
 
> > 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 <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
J

James Ingraham

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.
 
S
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
 
Top