Why do you pay for PLC programming software?

M

Michael Griffin

In reply to Kevin Cooper: I don't see what R&D has to do with language standards. Few if any of the vendors are doing any R&D on programming languages.

I believe that the real problem with this ongoing situation is that customers are losing a lot more from it in wasteful duplicated training and lost productivity than vendors are gaining from locking in customers. This is a net economic loss, not just a re-distribution of revenue.

Automation software is stuck in the equivalent of what was the early 1960s for the computing industry and will remain there until some very deep rooted problems are addressed in this industry. Every automation project involves re-inventing the same wheels over and over again in different proprietary languages. The development of specialised re-usable libraries and techniques which have been the key to advancement in computer programming is not happening in PLC programming because there are no common languages to express them in. The shear wastefulness of it all is appalling.

I would have to say that given the current situation, even a bad standard that was supported by everyone would be better than no standard at all.
 
M

Michael Griffin

In reply to Curt Wuollet: I've used QCad for electrical schematics. It most definitely does the job. However, what is "XSchema" that you refer to in this context? The only reference I can find to it is as an XML "Document Definition Markup Language", which I am sure is not what you intended to refer to.

As an aside (and ever further off topic), my opinion on how standard electrical schematics *ought* to be done is that the simple standard stuff should be automatically generated from the BOM list, not the other way around. That is, I should be able to fill in a spreadsheet with all the devices and the I/O addresses where they will be used, and the schematic software should make the drawings for me. Simple drawings could be auto-generated by merging standard blocks into drawing templates. You would still need CAD software for the non-routine drawings. Things like I/O drawings though are very simple and repetitive, but make up the bulk of a drawing set. You may recall discussing this several years ago on this list.
 
You don't want to wish that. It takes about six months of sitting in a cubicle littered with 2000 or so caffinated beverage containers to fully understand how to work the symbolic debugger of just one ANSI C compiler implementation. IEC programming enviroments are a walk in the park compared to that.

I think most engineers here have seen enough computer programming languages or PLC instruction sets to pick up a new one up within a few hours or days. It's the development environment that takes time to understand and that problem is not solved by a common language.
 
K

Ken Emmons Jr.

I agree with your statement regarding schematics. I personally don't generate schematics for IO, but rather have an IO list that, when needed, refers to schematics for things that are not point-to-point. Having schematics that detail terminal block A-1 wires to Terminal block B-34 is really difficult to read, but in a table it is easy to refer to.
 
K

Ken Emmons Jr.

I agree that we are stuck in time, and something needs to change, but I disagree that a bad standard is better than no standard. I don't see that IEC-61131 is visionary by any means, but rather it is a collection of loosely coupled band-aids that is trying to appease the masses but really doesn't please anyone fully. The reason people use standards is that they are good ones, and someone leads the way, and the rest have to follow.

There are so many added features and legacy crap thrown into IEC that reading the standard is rather sickening. For instance, who really uses all of the action qualifiers within the SFC language? Its set up to do machine control in the low level, but everyone I've talked to says things like "SFC is good for high level control", which really means: "SFC is piggy and resource heavy, so only use it for high level organization."

The late 70s and early 80s was a time when brilliant engineers and programmers crafted a lot of groundwork and were able to get paid well for it. Management didn't quite know how to get their claws on software at that time so things were able to flourish in the underground of corporations. Now with tight budgets and poor investment in R&D, how are things going to evolve? I think we are at a crossroads, but I really don't know which way things will go.

~Ken
 
C
Wouldn't it be great if someone had the time and inclination to craft something like this in the OSS world. With QCad or some other OSS software package as the basis, a fairly barebones framework might just be the "Stone Soup" needed to get some folks each adding a gadget to allow mere mortals and sole proprietors to have powerful automated drawing tools. You might get snuffed by Autodesk, but I'm surprised there isn't more OSS CAD and verticals work.

Regards

cww who barely has time to read this list anymore.
 
J

Jeremy Pollard

Sorry - I was misunderstood.. I was more referring to the generally accepted way of programming, instruction set, compatibility between compilers, etc.. not that control programming should be as funky as C programming...

I have reviewed many software packages, and I would agree that the interface can be challenging. IEC based packages arguably provide a similar interface. The target hardware quirks is what I find the most 'uhhhh' factor:)

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579
 
