IEC61131-3 coding rules and guidelines series - Part1: Variable naming

-

Every programming language has its own coding rules and guidelines. Industrial Automation programming is no different. 
However, documentation covering Industrial automation programming coding rules and best practices is very few.

 The software in the industrial environments becomes more and more important, the software projects become larger, and the costs of errors increase. 


In order to deal with the complexity of larger programs, a modern approach to software development processes should be followed supporting a structured approach. 
Also, we need to increase the efficiency in coding via re-use of pre-defined functionalities and to help better understand the program over the life cycle.

 The aim of this series is to share the coding guidelines and rules that are based on IEC61131-3 standard and based on my 16 years of experience deploying automation solutions throughout different market sectors.

Part1: Naming rules for variables

1.1 Physical addresses to be avoided

Reference: 
  • IEC 61131-3 6.5.5 
  • IEC 61131-8 3.11.2


Programming Languages: 
  • Ladder diagram (LD)
  • Function block diagram (FBD)
  • Structured text (ST)
  • Sequential function Chart


Description

The usage of system dependent physical addresses shall be avoided. It is always preferred to use Variables.

Using physical addresses makes code less portable: every time the program should be deployed on a different manufacturer, or even a different instance on the same manufacturer it has to be edited. 

Furthermore, It makes programs less readable: Without a symbol table for reference, it will be difficult to know what each address is used for. Later system changes are also more error prone as some access to the physical addresses may be skipped or overlooked. 

Exceptions might arise for some communication protocols, where a physical addressing is needed to assign variables to a physical location to comply with the protocol mapping

1.2 Type prefixes for variables to be defined

Reference: 

  • IEC 61131-3 

 Programming Languages: 

  • Ladder diagram (LD)
  • Function block diagram (FBD)
  • Structured text (ST)
  • Sequential function Chart


 Description

 It is a good practice to define a scheme to be used to prefix a variable's name as a 
variable's name shall communicate other attributes that can improve readability and help reduce programming mistakes. 

 For example:

  • Knowing the size of the datatype or whether signed or unsigned can be important in the selection of instructions. 
  • Knowing a variable is Global can suggest external influence, or caution about undesirable side effects when writing. 
  • Writing to an "Input" signal by mistake will have no effect, and is not always shown as an error, for example if intermediate variables are mapped.

Also as programs get bigger complex, there is a tendency to group related variables (for example InfeedSpeed, InfeedAlarm, InfeedStatus). This grouping fails if groups are used inconsistently (for example Infeed_Speed, In_Feed_Alarm, ifStatus, inFault etc) so the common 'zone' names could be defined. This is especially true for large, multi-developer teams.

 Here is a list of some variable's name prefix that can be used according to IEC61131-3:
Type
Prefix
BOOL
x
SINT
si
INT
i
LINT
li
DINT
di
USINT
usi
UINT
ui
UDINT
udi
ULINT
uli
REAL
r
LREAL
lr
TIME
tim
LTIME
ltim
DATE
dt
LDATE
ldt
TIME_OF_DAY / TOD
tod
LTIME_OF_DAY / TOD
ltod
DATE_AND_TIME / DT
dt
LDATE_AND_TIME / DT
ldt
STRING
str
WSTRING
wstr
CHAR
c
WCHAR
wc
BYTE
by
WORD
w
DWORD
dw
LWORD
LW
ENUM
e
ARRAY
s
STRUCT
st
FUNCTION BLOCK
fb
PROGRAM
prg
CLASS
cls
GLOBAL SCOPE
g
LOCAL SCOPE
l
TEMPORARY VARIABLE
tmp
INPUT (Read only)
i
OUTPUT (Read/Write)
o

Attention should be made when defining the prefix scheme for variable's name. Adding too many prefixes can create complexity and long variable names. 
The most commonly used is a prefix for the data type.
The next part of IEC61131-3 coding rules and guidelines series will cover the balance naming rules for Variables, Tasks, Programs, Function blocks, Functions and User defined data type.

Comments

Post a Comment

Popular posts from this blog

Control system documentation

-
Image
One of the basic activity in any project is to ensure it is well documented.  Automation and control projects are no exception, though they have different and unique requirements to properly capture the requirements, outcomes, and deliverable of  the work being performed.  The International Society of Automation (ISA) has developed  standards that are broadly accepted and used across the industry as the preferred method for  documenting control systems. The purpose of this post is to highlight and present briefly the major instrumentation and control documentation required for successful project execution. The information presented in this post is according to relevant standards from ISA (International society of automation). Why do we document? Automation and control solutions become more complex and involve the inputs of and coordination with different disciplines such as process, Mechanical, Electrical,... Documentation is used to define the control system des
Read more

Introduction to sequential function chart (SFC)

-
Image
The Sequential Function Chart (SFC) is the basic design tool for sequential control applications.  The IEC 61131-3 SFC language is derived from the IEC 848 function chart  standard.  SFC describes graphically the sequential behavior of a  control program Elements of a sequential function chart The general form of the function chart is shown below. The function chart has  the following major parts: Steps of the sequential operation Transition conditions to move to the next step Actions of each step Initial step The initial step is indicated by the double-line rectangle. The initial step is the initial state of the program when the controller is first powered up or when the operator resets the operation. Steps The steps of the operation are shown as an ordered set of labeled steps (rectangles) on the left side of the diagram. Unless shown by an arrow, the progression of the steps proceeds from top to bottom. Transition conditions The tr
Read more

Introduction to structure text (ST)

-
Image
The Structured Text (ST) language defined by IEC 61131-3 is a high-level language whose syntax is similar to Pascal. In general, ST is useful for implementing calculation intensive  functions and other functions that are difficult to implement in the other  languages. The ST language has a complete set of constructs to handle variable  assignment, conditional statements, iteration, and function block calling. Expressions An expression is a construct which, when evaluated, yields a value corresponding to one of the data types. Expressions are composed of operators and operands. An operand shall be a, a variable, a function invocation, or another expression. The operators of the ST language are summarized in below table.  The evaluation of an expression consists of applying the operators to the operands in a sequence defined by the operator precedence shown in below table.  The operator with highest precedence in an expression shall be applied first, followed by the
Read more