Why do you pay for PLC programming software?

Hi,

Your friendly local moderator here

> Jeez. Talk about the thread that won't die.

I thought that was creating electricty from household water pressure one ;-). Which has been closed after repeated requests from people who read this forum regularly.

These posts to kinds of topics surface from time to time. I usually would keep posting to this topic unless people started to get nasty or I start getting requests to close a topic.

Regards,
Peg Ferraro, Control.com moderator
 
B

Brad Zuercher

Why are so many people short sided, and only see THEIR application and overhead when it comes to PLC software.

RA RSLOGIX 5K can be used to write a program to run your garage door, or run a complete auto-manufacturing plant owned by Ford...or anything in-between.

If you are a hobbyist, then play hobby.
If you are controls engineer, and designing something of value for your customer (especially something with safety or reliability in mind)...the $6K I pay for all of my licenses is peanuts.

If you cant bury $6K (initial investment), and then about about $2K per year to maintain your licenses into your overhead, you need to find another career.
 
Well Said... Those on here that do not see the value in the Rockwell Software Programming tools do not know how to use the tools properly and are as you put "Have a cool Hobby"..

RSLogix 5000 (Studio 5000) with the use of AOP's, AOI's, UDT's and more practically writes the program for you. It allows you to focus on performance and productivity. Not wasting time and energy trying to figure out how to make a toaster communicate with a can opener. A lot of the inexpensive PLC's with "free software" are capable of some extraordinary things if you have the time and do not value productivity of your engineers or in worse case for a company those who think they are saving the company lots of money on hardware but take three times as long creating the application.
 
C
I guess I can't say how RS5000 works, But, I do think RSLogix 500 is the Gold standard for programming packages I have used. And yes, if you get everything AB, it generally does work together without too much hassle. Where the problem comes in, is if your job is to interface toasters and can openers. Or an awful lot of gear not made by AB, applications that don't run on WIndows, etc. My requirements require interfacing an enterprise system that speaks only XML over TCP/IP, to equipment that has only RS232 comms available. And on the same system I run a 40" HDMI display and maintain a deque of data on the product stream I parse from the XML data. I've got a RS485 RTU Modbus tying things together.

On another application I've just finished, I'm reading 2 Linear (custom protocol) scales measuring things, and two 2 axis cnc drills, (shop built) And yes, these things do take some engineering, but most are impossible with even a Contrologix. Many of them could be done at great expense and lots of adapters and convertors and equipment in general and probably a few Windows PCs thrown in. I've got embarrassingly little invested in hardware. I do the hard parts on a couple of Raspberry PIs and interface to the automation world with several Automation Direct Clicks. If I had AB tunnel vision, I would have to say it can't be done or the cost would probably say the same thing. Any difference in the PLC programming time VS RSLogix would be trivial. I would respectfully say that my employer values my productivity and I know for an absolute fact that I am saving money.

So the best I think you could say is that for your use case, for things that you can coerce into the Rockwell worldview, it lets you feel you are being productive and valuable. Much of my workload and an increasingly large part of what people want done is not well served by any of the big automation vendors or at best can be done by adapting your processes and workflow to what they can do with a major investment, licenses, maintenance contracts, and massive proprietary applications. I fail to see where, with the charge toward the cloud and IoT, and the general advancement of technology that you could make the general case that AB/Rockwell technology is the answer.
Oh, And I do know how to use the tools. I just don't like the shop.

Regards
cww
 
It depends on what world and industry you are working in.

If the control system has to meet a SIL level because the process or equipment is potentially dangerous; you must use hardware and software certified for that Safety Integrity Level. This requirement applies to chemical processes, boilers, process furnaces, railways, nuclear plants and many more situations.

You will find that anything that can kill you or blow up has this requirement.

AB PLC's do have safety versions that use an extra safety CPU and safety I/O; all supported by their current software.

In your application; have you addressed all the personnel safety requirements? In regular PLC applications; a large number of PLC's can be supported by just a few software copies or licenses; so the software cost is not very high per PLC.

Some vendors supply a copy of their software with every system and there is no limit on the number of people who can use it to support that system. Triconex a supplier of TMR SIL rated systems does this.
 
B
Curt has some kind of issue with AB that escapes me. He seems to go out of his way to create applications that can't use existing PLC or other standard control hardware. In the real world, these kind of automation applications are very rare. How he manages to get so many of them is a mystery to me.