J

James Ingraham

I certainly feel sympathy for people who have 40+ different PLC / cable / software combinations to support. I'm at about 25 myself. In ten years of being a "controls programmer", Logix is the best solution I've got right now. Yes, cost counts. Yes, purchasing continually fights with Rockwell on pricing, especially when our customers tell us they are paying less than we are for Rockwell parts. (We're an OEM.) But it's a pretty darn good solution.

This isn't to say that there aren't other perfectly good ways to do things. I've got systems in the field running on Windows, and while my company has never shipped a Linux system I've seen plenty of them. Modicon seems to have vanished off the face of the earth, and now Siemens is the "other brand" we get requests for all the time. Does this make life diffuclt? Yes. What could solve it?

1) Every device should have an Ethernet port. Not as an option, but as standard. "But hey!" I hear you cry, "they can't just put free Ethernet ports on everything!" Someone can check me on this, but I seriously doubt that a serial UART is cheaper than an Ethernet MAC. Get rid of serial ports, put Ethernet ports.

2) Everything with an Ethernet port should have TCP/IP support. Throw UDP and SCTP in for good measure. Make sure there's a Web page for status and configuration. This should be obvious, but it's worth stating.

3) The top level protocol is the problem. It seems we're down to EtherNet/IP and ProfiNet as the majors. Modbus/TCP is still my favorite, but it looks like it was just a stop-gap for when Ethernet first started on the factory floor. I can live with this, except for one major complaint about ProfiNet (see 4 below)

4) Everything should be multi-platform. This is a serious failing of ProfiNet, which is based on DCOM, which is NOT a nice cross-platfrom protocol. I'm also talking about the programming software. I don't care if you use Java, C++/Qt, Ruby, or hand-coded assembly, but by god make sure it runs on Windows, Linux, and Mac. Pick a good way of doing this and you'll get all 3 for the price of 1, plus a bunch of other platforms like handhelds.

5) Funny how everyone's talking about "standards," when in fact there are only a handfull of companies that make PLC programming software. Obviously some of the big boys roll their own, but a lot of the small players are re-packaging a licensed product. Examples are InduSoft and CoDeSys. I find these both to be similar to Siemens Step-7. So really the only time I have to switch my thinking is going between Rockwell and anybody else. But I vastly prefer Rockwell.

Well, that was probably a completely pointless diatribe. I guess I just like the sound of my own typing. But I meant every word of it.

-James Ingraham
Sage Automation, Inc.
 
M

Michael Griffin

In reply to Ken Emmons Jr.: I probably phrased my previous message poorly. By a "bad standard that everyone supported", I meant a standard whereby even if the language features were not ideal, it was at least a standard that was used identically by everyone. A standard can be improved over time. At present, we really don't have one as just about anything can be called "IEC-61131-3 compliant".

I do not agree that "the reason people use standards is that they are good ones". There are many cases where it is less important that we have an ideal solution than it is that we have a common one. Think for example of railway gauges. "Standard" gauge isn't ideal for all applications, but the advantages of having a common gauge usually outweigh the disadvantages of a less than ideal gauge for any individual line.

Of course I would prefer a universally accepted "perfect" standard, but that doesn't seem to be on offer by anyone at this time either.

As for whether "SFC is piggy and resource heavy", that is an implementation problem, not an inherent characteristic of the language. The problem with many implementations is that the particular target PLC was never designed to directly support SFC, so the missing PLC functionality has to be emulated with large blocks of IL. The quality of any auto-generated code is usually very poor when you have a large semantic gap between the language and the underlying platform.

SFC is a form of Grafcet, and so isn't anything new. Indeed, nothing in IEC-61131-3 was supposed to be new. It was supposed to just winnow down existing practise to a smaller consistent set. That unfortunately, didn't happen.
 
M

Michael Griffin

I believe what Mr. Pollard meant was that ANSI 'C' is a good example of a programming standard that actually works. You can take a program written in ANSI 'C' and re-compile it with a different compiler on a different platform, and have it compile and run with little or no change to it. This is what people want to be able to do with PLC programs written in ladder or IL.
 
M

Michael Griffin

