Automation Notes || 

Adisetiadi

Stick with your architecture and remember to reuse your code

Daniel Fenton

01/15/2014

Every PLC programmer will make a mistake when he or she is writing code. Whether it’s the result of pressure by the customer, lack of coffee in the morning, or simply getting distracted at the wrong time, here are the top five mistakes to avoid.

1. Not sticking to an organized architecture

When a program is first laid out, all of the code for each portion should fall into neat, orderly sections. Keeping each part of the code separate allows the person working with the program to easily visualize the overall execution of the program.

It also helps to debug the program if something goes wrong, since each piece of code is encapsulated into its own structure. Finally, it looks better, because there isn’t the mess of an entire program on the screen at one time.

Unfortunately, as the developer and post-deployment maintainers work on the code, sometimes the code begins to creep out of each section, and intertwine with the supposedly isolated functions around it. This leads to confusion as tags hop from one sheet to the next, or outputs are written twice during execution.

It also leads to disorganized code. Finally, this can be dangerous, as minor tweaks across the board cause little program issues to build up until something breaks. Maintaining code organization and encapsulation is critical to the longevity of a PLC program.

2. Not documenting the code

Documenting code as it is written and, further, as it is maintained is critical to keeping a PLC and its program operational during the long periods of time between updates and adjustments. A quick few sentences on each major portion can save a lot of time and headaches later on. It can also help the programmer put his or her thoughts on paper, which can be helpful in figuring out the next step.

Even though the code may make sense at the moment it is programmed, the five minutes spent explaining thoroughly why a particular technique was used can save hours when, months later, a user must decipher what is going on. All too often, code originally installed in a system will change due to fixes, updates, and feature additions. If the documentation is not updated with the code, this can lead to confusion and misinterpreted programming.

3. Creating redundant tags and variables

As logic statements and ladder rungs are written out, often a program can have multiple branches of logic that eventually lead to a tag that functions as a sort of “flag.” This flag will usually wind up activating other pieces of logic in the program. Sometimes, these pieces of logic are mutually exclusive, such as a Boolean variable, which requires the program to send a message to one remote station or another, depending on the status of certain inputs.

The IEC 61131 Structured Text statements IF and ELSE are purpose-built for this exact logic, so that only one tag needs to be tested. If the tag is true, one set of code is executed. If the tag is false, another set of logic is executed.

If a programmer is not paying attention, he or she can be put in the situation of creating a “flag_1” and a “flag_2,” with both of these tags performing the same duty. Now, both variables need to be tested, which leads to increased code complexity and greater memory utilization. Not only are both of these results poor programming practice, but repetitive use of redundant tags and variables will require that a program utilize a more powerful (and therefore expensive) processor than otherwise required.

4. Not reusing existing code

Aside from ease of maintenance, debugging, and readability, the reason it is so important to encapsulate and isolate code in a program is that code encapsulated inside of a function block can be reused over and over throughout the program. This removes the requirement to rewrite the code that already exists inside of a function block. Therefore, the programmer can generate a standard, all-use function block that can be debugged and modified once, and have that change reflected throughout the entire program.

Collections of these general use function blocks are called function block libraries, and many manufacturers offer application or industry-specific function block libraries for download on their websites. These function block libraries heavily cut down on the amount of development time required for a given application or project.

Sometimes, without realizing it, a programmer will find him- or herself writing code that’s already been written. Where five or six of the same pieces of equipment need to operate similarly, it is easy to create a function block that accepts the inputs of the sensors and outputs solutions for the actuators. On the other hand, it can be more difficult on seemingly one-off algorithms to find a reason to write generic code.

The effort needed to write a function block that is generic enough to be reused must be balanced against the time spent for development on the project. It is worthwhile, however, to bear in mind that a little extra time spent immediately can save a lot of time later on.

5. Not utilizing version control

Keeping your code organized is another major practice that is sometimes lost in the commotion of trying to complete a project for commissioning. Version control systems can be as simple as naming a project for a particular PLC once it has been deployed, or as powerful as a dedicated application used specifically to track what the changes are in each major revision.

The use of such versioning schemes mitigates situations where a particular fix or feature might have gone out to the field, and the PLC has a program that may or may not have those changes.

Programmers often forget to keep track of what changes are in the program on the PLC without a proper versioning strategy. Documentation, a good naming scheme, and possibly dedicated version control software can lessen these issues and increase the detail available to the programmer.

Dedicated version control software also allows a system to track the user that made every single change, documented or otherwise. This can be particularly useful if multiple programmers are working on the same program.

http://www.controleng.com/

IEC 61131-3: What’s the acceptance rate of this control programming standard? Ladder diagram remains the simplest and most popular approach for PLC programming, but may not be the most efficient way. Lack of interoperability may be a problem. To learn what languages PLC programmers prefer and to understand the level of awareness and use of the IEC 61131-3 standard for industrial control, Control Engineering surveyed readers as part of a custom research project on behalf of AutomationDirect.

Jeff Payne

12/23/2015

Although the IEC 61131-3 Programming Languages standard has been around for nearly 25 years, limited awareness of its scope and features has kept it from becoming a requirement in North America. A recent survey of Control Engineering readers showed that ladder logic remains the most popular programming method for programmable logic controllers (PLCs). Findings of the custom research project, on behalf of AutomationDirect, suggest that programmers could save time and money by using other standard programming languages more often. It also suggests that difficulty in code transportability among PLC brands may be an issue.