The thing is that in the end the difference in cost between AB and other brands just does not matter to most of the users who are actually using the products. The cost of the software and the little bit of extra cost on the hardware is not as important as the cost of training and spare parts and keeping things up and running.

The problem with Curt's approach to hacking something together from the cheapest hardware he can find is that it relies on him being there to maintain it. I can pretty much guarantee that the guy who takes over when he moves on will curse him for his choices.

As far it being "impossible" to run a simple 2 axis CNC drill on a Controllogix, my guess is that it is a lot simpler for someone familiar with CLX motion than to hack together a bunch of stuff never intended for this kind of thing. If one does not know how to use CLX effectively, it isunderstandable that one might think it is simpler to do it some other way. It does take some time and experience to get used to the AB solutions for this kind of thing.

It may be that CLX is not a good option, but certainly a Fanuc option is readily available that would handle it.

There are things that GP PLCs don't do well, and it is best not to try and shoehorn them into those applications. Knowing what they can and cannot do takes some understanding and experience with the product line.

I wish someone had an Ethernet/IP to GPIB adapter. AB CLX now supports native TCP/IP comms so one could probably make a regular Ethernet to GPIB adapter work, but it would be nice it it was simpler, and I did not have to support it. It would open up a whole world of test stand applications to the PLC world.
 
D

Dave Ferguson

Curt, Curt, Curt we have this discussion over and over.......just finished a Provox DCS conversion project (start up all last week) ...... 6 Controllogix processors, 12 clients, 2 esxi stacks running running 6-8 servers each, 24/7/365 PGW plant with 22 full rack of discrete 16 point cards, and 14 full racks of 16 point Hart in and 8 point Hart outs....36 racks of I/O.....full Rockwell PlantPax blocks and faceplates.......so every control module tells you what is holding a device out, why it tripped, the last 10 trips on every device from the glass......sequencers, alarm systems, full Historians with ties to plant wide historian systems, SQL SSRS reports etc etc etc....we were done a day early and started up the first try......very very little massaging.....plan plan plan.

Not going to be doing this with with raspberry PI, and a soldering gun and a copy of MySQL........no bashing intended.

We have trained Maintenance people on one standard of equipment and we pay to train them, we can hire them with this experience and we follow standards to keep it easier......the HMI tells the human what is wrong without going into the machine (as it should be). Every permissive or interlock is displayed and when things go out, it tells you why and a big chunk of it is programmable from the faceplates and was bulk built and setup with excel and online tools.

I have done multi axis robot systems with Clogix, entire Woodrooms, feed decks, drive systems and on and on and the next one is bigger yet...

We pay for it, we trust it and we can support it ....... On almost all of these conversions......our troubles lie in the one off custom "save a buck" stuff. Stuff done with one off equipment and one off programming and trying to figure out what they were thinking and trying to accomplish.

When big money is on the line, it takes more than a few mail order parts and a soldering gun........but then again, you knew where I stood on the topic. Again my management knows that it takes money to make money 24/7/365 and don't want the risk of my leaving jeopardizing their plant.......

Dave Ferguson
Control Systems Engineer
 
C
That was one of my points, there are a whole spectrum of use cases. For new work, I mostly do custom machine building and integrating machines that were often not intended to be integrated. This requires much greater flexibility than processes that lend themselves to the mainstream controllers and hardware. And gluing them into the enterprise systems requires Open protocols that don't excite big automation. So, even if I was given carte blanche at the local AB distributor and cost was no object, AB still couldn't provide the solutions. And the parts they could do would actually be harder than using appropriate tools. And I shouldn't be picking on AB, no one else is shading toward the IoT, best of breed, and Open protocols. They do provide some ways to integrate with enterprise systems, but they are inflexible and seldom do exactly what you want to do.

Regards
cww
 
C
Hi Bob

I'm curious, what would the Ethernet I/P input look like for a GPIB (IEEE488) adapter? Unlisten and Untalk etc. box commands? I agree that it would make testing components and certain other processes much easier. But why did (does?) GPIB work? Because it was an Open Standard (for the time) and eventually you could get test equipment from many manufacturers and assemble a solution. Yes, it was useful when it was all HP, but it was far more useful when you could fill in the holes with the "best of breed" for that need. And once you could write applications in something besides HP basic, it became a lab standard.