In reply to Curt Wuollet: I have too many projects on my plate already at this time to look at doing something like this (automatic schematics generation). I took a quick look though at what is available to work with.

There appears to be someone who recently (about six weeks ago) started a project on SourceForge which seems to be somewhat related. The project description is: "Interkonekto is a program which draws interconnection diagrams from tabular data read in a set of text files. The input layout model and generated output drawings are DXF files, compatible with the original specification from Autodesk." There's nothing there yet, as he has apparently just started on this.

Independently of the above, I looked at what would be involved to do a project like this. The most obvious thing to do would be to let the user create "template" drawings with "dummy" block devices (e.g. sensors, actuators, etc.) using an existing CAD program in DXF format. These would have all wires, etc. already drawn in. They would also create drawings of I/O devices as blocks.

The user would then separately create lists of I/O devices together with the I/O addresses, the pages they want them to appear on, and the templates they want to use for each page. The program would go through the list, make copies of the template drawings for each page, insert the device blocks, renumber the wires and devices, number the pages, etc. This is more or less what most people do manually with their CAD software already.

Ideally, the substitutions would be done without the program trying to understand the actual drawing contents, except for re-writing the wire numbers and device names. The most difficult (or at least time consuming) part of this would be learning enough about the DXF format to do this properly.

Also ideally, the user created lists would be in a standard spreadsheet file (ODF ISO/IEC 26300 format is the obvious one). There is a python library called "py-odftools" which may be usable for this. The reason for using a spreadsheet to enter the data is that the concept is you are creating this list anyway for use in a BOM.

The above is more or less what I had in mind, but as I said I already have too much to do to look at it for at least a couple of years. If anyone else wants to give it a try though, they are welcome to use the above ideas.
 
Really you mean Rockwell is the best solution you have been exposed to. There are manufacturers out there that are light years ahead with vastly superior real time Ethernet solutions.
 
K

Karsten Schneider

Hi James,

Just wanted to point out that PROFINET does not mean you have to use DCOM. There is one appication within PROFINET (which is CBA = Component Based Automation) which uses DCOM but all the rest of PROFINET is not. Like I/O, motion control, safety, etc. PROFINET stacks and Dev-Kits are available on a variety of platforms from different vendors (Hilscher, Softing, GridConnect, Siemens...).

Hope this helps,
Karsten Schneider
PROFI Interface Center
 
K
Actually Michael this thread is about "Why do you pay for PLC programming software?”. I was simply trying to make the point that it would be great to have a free, open, and standarised plc programming platform. The reality though (for now) is that it isn't happening. With the divergence of this discussion it is apparent that it won't happen soon. At present the best plc programming software that I have used has probably been the most expensive, while the worst has been approximately the least expensive. Obviously development costs have a lot to do with this. It seems that no one really wants to develop a package that programs everything, has every bell and whistle, and is wide open allowing others to tinker- all for free. A primary difference in the plc market and the pc market is that there aren't millions of programmable controllers sold everyday. Not everyone has them, or even knows what they are, so it's a bit of a niche market.
 
I think that Allen-Bradley and Automation Direct could learn a lot from each other, but I don't think Allen-Bradley's products are better than anyone else's. I use both platforms. Logix has features I wish DirectSoft had, and DirectSoft has features I wish Logix had.

Aside from the features, there is no reason you should have to purchase separate software to communicate with your controllers after having already been raped on the price of programming software. Getting RSLinx to communicate with a controller can be a real pain. It's a breeze with DirectSoft. Rockwell gets away with it, which is exactly why they continue to do it.

You get a hell of a lot more for your money with Automation Direct controllers and hardware than you do with Allen-Bradley. The only reason I use Allen-Bradley is because they are the company's standard for use in the equipment I work on. I used solely Automation Direct in my previous department.

You also get free Tech Support from Automation Direct. Allen-Bradley wants you to pay a crapload for tech support, two craploads if you want nights and weekends. I've been saying "to hell with A-B" for years. :)

I think Cutler-Hammer is releasing a new line of controllers that should prove to be some good competition for A-B and A-D. Only time will tell.

Chris
 