Overview: limited adoption

More than 586 responses were received from participants who met eligibility requirements, including relevant purchasing influence and authority, and also responsibility for hardware specifying or PLC programming. The results of the survey show low awareness and limited adoption of this standard in North America, indicating that situations where its application is required are rare.

The most common job functions of the respondents were system or product design; control or instrument engineering; or system integration or consulting. These functions accounted for more than 60% of the respondents. About one-third of the functions included process, production, or manufacturing engineering; operation or maintenance; or other engineering. Almost 10% of the participants were in general or corporate management, and this group was more likely to specify but not program PLCs.

The majority of the respondents, more than 60%, were employed at companies with more than 100 employees, some with 1,000 or more. However, the largest group of participants, at almost 40%, was from companies with fewer than 100 employees.

By company type, end users of PLCs were the largest group of respondents at almost 40%, and almost half of the respondents were system integrators, original equipment manufacturers (OEMs), or machine builders. The respondents were widely spread geographically throughout the United States.

What the experts say

The IEC 61131-3 standard has been around for nearly 25 years and includes a family of programming languages. IEC characterizes it as an international standard for programming PLCs. PLCopen, a nonprofit industrial trade organization, is mostly dedicated to IEC 61131-3 and contains significant information about the standard.

The PLCopen Website describes IEC 61131-3 as, "The only global standard for industrial control programming. It harmonizes the way people design and operate industrial controls by standardizing the programming interface." The organization says it is a standard programming interface with a common structure.

The standard includes a definition of the sequential function chart (SFC) language, used to structure the internal organization of a program. It adds four inter-related programming languages including two graphical ones, ladder diagram (LD) and function block diagram (FBD); and two text-based languages, instruction list (IL) and structured text (ST). Using logical elements, defined data types, task structure and scheduling, and execution control, each program can theoretically be structured to increase re-usability, reduce errors, and increase programming and user efficiency.

PLCopen has been working with technical committees to add extensions to the standard. There have been a number of functions added as a result of these activities including motion control, safety, OPC Unified Architecture communication (OPC UA from OPC Foundation), XML schema, reusability level definitions, and conformity level.

Awareness levels

So how familiar are PLC purchasers and programmers with IEC 61131-3? When Control Engineering polled its readers, a whopping 85% of the respondents said they are either not familiar with or only somewhat familiar with it (see Figure 1). While this standard may have great acceptance and use in Europe or other parts of the world, it has not had as much impact in North America. Implementing it does not appear to be a priority or a requirement for many respondents in the United States since, after more than 20 years, an overwhelming majority of programmers working in North America are, at best, only somewhat familiar with the standard.

More than 40% of the respondents reported no familiarity with the standard, and the highest concentration of these respondents was among those who say they are PLC programmers. Turning it around, among those who say they actually write programs, only 15% claim a high level of familiarity.

Why use PLCs supporting IEC 61131-3 programming?

Among the respondents who use or specify PLCs, and who say they are familiar with IEC 61131-3, the next question asked in the survey was why they use it. The answers (see Figure 2) suggest its use does not appear to be a requirement for most in North American industrial automation markets. The reason cited most often (39%) is simply because the PLC product came with the language. A quarter of the end users specified IEC 61131-3 programming language, and some of this can be attributed to U.S. companies shipping machines into Europe or Asia.

The fact that fewer than 10% of the applications demand the features of IEC 61131-3, while a larger percentage of respondents who don't program PLCs say it's because it's specified, hints that some of the totals are driven by hardware choice and selection.

http://www.controleng.com/

|| What Is A Servo?

Servo control, which is also referred to as "motion control" or "robotics" is used in industrial processes to move a specific load in a controlled fashion. These systems can use either pneumatic, hydraulic, or electromechanical actuation technology. The choice of the actuator type (i.e. the device that provides the energy to move the load) is based on power, speed, precision, and cost requirements. Electromechanical systems are typically used in high precision, low to medium power, and high-speed applications. These systems are flexible, efficient, and cost-effective. Motors are the actuators used in electromechanical systems. Through the interaction of electromagnetic fields, they generate power. These motors provide either rotary or linear motion. Here is a graphical representation of a typical servo system:

This type of system is a feedback system, which is used to control position, velocity, and/or acceleration. The controller contains the algorithms to close the desired loop (typically position or velocity) and also handle machine interfacing with inputs/outputs, terminals, etc. The drive or amplifier closes the inner loop(s) (typically velocity or current) and represents the electrical power converter that drives the motor according to the controller reference signals. The motor can be of the brushed or brushless type, rotary or linear. The motor is the actual electromagnetic actuator, which generates the forces required to move the load. Feedback elements such as tachometers, lvdts, encoders and resolvers, are mounted on the motor and/or load in order to close the various servo loops.

ADVANCED Motion Controls designs and manufacturers servo drives and amplifiers for use in servo systems. Servo drives and amplifiers are used extensively in motion control systems where precise control of position and/or velocity is required. The drive/amplifier simply translates the low-energy reference signals from the controller into high-energy signals to provide motor voltage and current. In some cases the use of a digital drive replaces the controller/drive or controller/amplifier control system. The command signals represent either a motor torque, velocity or position and can be either analog or digital in nature. Analog +/-10 VDC command is still the most common reference signal but it is quickly giving way to digital network commands.

ADVANCED MOTION CONTROL http://www.a-m-c.com/