Jeremy Pollard, CET, has been writing about technology and software issues for many years. Pollard has been involved in control system programming and training for more than 25 years.
I've been asking around about the state of the programming software union. I believe it's a boring arena now, with little innovation. What's valuable? What's missing? In general, "Hey, what do you think?"
Colm Gavin, engineering software product manager for Siemens Industry, believes the platform makes the difference. And, it had better be flexible enough to interface with cultural differences.
SEE ALSO: Programming With Old and New
Major influences consisted of mass operation functions (macros) in the instruction set, like function blocks in IEC-61131, mouse functions for one part of the world, and keyboard contexts for the other side of the world.
What's missing is a common HMI and PLC interface suite. This dovetailed with Jeff Payne, product manager for AutomationDirect, whose opinion is that a system-wide, common database is paramount in this mature market. Payne's view of a networked environment mirrors Gavin's in that devices across the system should be common and presented with commonality, regardless of what or where they are.
Andrew Stump, design software manager for Rockwell Automation, alluded that the "missing pieces" might be user-driven. Along with Payne, Stump believes that hardware is hardware, and the software needs to embrace all users with functionality and skill levels. Not to say that hardware is all the same, but I think the point could be that your user might not be as proficient in some areas as he or she might be in another area.
A common theme with all three contributors is the need for software to be hardware-aware. Payne likes the idea of auto discovery, and I can't disagree. "Tell me what's there" can be helpful for the maintenance guy. Oh, there's another component that isn't there.
Gavin endorses the system-hierarchy-type display that can educate the user quickly.
[pullquote]
Stump's view of the hardware support is to place hardware-specific instructions and displays in the software for the programmer and designer, as well as the maintenance person. I can attest to the value, since we didn't ever have that in the Stone Age of early software.
Gavin identified a user absolute in software navigation. Payne and Stump agree. I suspect this comes from the marketing guys: the hardware must be supported in the best way possible. One might not care that a descriptor is only 10 characters, but not having hardware support "to the nines" isn't acceptable.
Payne touched on device structures, which are part of IEC-61131 data typing. Similar to structured languages, it can provide a compact view into a device.
Stump was also quick to suggest that commercial, third-party devices have to be incorporated into the design process.
So, it seems the main use for a vendor's programming software is to support its hardware. Novel idea for sure, and instruction sets will reflect that. The main issue for users that I got from all three was the view of the canvas. How does the picture look and, if you want to get somewhere, it better be easy.
I also asked Bill Lydon, managing director of PLCopen North America, a position I held until a few years ago. Lydon indicated that PLCopen recently extended the function block platform of motion control to fluid power, with definite-purpose functions to perform a specific task. I would imagine that Bosch Rexroth and others would be providing this with their hardware.
Also, a common platform point is the XML interchange between modeling and programming environments. Coupled with the common platform theme, Lydon expects more of the HMI and programming in the same room. PLCopen has been engaged with the OPC Foundation to provide exactly that.
While it's a pure plug for IEC-61131, he argues that software needs to provide productivity advantages. The suggestion is that programming and HMI software need to have a common database, ability to have application-specific instructions, which Stump also supports, along with a data-typing scheme with structures, etc.
And, this is where all things collapse. Lydon suggests that a standardized programming convention is needed to support future generations. While it might have merit, most would agree that it will never happen.
All of the contributors I spoke to believe that since their software is mainly there to support their hardware, and that each have their own marketing and design philosophies, PLCopen's standardized platform might only exist in parts.