B
On May 20, 2007 3:03 pm, Chris wrote:
I think that Allen-Bradley and Automation Direct could learn a lot from each
other, but I don't think Allen-Bradley's products are better than anyone
else's. I use both platforms. Logix has features I wish DirectSoft had, and
DirectSoft has features I wish Logix had.

[rap] Maybe you could list some of those features. I have found the Logix
software can do just about anything, but often the capabilities are not well
documented, and sometimes not real obvious.

[chris] Aside from the features, there is no reason you should have to purchase
separate software to communicate with your controllers after having already
been raped on the price of programming software. Getting RSLinx to
communicate with a controller can be a real pain. It's a breeze with
DirectSoft. Rockwell gets away with it, which is exactly why they continue
to do it.

{rap] the version of rslinx used to communicate from logix to processors is
included with the package. there is no extra cost. I get frustrated with ab
software from time to time. Most of the frustration is the poor
documentation and the abysmal search capabilities of the knowledge base.
just about every problem can be easily fixed if you can find the right tech
note, but finding the right tech note is a whole lot harder than it needs to
be. but if it was easy, there would be far less reason to pay for tech
support.

[chris] You get a hell of a lot more for your money with Automation Direct
controllers and hardware than you do with Allen-Bradley. The only reason I
use Allen-Bradley is because they are the company's standard for use in the
equipment I work on. I used solely Automation Direct in my previous
department.

[rap] I am not sure that is true. A lot of people compare apples with
oranges when they do price comparisons between AB and AD. Having done it
several times, I can tell you the hardware cost is not as far off as you
seem to be stating. And if a company is already using AB, the costs to
switch (training, spares, etc.) is not something to be trifled with. On most
projects a 5 or 10% difference in PLC hardware costs is not a big deal.

[chris] You also get free Tech Support from Automation Direct. Allen-Bradley wants
you to pay a crapload for tech support, two craploads if you want nights and
weekends. I've been saying "to hell with A-B" for years. :) I think Cutler-Hammer is releasing a new line of controllers that should
prove to be some good competition for A-B and A-D. Only time will tell.

[rap] The eaton line of PLCs seems like a heck of a deal. when you do not
have to support old products, you can do a lot.
 
M

Michael Griffin

In reply to Chris: The people who program PLCs all day long, and the people who program them once in a while often want different things from their programming software. The same goes for people who work on a few very large programs versus many small ones, or for people who build machines versus people who have to maintain them. Pretty often, the sophisticated features that some people like in their large, complex programming packages are exactly the features which other people hate the most.
 
C
And there is the need factor. The only thing RSLogix does that I need, is to program AB PLCs. Is that need worth 10x the price? Invalid question
really, because there is no $350 way to program AB PLCs. In the end, since all of the programming tools are mutually exclusive, the question really is: Is using AB worth much higher cost in every category than using say, Koyo? Will the total bundle do the job better, faster, cheaper? In most cases, I would say no. From scratch, definitely not! Until you consider the lock-in factor. If you must interface with AB or you have a plant full of AB, there is no question and no choice. I think that is why many people use AB. Most of our equipment suppliers, including those with some very large, complex, and expensive systems use something else. Mostly Siemens or Mitsubishi. And our latest big system uses no packaged PLCs at all, they use powerful computers running Linux, RTLinux or an RTOS. Apparently they did not find the value in using AB, so it's probably not worth paying 10X more in many cases.

Regards

cww
 
D
OK, Curt I will bite:

Lets throw in 200 analog loops, 15 drive systems, some motion control robotics and a bunch of "structured text" interfacing to an upper level ERP system and some batch and oh some backward compatability, some weigh scales. Add company wide spare parts and training for all of the shift workers to work on all systems.

I will take the AB solution and its cost over Koyo or AD and its cluge to pull this all off.

TOTAL COST OF OWNERSHIP not initial cost, and I can find 1000 AB experts in 10 minutes but not 1000 Siemens or Koyo in the US within driving distance of me. I will compare company wide TOTAL COSTS any day for our paper mill of roughly 75 interfaced systems. Now if you are a little skid supplier, maybe a different story, but it is still up to who you are selling skids to.

If all you need is a knife have at it, if you need a screwdriver, corkscrew, earwax remover and a toothpick... give me a McGuyver knife.

Right tool for right situation and future expansion.

Have a great day:

Dave
 
Top