Why do you pay for PLC programming software?

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.
 
C
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
 
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
 
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
 
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
 
C
&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
 
C
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
 
M

Michael Griffin

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.
 
D
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
 
M

Michael Griffin

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.
 
D
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
 
B
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.
 
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.
 
M

Michael Griffin

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

Michael Griffin

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.
 
M

Michael Griffin

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).
 
A

Armin Steinhoff

>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
 
D
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
 
Top