Massey contends that automation software should be thought of as more than simply a prescribed process for automating a specific task; it should be a means of creating an array of software tools for the automating of a wide variety of tasks.
It is that approach, he says, that lies behind B&R’s Automation Studio, an integrated set of development tools designed to allow engineers and programmers to create applications in a standardized environment and then port them to the control platform of choice.
“This single software package is used to program and communicate with all of B&R’s products,” says Massey. “It uses libraries and function blocks as well as IEC 61131-3 languages plus ANSI C to make programming flexible and reusable,” he notes, in reference to the International Electrotechnical Commission’s 61131-3 standard, and the C programming language published by the American National Standards Institute. “It also provides Unicode support, remote diagnostics, connection with enterprise resource planning (ERP) systems and version control,” Massey continues.
It is an approach that holds out the promise of faster development times, as well as a variety of cost savings throughout the lifecycle of a project, and it’s one that B&R is not alone in deploying. “It’s an approach that’s become somewhat common among automation vendors,” notes Ron Bliss, Logix software marketing manager for vendor Rockwell Automation Inc., Milwaukee.
Abstract and inherit
“We have a range of control platforms in our Logix family,” he continues, “but our development environment is designed to look the same to the user regardless of what application they are trying to control. The same programming tools and the same instruction set is used.” Abstraction, a concept imported from personal computer (PC) programming, comes into play here. It’s the process of simplifying programming by masking some details in order to allow the user to concentrate on others.
“We provide users with a tool that they need to organize their control execution while not tying that development to the limitations of a particular hardware platform,” says Bliss. “They are abstracted from the hardware in the sense that the limitations of the hardware don’t manifest themselves in the programming environment. Then, once they’ve developed their application, the system compiles and builds source code appropriate to the targeted control platform.” Not only does this help reduce initial development time, but it also facilitates the reuse of programs despite changes in the scale of the target application or the hardware used.
The studio approach has been aided by another concept borrowed from the PC world: inheritance, or the ability to create new objects by using existing, previously validated objects. This allows the creation of standardized libraries whose components can be modified via add-on instructions. Along with reducing development time and ensuring consistency, this impacts an organization in other ways as well.
“Say, for example, you’re an end-user and you hand your code off to one of your systems integrators, who then discovers a problem with some aspect of it,” explains Bliss. “The necessary changes can be made, and then through a simple import operation, you can replace the existing code and inherit the changes throughout the system without having to go in and manually edit each instance where that particular problem occurred.”
Language flexibility
Standardized programming languages, such as those contained in IEC 61131-3, are central to the studio approach, as Mark DeCramer, product manager for automation vendor Wago Corp., Germantown, Wis., makes clear. Referencing his company’s CoDeSys integrated programming environment, he notes that its use of IEC 61131-3 allows users to develop their applications or routines in whichever of the standard’s four languages is most efficient for the purpose at hand.
“Languages such as Ladder Diagram and Sequential Function Chart are prevalent in our industry,” he observes, “but it can be cumbersome to write sorting, file-access and numerous other routines using these languages. These routines can be written as function blocks and stored in libraries, where they can be easily re-used and shared among users, reducing software development time.”
DeCramer goes on to note other advantages of this multi-language capability. “The Structured Text Programming language permits constructs such as IF-THEN-ELSE, DO WHILE, FOR-NEXT and CASE statements, which allows writing well-formatted software. The same software can be written in ladder logic, but the resulting code will be rife with JUMP statements and disjointed logic, making it difficult to read, re-use and especially troubleshoot. Logic written in Structured Text is also easily commented, resulting in more readable software.”
“Easy to troubleshoot” brings up another selling point of the integrated, studio approach: easier maintenance. For starters, the fact that a single software program is employed, as opposed to separate packages for motion, human-machine interface (HMI), logic and the like, simplifies maintenance while reducing costs. Built-in diagnostic systems such as those offered by S7-PDIAG, a component of the Simatic Step 7 programming and configuration environment from vendor Siemens Energy & Automation Inc., Alpharetta, Ga., helps users configure process diagnostics during application development, provides monitoring capability and fault detection, then reports those faults, such as a limit switch failure or a motor overload, to the HMI.
Similarly, the PAC Project Software Suite from Temecula, Calif., automation vendor Opto 22, a flowchart-based system used with its Snap programmable automation controllers (PACs), offers an array of integrated functions designed to speed maintenance, including the ability to test an analog or digital point by writing directly to it, and remote monitoring.
Collateral benefits
The time savings achieved with today’s integrated programming environments affect not only the speed of design, but, potentially, the process itself. “Today, we are seeing a lot of machine builders who are being crunched with smaller and smaller machine design teams facing shorter development times, and they are taking advantage of function blocks to meet those challenges,” says Nipun Mathur.
Mathur is product manager for motion control and mechatronics for vendor National Instruments (NI), Austin, Texas, and he is speaking specifically about the function block facility in LabView, NI’s integrated programming environment. “These, coupled with the rest of the LabView functionality, allow users to develop their applications for one type of hardware platform, scale it to another type of platform, and generally make changes quickly.
“One of the big advantages of this environment,” Mathur continues, “is that it facilitates more integrated development, so your control engineer, your electronic engineer, your control design programmers—everybody who needs to be involved in application development—will be more synchronized and on board earlier. Today, what happens is that if you have a year to develop a machine, the mechanical engineer will take about eight months, and then the control engineer comes in and is supposed to make that machine work at all costs within the time left. He is thus limited to off-the-shelf solutions. With a more integrated, mechatronic approach, that control engineer has more time to customize solutions best suited to that application.”
Mathur cites OptiMedica Corp., Santa Clara, Calif., and the control system of its PASCAL (pattern scan laser) photocoagulator as an example of the sort of innovative design fostered by an integrated development environment.
Taking the hurt out
Laser photocoagulation involves the controlled destruction of a patient’s peripheral retina using targeted laser pulses. It is a frequently used and highly effective way of treating retinal diseases caused by diabetes, but there’s a downside. “It can be very tedious to both patients and doctors,” explains OptiMedica co-founder and Principal Engineer Michael Wiltberger. “Ophthalmologists can deliver only one burn at a time, and treatment can require as many as 2,000 burns. A full course of treatment typically requires two to four sessions, each lasting 12 to 15 minutes.”
And it hurts. It feels like “getting a soldering iron right in your eyeball,” says Wiltberger. No wonder many patients are loathe to come back, even though the treatment may be the best hope for preserving their vision.
OptiMedica set itself the challenge of developing a more accurate, more automated, less painful photocoagulator to be a fully integrated pattern scanning laser system that provides significantly improved performance for the physician administering the treatment, as well as an enhanced therapeutic experience for the patient. The company used LabView’s integrated programming environment to do it.
“With a single graphical development platform, we were able to design and prototype the machine efficiently,” Wiltberger notes. With conventional methods of retinal laser photocoagulation, the physician uses a mechanical joystick and foot pedal to deliver single 100-millisecond laser pulses to abnormal blood vessels of the peripheral retina.
“We discovered that automatically delivering multiple, shorter pulses rather than a series of manually placed lesions allows for greater precision and safety. By programming in LabView, we were able to vary the timing and power of each pulse to optimize for speed and precision while still protecting the fovea by creating patterns with integrated foveal exclusion zones.” And, by reducing the laser pulse time from 100 milliseconds to just 10 milliseconds, and then automating multiple spots with each depression of the foot pedal, the new PASCAL system significantly reduces the overall procedure time, as well as the amount of discomfort felt by the patient. No more soldering irons
Check out an Automation World Webcast on programmable automation controllers at
www.automationworld.com/view-3210
