Control Considerations in Mechatronics

From Project Mechatronics

Opto 22’s PAC Project software suite is an example of PAC software. Integrated with SNAP PAC controllers, the suite includes control programming and HMI development software, plus optional OPC server and database connectivity software. I/O points and variables are stored in a single tagname database. Flowchart-based PAC Control development software from Opto 22 is fully integrated with SNAP PAC programmable automation controllers.

PAC hardware can be used in multiple domains, including logic, motion, drives, and process control. And the software programs all control and monitoring tasks of multiple domains. This feature enables the programs to “flow” as the requirements of the application dictate.

This PAC from Opto 22 includes two independent Ethernet network interfaces plus four serial ports configurable for RS-232 or RS-485/422.

Critical to any mechatronics system is the control. One of the newest controllers is the programmable automation controller. Here are tips on selecting one for your specific application.

By Kelly Downey,
Electrical Engineer
Opto 22

Industrial applications continue to increase in complexity, requiring controls that can integrate multiple systems that incorporate discrete, motion control, and process tasks and that can gather, process, and transmit real time data to company databases. Programmable automation controllers (PACs) can be one choice for managing this complexity because they combine the capabilities of several traditional control and monitoring systems. Typically, they have features found in programmable logic controllers (PLCs), distributed control systems (DCSs),remote terminal units (RTUs), and personal computers (PCs).

Even so, control manufacturers offer PACs with varying capabilities. Thus, there are several considerations to keep in mind with your selection.

— For a new installation, most PACs feature monitoring, control, and data acquisition capabilities plus Ethernet connections. They should also include full analog and digital control, motion control, the ability to interface with serial devices, and remote monitoring. You may not have an immediate need for these features, but needs have a way of expanding.

— Look for PACs with features that can reduce network hardware expenditures, such as extra built-in network interfaces.

— For an existing installation, a PAC can consolidate separate systems and link them with company computers to exchange control, production, and monitoring data as needed. It is important to verify that new PACs are compatible with all legacy systems, including all networks and protocols.

— Choose the PAC to suit the size of your system. For example, a PAC that mounts on the I/O rack may be more suited to cell control and RTU-type installations. Extensive systems may need more powerful, standalone PACs.

— For efficiency, choose a PAC-based system that uses distributed intelligence, not just a distributed architecture. Distributed intelligence offloads many control functions to remote processors co-located with distributed I/O. Distributed intelligence shortens wiring runs, reduces network traffic, maintains critical control should communications fail, and frees the central controller for supervisory tasks.

— Choose a PAC that has all the networking and communication options you need—and anticipate needing—built in. Networks may include Ethernet (either wired or wireless), and serial. Other communication options include OPC, Modbus® or Modbus/TCP, Profibus®, Allen-Bradley DF1, and other control standards. For communication with computer networks, you may also need protocols such as TCP/IP, SMTP for email, SNMP for network management, and FTP for file transfer.

— PACs tend to be hardened for industrial environments. However, if your application involves extreme temperatures, vibration, dampness, dust, electrical noise, or other exceptional conditions, provide necessary enclosures and protection just as you would for a traditional control system.

— Signal requirements for inputs and outputs vary widely, including temperature, rate, RMS, pH/ORP, load cell, in addition to voltage and current. The PAC should communicate with all signal types natively rather than requiring signal conditioners. Where cabinet space is limited, high-density I/O is a good choice. Software-configurable I/O—for example, an input module configurable as any of several thermocouple types—offers flexibility and reduces the number of spares you need to have on hand.

— Many PAC-based systems have advanced control capabilities built in. They can satisfy requirements for high-speed digital control, motion control, PID loop control, and mathematically complex logic, without expensive add-ons.

— Because a PAC is similar to a PC, its integrated software includes such programming features as subroutines, string handling, complex conditions, and floating-point math. In addition, a PAC can often be programmed in C or other standard programming languages. While it may seem easier to program with tools you are familiar with (such as ladder logic), you may find that software designed for a PAC is more efficient for expanding needs. Plus, it will likely save development time and effort.

— For data acquisition applications, a PAC should have substantial memory for acquiring and storing data; and the ability to share data directly with corporate databases over an Ethernet network. If control networks and computer networks need to be separated, consider how you’ll accomplish this. One way is to segment networks using independent Ethernet network interfaces on the PAC itself.

— Check out the human-machine interface (HMI) options. Often, the software will use a single tagname database. Once you define variables and I/O in the control software, you can immediately use them in the HMI software. A PAC should also communicate with third-party HMIs using OPC. Other options, such as a touch screen terminal, may be available as well.

— Finally, plan for the future. When your needs change, additional distributed I/O should be handled by the same PAC—as should process, discrete, and motion control.

All of these types of control should be programmable in the same software as part of the same system, and most changes should require no middleware or add-ons.

Opto 22
http://www.opto22.com

This table compares features of a PAC with common features of PCs, PLCs, DCSs, and RTUs to help you choose all the features you anticipate needing, both now and in the future. [edit] A closer look at software for PACs According to the ARC Advisory Group, generally credited with coining the term PAC, among a PAC’s defining characteristics are three elements directly related to software: • Tightly integrated controller hardware and software. The software used with a programmable automation controller is designed specifically for the PAC. • A single development platform, using common tagging and a single database for development tasks across a range of disciplines. • Programmability using software tools capable of designing control programs to support a process that “flows” across several machines or units. Let’s take a closer look at these characteristics. Tightly integrated hardware and software When hardware and software are designed together, not only does it often lower software costs, systems are usually easy and fast to build. The integration eliminates the need for drivers, which eliminates the task of debugging. If problems occur, you have just one company to call for product support or one website to visit for information. Documentation is often more complete, as well. A single development platform The software built for a PAC is not just integrated with the hardware it runs on. It is also internally integrated: it provides an integrated development environment (IDE) for programming as well as a suite of related programs for HMI development and other purposes. The IDE is a single software program that handles everything related to control programming, such as editing, compiling, and debugging. Plus, a software suite made of two or more applications offers a similar look and feel in all of them. More importantly, the software applications in the suite work together behind the scenes in ways that significantly reduce development time. Common tagging means that names and definitions you set up in one of the suite’s applications are also used in the others. For example, if you define a string variable in the control development software, that same definition will be used in the human-machine interface (HMI) development software. If you name a digital I/O point in the control software, that name will automatically appear when you’re configuring OPC data communications. Because all these common tags are kept in a single database used by all the applications in the software suite, you don’t have to reenter tags or maintain and reconcile lists. Development tasks can be finished more quickly and easily. Supporting a process that flows The same hardware can be used in multiple domains, including logic, motion, drives, and process control. Thus, it follows that the software must be capable of programming all control and monitoring tasks of multiple domains. The software must let the developer mix and incorporate tasks as needed into control programs, so these programs can “flow” as the requirements of the application dictate. The number of PACs needed will depend on application requirements, however, each PAC can be used in any domain or in multiple domains. Because the application requires processes that flow into each other over space and time, the PAC software accommodates that flow and integrates these multiple domains into one system.