Why do you pay for PLC programming software?

G

George G. Robertson, P.E.

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

Vladimir E. Zyubin

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 <[email protected]> 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
 
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.
 
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.
 
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 <[email protected]> http://www.csse.monash.edu.au/~jirib
 
B
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
 
Thanks for your support Larry.
You said everything I was thinking

Lee J Ward
Business Manager - Programming Software
Marketing Group
Schneider Automation
 
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
 
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
 
> 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
 
J

James Ingraham

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
 
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
 
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!
 
B
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
 
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 <[email protected]> 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
 
Top