GB/T 15969.3-1995 Programmable controllers Part 3: Programming languages
Some standard content:
ICs35.160
National Standard of the People's Republic of China
GB/T15969.115969.4—1995
Programmable controllers
Programmable controllers
1995-12-29 Issued
National Technical Supervision Bureau
Implementation on 1996-10-01
National Standard of the People's Republic of China
Programmable controllers
Part 3: Programming languages
Programmalie controllers
Part 3: Programming languages 1 Subject content and applicable scope
1.1 Subject content
This standard specifies the syntax and semantics of the programming language for programmable controllers (PCs). GB/T15969-3—1995
The FC programming languages specified in this standard include textual languages (instruction list (IL) language and structured text (ST) language), graphic languages (ladder diagram (LD) language and function block diagram (FBD) language). This standard also describes the features that facilitate communication between programmable controllers and other components of the automation system. 1-2 Scope of application
This standard applies to the print representation and display representation of the programming language used by programmable controllers, and the characters used for representation are GB19 character set characters. The language elements defined in this standard are allowed to be represented by graphics and semi-graphics, but such representation is not defined in this standard. The programming language elements defined in this standard can be used in an interactive programming environment, and the detailed description of this environment is beyond the scope of this standard: however, this environment should be able to generate text or graphic program files in the format specified in this standard. Functions such as program input, testing, monitoring, and operating system are specified in GB/T15969.1. 1.2.7 Software model
Figure 1.2.1 shows the basic high-level software elements and their relationships. These elements are programs, function blocks, configurations, resources, tasks, global variables and access paths. The first two elements can be programmed using the language defined in this standard, and the remaining elements can be configured as specified in clause 2,? of this standard. The software element configuration corresponds to the PC system and virtual machine device (VMD) defined in GB/T 15969.1. The software element resource corresponds to the "signal processing function" and its "human-machine interface" function and "sensor and actuator interface" function defined in GB/T 15969.1. Each configuration contains one or more resources, and each resource contains one or more tasks and programs. A program can contain zero or more function blocks or other software elements defined in this standard. Configurations, resources and any operations can be started and stopped by the "operator interface" function, the "programming, test and monitoring" function, or the "operating system" function defined in GB/T 15969.1. Therefore, these elements are program-enabled (PR-GRAMINVOCATIONS) as defined in GB/T 15969.1. Starting or stopping a configuration or resource is equivalent to starting or stopping all services contained in the element. Programs, tasks, resources, global variables, access paths (and their corresponding access priorities) and configurations can be loaded or deleted through the "communication functions" defined in GB/T 15969.1; therefore, these elements belong to the scope of this standard (LXOMAINS). The loading or deletion of configurations or resources should be equivalent to the loading or deletion of all the elements it contains. Approved by the State Administration of Technical Supervision on December 29, 1995 78
Implementation on October 1, 1996
1.2.2 Communication model
Execution control path
Function block
GB/T15969. 3—1995
Complete variable
Input and output path
, variable input and output path
[--] variable
Figure 1.2.1 Software model
Figure 1. 2. 2 shows various methods of communicating variable values between software elements. Task
As shown in Figure 1.2.2 (a), variables in a program can communicate directly by connecting the output of one program element to the input of another program element. This connection is intuitive when expressed in graphical language, but implicit when expressed in text. Communication between variables of two programs in the same configuration can be achieved through a global variable, such as the variable "X" illustrated in Figure 1.2.2 (b). This variable is called global in the configuration, and external in the program as defined in Clause 2.4.2. As shown in Figure 1.2.2 (c), variables can be communicated between two separate parts of a program, or between two programs in the same configuration or different configurations, using the communication function blocks defined in Clause 2.5.2.3.5. 1.2. 3 Programming model
PC programming language elements The subclauses that appear in this standard are classified as follows: Data type (2.3)
Program organization unit (2.5)
Function (2.5.1)
Function block (2.5.2)
Program (2.5.3)
Sequential function chart (SFC) Metadata (2.6)
Configuration element (2.7)
Global variable (2.7.1)
Resource (2.7.2)
Service (2.7.3)
Program A
VAR - FXTERNA1.
END-VAR
Program A
(a) Strongly ordered
<h) Program/configuration
GB/T 15969.3—1995
Program A
Configuration C
YAR-GLOBAL
X,BOQL
FND=VAR
Program B
*Gate HI*
Figure 1.2.2 Communication model
Inter-process/program: Inter-configuration/configuration Note: The detailed diagram of the sending and receiving blocks is given in this document, see 2.5.2.3.5, O
VAR-EXTERNAI.
END-VAR
GB/T 15969. 3—1995
a. Derived data types shall be described as specified in Clause 2.3.3 using the standard data types specified in Clauses 2.3.1 and 2.3.2 and previously derived data types.
b. Derived functions shall be described as specified in Clause 2.5.1.2 using standard and derived data types, standard functions defined in Clause 2.5.1.4, and previously derived functions. The description shall use the format defined for the IL, ST, LD, or FBD language. Derived function blocks may be described as specified in Clause 2.5.2.2 using standard or derived data types and functions, standard function blocks defined in Clause 2.5.2.3, and any previously derived function blocks. The description shall use the format defined for the IL, ST, LD, or FBD language and may include Sequential Function Chart (SFC) elements as defined in Clause 2.6. d. Programs shall be described as specified in Clause 2.5.3 using standard or derived data types, functions, and function blocks. The description shall use the format defined for the IL, ST, LD, or FBD language and may include Sequential Function Chart (SFC) elements defined in clause 2.6, and may combine programs into configurations using elements such as global variables, resources, tasks, and access paths defined in clause 2.7. e.
Regarding the "previously derived" data types, functions, and function blocks in the above rules, it means that once such derived elements are described, their definitions are available. For example, it can be placed in a "library" of derived elements and used in further derivations. Programming languages not defined in this standard can also be used to describe functions or function blocks. The execution of such a derived function or function block, as well as the acquisition of data related to it, can be completed by a user program written in a language defined in this standard, but the method used should be defined in this standard.
Language elements
Data format
· Standard (2.3.1.2.3.2)
, later
· Standard 2.5.1.4
· Derived
Function block
Standard 2.5.]. 3
·Derived
SFC elements (2.6)
Description (2.5.1.2)
IL..ST,LD
FDOthers
Description (2.5.2.2)
IL.ST.LDX
FELDOthers
Description (2.5.3)
Description<2.7)
·Global variables
·Egg source
·In-service
Entry path
Exported elements
Derived
According to the form
Generated functions
Newly generated functional blocks
Note: The numbers (1) to (5) enclosed in brackets in the figure correspond to paragraphs a, lh.cd in the justice respectively. Figure 1.2.3 Combination of PC language elements LID—Ladder diagram (4.2) FBI Function block diagram (4.3): IL—Instruction list (3.2) ST—Structured text (3.3) UTHERS—Other programming languages (1.2.3)
1.3 Conformance
This clause defines the requirements for PC systems, the procedures of which shall be conformant to this part of the standard. 8
1.3.1 PC systems
GB/T 15969.3—1995
As defined in GB/T 15969.1, a PC system that is said to fully comply with the requirements of this part of the standard shall only do as described below.
A conforming language shall be included in the system documentation or generated by the system itself. The format of the conforming statement should be as follows: "The system complies with the requirements of GB/T 15969.3 for the following language properties." Then a conforming table with the following format should be established: (Table title)
Sub-items
Characteristics and descriptions shall be obtained from the table given in the relevant sub-clauses of this part. The table title shall be obtained from the following list: Public elements
Common text elements
11. Comment elements
ST language elements
Common graphic elements
LD language elements
FBD language elements
Characteristics in Clause 2
Characteristics in Clause 3.1
Characteristics in Clauses 3.2. 1 ~ 3. 2. 3
Characteristics in Clauses 3.3.1 ~ 3.3.2.4
Clause 4. 1 ~ 4. 1. 6 Characteristics in clauses 4.2 through 4.2.6 Characteristics in clauses 4.3 through 4.3.3 Characteristics in clauses 4.3 through 4.3.3 For the language defined in this part, a PC system that complies with the requirements of this part shall:. Not be required to include replacement or additional language elements in order to accomplish any of the characteristics specified in this part. Include documentation that defines all execution-related parameters. As listed in Appendix D to this part. b. Be able to determine whether a program organization unit used violates any requirement of this part. If such a violation is not designated as an error in Appendix E, notify the user of this determination. In the event that the system does not examine the entire program organization unit, the user shall be notified that the determination of a violation is incomplete whenever a violation is detected in the portion of the program organization unit examined. d. Handle each user violation designated as an error in Appendix E to this part by at least one of the following methods: 1. There shall be a statement in the accompanying documentation that the error was not reported. d. 2 During program preparation for execution, the system shall report the possible occurrence of each type of error. d.3 During program preparation for execution, the system shall report errors. d.4 During program execution, the system shall report errors and terminate execution of the program organization unit, reset the global variable "OK" to zero, and initiate the appropriate system or user-defined error handling procedures. If any default designated as an error is handled as described in (d.1) above, then comments referring to each such handling shall appear in the respective sections of the accompanying documentation.
A document describing each feature accepted by the system that is prohibited or not specified in this part shall be accompanied by a description, e,
, which is an extension of the language defined in GB/T 15969.3", 1: any use of any such extension can be handled in a manner similar to that specified for errors. Name, any use of an implementation-related feature specified in Appendix D can be handled in a manner similar to that specified for errors.
h. For manufacturer-defined features whose functionality is different from that of this part, any data class, function or kinetic block name defined in this part shall not be used. The phrase "can" used in this clause allows the user to control the printing of reports with switches in the execution software. When the coding or program input fails due to certain restrictions such as tables, "although no violation is detected, the check is incomplete" is considered to meet the requirements of this clause. 3.3.2 Programs
PC programs shall comply with the following requirements:
GB/T 15969. 3—1995
(a) Use only those features specified in this part for the particular language being used. (b) Do not use any features that extend the language. (c) Do not rely on any special interpretation of implementation-dependent features. The results produced by a compliant program shall be the same when processed by any compliant system, except that these results are affected by the timing of program execution, the use of implementation-dependent features (listed in Appendix D) in the program, and the implementation of error recovery procedures. 2 Common elements
This subclause defines the textual and graphical elements that are common to all PC programming languages that are specified by this part of the standard.
2.1 Use of printed characters
2.1.1 Character set
Textual elements of textual and graphical languages shall be represented in accordance with the "Basic Code Tables" of the GB 1988 character set and the "Basic Set" of the GB 2312 Chinese Character Coded Character Set for Information Interchange. The character set shown in characteristic 1 of Table 2.1.1 consists of the characters in columns 3 to 7 of the basic code table \ given in Table 1 of GB1988, except for lowercase letters and those characters whose positions are reserved or optional in the national character set. When lowercase letters (characteristic 2) are supported, the case of letters shall no longer be significant in language elements (except for comments defined in clause 2.1.5 and string literals and variables of type STR1NG defined in clauses 2.1.5 and 2.3.1 respectively). For example, the identifiers "abcd", "ABCD\ and "aBCd have the same meaning. The manufacturer shall make the choice (a or b) for each of the characteristics (3a, b) to (5a, b) in Table 2.1.1 according to the following rules. "The pound sign should be used in the position of the number sign (#), which occupies 2/3 of the character position in the national implementation of the GB198 character set. The currency sign should be used in the position of the dollar sign ($), which occupies 2/4 of the character position in the national implementation of the GH1988 character set.
When the 7/12 character positions of the GB1988 character set are used by other characters in the national character set, the "shock sign" (!) at the 2/1 position should be used to represent a vertical line. m-Chinese character set according to GB2312
Note: The use of characters in the national character set is a typical extension of this standard. Table 2.1.1 Character set characteristics
2.1.2 Required character nesting for identifiers
See above
Lower case characters | |tt||Number sign (#)
English sign
Dollar sign (S)
Currency symbol
Vertical bar ()
Shock sign ()
An identifier is a string of letters, numbers, and underscore characters, and it should begin with a letter or an underscore character. Underscores should be meaningful in identifiers. For example, \A_SBCD\ and \AB_CI\ should be interpreted as different identifiers. Identifiers should not contain embedded space (SP) characters.
GB/T75969.3—1995
At least six characters should be supported in all systems that support the use of identifiers. In all such systems, \ABCDEI\ should be treated as different identifiers from "ABCE2".
Table 2.1.2 Identifier Characteristics
Characteristics
Uppercase and digits
Uppercase and lowercase letters, digits, embedded underscores Uppercase and lowercase letters, math, leading or embedded underscores 2.1.3 Keywords
JW2151W215Z QX75 DENT
All of the above plus:
I.IM_SW_ 5 I.imSw5 abed ab_Cd All of the above plus,
MAIN 12V?
Keywords are unique combinations of characters used for individual syntax elements as defined in Appendix B: All keywords used in this standard are listed in Appendix D. Keywords should not contain embedded spaces. The keywords listed in Appendix C should not be used for any other purpose, such as variable names and extensions as defined in Clause 1.5.1. Note: National standards organizations may publish conversion tables for the keywords given in Appendix C. 2.1.4 Use of spaces
Users should be allowed to insert one or more spaces (code positions 2/0 in the GB1988 character set) anywhere in the PC program text, except within a keyword, literal, identifier or qualifier combination (such as the comments defined below). 2.1.5 Comments
User comments shall be delimited by special character combinations \(*” and “)” at the beginning and end, respectively, as shown in Table 2.1.5. Except for the IL language defined in clause 3.2, comments can be added to any place in the program where spaces are allowed. (But except for the characters defined in clause 2.2.2, comments shall not have syntax or semantics. Nested comments are not allowed. For example (* (*NESTED)*) Table 2.1.5 Comment characteristics
2.2 External representation of data
Characteristic description
(* ＊＊
*★★＊)
(*A good side comment
(**★*★***)
In various PC programming languages, the external representation of data shall consist of numeric literals, character literals, and time literals. 2.2. 1Number literals
There are two types of numeric literals: integer literals and real number literals. A numeric literal is defined as a number in base 1 or base 2. The maximum value of each numeric literal shall be representable in the entire range and have exact values for all numeric types in a given implementation. Such numeric types shall be represented by the literal itself in the implementation. A single underscore character () between digits of a numeric literal is meaningless. Other uses of the underscore character are not permitted in numeric literals.
1Number literals shall be represented in the traditional decimal notation. Real number literals are distinguished by the presence of a decimal point. An exponential representation is an integer power of ten multiplied by the preceding number to obtain the represented value. Decimal literals and their exponents can contain a leading sign (+1 or -). Integer literals can also be represented in base 2, 8, or 16. The base should generally be the base symbol. For base 16, a set of extended digits consisting of the letters A through F should be used, representing decimal 10 through 15, respectively. The base number should not contain a leading sign (+10 or -).
Boolean data should be represented by a literal with the value ^ or 1. 84
Integer literals
Real number literals
Feature description
Real number literals with exponents
Base-2 literals
Base-8 literals
Base-16 literals
Boolean 0 and 1
2.2. 2 Strings
GB/T 15969.3—1995
Table 2. 2. 1
Numeric literals
—12123456
-12. 0 0. 0
3.14159..26
1.0E:61.234E6
-1. 34E -12
2#1111_1111
(decimal 255)
(decimal 255)
2#11100000
(decimal 240)
(-+decimal 240)
A string literal is a sequence of zero or more characters preceded and followed by a single quote character (\). Within a string literal, a three-character combination of a dollar sign ($) and two hexadecimal digits shall be interpreted as the hexadecimal representation of an eight-bit character code. In addition, a two-character combination beginning with a dollar sign shall be interpreted according to Table 2.2.2.2 when it occurs within a string literal. Table 2.2.2-1 String literal characteristics
'SODSOA
Empty string (zero length)
Contains a single character A string of length 1
Contains a space character. A string of length 1
Contains a single quote character. A string of length 1
Contains CR and LF characters. A string of length 2 can print "$1. 00" A string of length 5
Table 2.2.2-2 Double character combinations in strings
Interpretation when printing
Dollar sign
Single quote
Note: "The new line character provides an execution-dependent means of determining the end of a line of data for both physical I/O and file I/O; for printing, its effect is to end a line of data and resume printing at the beginning of the next line. Time literature
GB/T 15969.3-.- 1995
It is necessary to provide external representations for two different types of time data: ① duration data, used to measure or control the time elapsed by a control event, and ② moment data (which may also include date information), used to synchronize the start or end of a control event to an absolute time. ③Duration and moment texts shall appear in Clauses 2.2.3.1 and 2. 2.3.& The key to the definition is delimited on the left. 2.2.3.1 Duration
Duration data shall be preceded by a key and # delimited on the left. The representation of duration data in terms of days, hours, minutes, seconds and milliseconds or any combination thereof shall be consistent with that shown in 2.2.3.1. The least significant time unit may be written in real notation without an exponent. Units of a specific time literal may be separated by an underscore character. Overflow of the most significant unit of a specific time literal is permitted. The symbol T#25h-15m is permitted. Time units such as seconds, milliseconds, etc. may be indicated by upper or lower case letters. 2.2.3.1
Duration time literals
2.2.3.2 Time and date
Characteristic description
Duration time literals
(without underscore) bzxZ.net
Duration time literals
(with underscore)
T#14ms T#14.7s [#[4.7m
T#14.7ht#11.7dt#25h15m
t# 5d14h12118s3. 5ms
I #14.7s Ti14.7m T#14+7h
T#14ms
t#25h15m
t# 5d 14h 12m186 3. 5ms
The leading keywords of time and date shall be as shown in Table 2.2. 3.2-1. The representation of time and date information shall meet GB 2809. Table 2, 2.3.2-1 Time and date characters
Characteristics
Date characters (long prefix)
Date characters (short prefix)
Time characters (long prefix)
Inch characters (short prefix)
And period and time characters (long prefix)
All period and time characters (short prefix)
Table 2. 2. 3. 2-2
Long prefix symbol representation
DATE1984-06-25
date # 1984-06-25
:TIME_OF_DAY#15:36;55.36
time_of_day t 15:36:55.36
DATE_ AND.TIME#1984-06-25-15:36:55.36date_and_timet1984-06-25-15:36:55.362.3Data Types
Pre-Key Learning
TME_OF DAY#
DATE AND_TIME#
Examples of Date and Time Text
Short Prefix Notation
D1984-16-25
d#1984-06-25
TOD#15;36:55.26
a#15:36.55.36
DT#1984-06-25-15:3655.36
dt #1984-06-25-15 :36: 55. 36GB/T15969.3—:1995
If ten basic (predefined) data types are recognized in this standard. In addition.Defines the generic data types used in the definition of overloaded functions (see clause 2.5.1.4). Also defines a method for the user or manufacturer to specify additional data types. 2.3.1 Basic data types
The basic data types, the keywords of each data type, the number of bits per data element and the range of values for each basic data type shall be as shown in Table 2.3.1.
Basic data types
Table 2.3.1
Keywords
TIMEF.DAY
DATE.AND.TIME
STRING
Data type
Edge-triggered Boolean
Short integer
Double integer
Long integer
Unsigned short integer
Unsigned integer
Unsigned double integer
Unsigned long integer
Long real
Duration
Date and time
Variable length string
Bit string of length 8
Bit string of length 16
Bit string of length 32
Length 64
1) The variable values of these data types shall be 0 or 1, but the use of the function block auxiliary input +EDGE type specified in clause 2.5.2 is restricted. 2) The length of these data elements is implementation-dependent. 3) The variable value range of this data type is from -(2**(bit-1)) to (2**(bit1))-1. 4) The variable value range of this data type is from 0 to (2**bit)-1. 5) The variable value range of this data type shall comply with the provisions of SJ/Z 907I for the basic single-precision floating point format. 87
GB/T 15969. 3—1995
6) The variable value range of this data type shall comply with the provisions of SJ/Z 9071 for the basic double-precision point format. 7) The variable value range of this data type is implementation-dependent. B) The numerical range of value is not applicable to this data type. 2.3-2 Generic Data Types
In addition to the data types in Table 2.3.1, the hierarchy of generic data types shown in Table 2.3.2 shall be used in the specification of overloaded inputs and outputs of standard functions and function blocks as defined in Clause 2.5.1.3. Generic data types are identified by the prefix "\ANY". These data types shall not be used in user-specified program organization units as defined in Clause 2.5. Table 2.3.2 Generic Data Type Hierarchy
ANY NLM
ANYREAL
ANY INT
ANYBIT
2.3.3 Derived Data Types
2.3.3.1 Description and Initialization
STRING
ANY_DATE
DATE_AND _TINE
TIME OF DAY
Derived (i.e., user- or manufacturer-defined) data types may be declared using the TYPE-END-TYPE text structure shown in Table 2.3.3.1. In addition to the basic data types defined in clause 2.3.1, these derived data types may be used in variable declarations as shown in clauses 2.4.1.2 and 2.4.2.
An enumerated (ENUMERATED) data type declaration specifies that the value of any data element of this type may only be one of the values given in the table associated with the identifier. See Table 2.3.3. 1. A SUBRANGE specification specifies that the value of any data element of this type can only be between the specified upper and lower limits (including the upper and lower limits). As shown in Table 2.3.3.1. A STRUCTURE specification specifies that data elements of this type should contain sub-elements of a specified type that can be accessed by a specified name. For example, an element of the data type ANALOG_CHANNELCONFIGURATION described in Table 2.3.3.1 will contain a RANGE sub-element of type ANALOGSIGNALRAGE, a MAX_SCALE sub-element of type ANALOGDATA, and a MAX_SCALE element of type AVALOG_DATA. An array specification specifies that sufficient data storage space should be allocated for each element of this type to be able to store all the data in the sub-range specified by the index. Thus, the type ANALOG16_INPUT shown in Table 2.3.3.1 Any element of _CONFIGUREATION must contain (among other elements) sufficient storage for 16 CHANNEL elements of type ANALOGCHANNEL_CONFIGURATION. Methods for accessing array elements are described in Section 2.4.1.2.1. A structure specification specifies that data elements of this type shall contain sub-elements of a specified type that can be accessed by a specified name. For example, an element of the data type ANALOG_CHANNELCONFIGURATION specified in Table 2.3.3.1 will contain a RANGE sub-element of type ANALOGSIGNALRAGE, a MIN_SCALE sub-element of type ANALOGDATA, and a MAX_SCALE element of type AVALOG_DATA. An array specification specifies that sufficient data storage space shall be allocated for each element of this type to be able to store all the data in the sub-range specified by the specified index. Thus, any element of type ANALOG16_INPUT_CONFIGUREATION shown in Table 2.3.3.1 must contain (among other elements) sufficient storage space for 16 CHANNEL elements of type ANALOGCHANNEL_CONFIGURATION. Methods for accessing array elements are described in Clause 2.4.1.2.1. A structure specification specifies that data elements of this type shall contain sub-elements of a specified type that can be accessed by a specified name. For example, an element of the data type ANALOG_CHANNELCONFIGURATION specified in Table 2.3.3.1 will contain a RANGE sub-element of type ANALOGSIGNALRAGE, a MIN_SCALE sub-element of type ANALOGDATA, and a MAX_SCALE element of type AVALOG_DATA. An array specification specifies that sufficient data storage space shall be allocated for each element of this type to be able to store all the data in the sub-range specified by the specified index. Thus, any element of type ANALOG16_INPUT_CONFIGUREATION shown in Table 2.3.3.1 must contain (among other elements) sufficient storage space for 16 CHANNEL elements of type ANALOGCHANNEL_CONFIGURATION. Methods for accessing array elements are described in Clause 2.4.1.2.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.