I find it ironic that you should mention it, as the norm was to "cobble together" the instruments you needed and write the "glue code" to make an application. Kinda like today, at the (dis)junction of computers and instrumentation.

Later came Matlab etal. IIRC to make things easier. And yes, I wrote a great deal of Turbo Pascal code (Basic was too slow) to automate
component testing.

The point is, different arena, different norms. But because the language and the buss were standards. no one worried about if I would be around to maintain it. Most lab rats of the day knew GPIB and BASIC or Pascal, because.......That was the way you did things.

The strange thing is, it feels just like that, using Python and Pi's to tie islands of automation together using the few open spigots they provide and a few internet protocols to deliver the results. Oh, by the way, I'm also sure Fanuc could set me up with a couple of CNC drills, maybe as low as $50k per axis.

That proposal would go noplace. $1k per spindle was very attractive. And they use the G-Code standard, just like the Fanuc would.

There would be a warm place in my heart for GPIB/TCP, but not for GPIB/EthernetIP. And a much, much, larger potential user base.

Criticize as you will, I find you can accomplish a lot wider variety of things, for a lot less, if you have the largest possible toolbox. And use things that work together. Face it, the demands are getting broader rather than narrower, that why we have PACs instead of PLCs. It's too little, too late. It's a lot like the situation for the Party in China, "How do we open things up without becoming completely irrelevant"? When you can get an extremely powerful computer with no moving parts for $35, I start checking the wall for handwriting.

Would you rather I pick on Siemens?

Glad to hear from you!

cww
 
C
That's great Dave, how would you build my machine? :^).

And I don't use MySQL they have existing DBs for that.

No offense Dave, but not relevant, not even the same universe.

You are using those tools where they are appropriate.

They don't sound very good for building small specialized machines. It could probably be done.

My tools wouldn't be appropriate for building clock-radios, but I could make a pretty cool one with the Pi and a the 7" touchscreen for $100. But $100 is a lot for a clock-radio.

Same comparison, give or take a few orders of magnitude.

Regards
cww
 
As a business owner and consumer of these devices and processes, I prefer a scaled approach as proposed by Mr. Wuollet. Those with a broad appreciation for the entire spectrum of possible solutions, how and when to apply them will always be far more useful to industry than those who remain narrowly focused on a single tool.

Somewhere above analogous mention was made of a hammer. The old adage from Maslow is true: when all you have (or have knowledge of) is a hammer, everything looks like a nail. I fear that the PLC manufacturers and to an extent those who have consumed their brand of cool-aid are in fact doing a disservice to their clients or potential clients. By not offering a range of solutions or an interchangeable standard, the manufacturers like AB and Rockwell are artificially trying to eliminate competition by forcing you to chose their proverbial hammer. Let the best rise to the top through open standards and true competition. Programmers beware, the same applies to you as well. Kids are being exposed to coding in middle school. As a result, the mysticism is being removed.

It is only a matter of time before a disruptive technology loosens or eliminates the stranglehold companies like AB/Rockwell are attempting to keep on automation.
 
Look at the wide range of PLC's that Rockwell sells; from fixed IO micros, to SLC, to PLC-5, to limited size ControlLogic to multiple 13 slot chassis systems, safety PLC versions; and now the TMR SIL rated safety PLC's from ACS Triplex.

And communication that ranges from DH+, DeviceNet, ControlNet, DH on Ethernet and Ethernet I/O. I would say that some PLC manufacturers have a wide range of systems to match their customers needs.
 
C
And I would agree. I've used a lot of Rockwell gear and it's still running. But It makes the most sense when the requirements include that you use Rockwell gear and cost is no object. But, when you start to color outside the lines and you need to interface to an enterprise system that only speaks say, XML over a TCP/IP socket. And you need say a serial link that needs to speak to a Zebra printer, another for a remote display. and a third to talk to a scale reader and the customer wants a local touchscreen HMI, it would get really bulky and expensive to do it with Rockwell gear if at all.

I did it with a $35 Raspberry Pi, a $60 integrated touchscreen display, and a $40 IO module. I get the standard Ethernet with the standard Internet protocol suite that will talk to anything. Four USB ports that can be adapted inexpensively to any serial requirement. In addition to the integrated touchscreen display, I can plug in any size commodity HDMI display for the cost of said display. I do this in a 6 X 9 X 2 inch cabinet with room for the serial adapters, And I have 8 inputs and 8 outputs, expandable X 4, if needed. All for less than 25 watts.

