Why do you pay for PLC programming software?

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
 
S

Steve Myres, PE

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

Michael Griffin

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

DAVCO Automation

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

Michael Griffin

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

Steve Myres, PE

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.
 
C
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
 
C
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
 
W
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.
 
Top