It all runs on a 1200 Mhz. 64 bit, quad core ARM v8 processor with a fairly powerful GPU, running a widely used, well supported version of Linux. It has no moving parts. It can run say MySQL, if a database is needed, your _choice_ of webservers, can directly use cloud services, etc, etc. It can comfortably and asynchronously run all that comms gear at speed. Pretty much anything that can be done with a PC and a PLC.

But this was hijacked from the software thread, so let's get on topic. No, I can't do this using RLL or CoDeSys with a Rockwell IDE, having tried CCWorkbench, I'm not shedding any tears.

I do this with Python with the nice Geany IDE. This allows the machine to be self hosted. I can connect from any PC in the plant. I am fairly new with Python, but I have been able to do this. It's not an "automation" language. I wouldn't want to write massive amounts of logic with it, but it excels for the display and interfacing work, XML parsing, string handling, TCP/IP and serial communications, these are much easier and more flexible than with the box commands kludged into PLCs and a great deal faster as well. Each comm process runs in a thread and so far, no waiting. It's all free and there's no problem mixing and matching. I can use nano (text editor) on an ancient PC or even Eclipse (a full blown IDE for several languages) on faster hardware.

I can pick a different database or call programs written in C or whatever. I have a full non-volatile filesystem. And a truly vast array of open example code to learn from. And no licenses, EULAs,
restrictions,keys, etc. I've done things both ways and i think it's fair to say that simple things are easier to do with PLC tools, but the complicated things that are more and more in demand, are easier to do with SBCs. And people expect that you can connect anything to anything. And they are open to using whatever you need to do it. Some requirements were simply no go with "automation" gear. I find saying "Yes, I can do that" sells better than "This is what I can do and you'll have to adapt all the other stuff to it".

Regards
cww
 
Hello Curt,

I share your aspects.

Here most of the time i use C/C++ but Lua is also an option for our OSS project pvbrowser.

For data acquisition there are a lot (too much) standards from a lot of companies with their own ecosystem. Simply write daemons that read the inputs from these "standards" of communication and store them in a shared memory from where you can read them without the need to follow these "standards".

Here you can see a result from my tinkering around with the Raspberry Pi and our pvbrowser.
http://pvbrowser.de/pvbrowser/index.php?lang=en&menu=3&left=25
 
C

Chris Singletary

>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 don't agree. Hardware costs are engineering, prototyping, testing (QA/QC), stuffing. etc.. for EACH type module and then there is power supplies, Racks, communication modules, etc. The logistix for hardware supplies alone are rigorous and time consuming. Software on the other hand has very little material cost up front. This is mainly about programmers time while considerable, is more universal across platforms and modules.

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

IDEC has proven you don't have to charge for software to sell PLC hardware successfully. For that matter if I was in charge of PLC's I wouldn't use Allen Bradley for most anything. IDEC is a 10th the cost per IO and with the almost free software it would save a company a lot of money to go with them in the first place.

>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 essential to an automation
>system
 
T
IDEC plcs are better and the software is free. I have never seen an IDEC plc go bad [and I'm old]. The software is easier to use too.
 
>My question is simple, but the answer escapes me. To all
>you devoted Allen Bradley people and to everyone else who
>uses PLCs, why do you pay for their programming software?

Because I don't know how to steal it. LOL
 
J

Jeremy Pollard

Why do you think you should get for nothing??? It provides value and allows us that use the best platform to develop in, so we can provide services which we get paid for.

I have worked with software companies and you need to know there is big money in development as well as support.

Now paying too much? Another argument!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
Crisis, necessity, change

Integrator, Educator, Consulting, Columnist - Control Design
 
R
I grew up on Logix 500, and now the new logix 5000 is also very powerful. but for the price...HORRIBLE. Automation Direct Productivity 2000 and 3000 are free. I also use unitronics. HMI options not as awesome as Siemens or AB, but FREE.

Siemens is also incredibly expensive, but the TIA portal is the best world class integrated software out there. It smokes AB.

For small i/o systems I never use AB unless it needs to have a high MTBF. They have 4 million hour MTBF controllers for SIL3. [guardmaster and micro 820].
 
Top