Identifiers are defined at the declaration of variables (variable names), user-defined data types and at the creation of POUs (functions, function blocks, programs) and visualizations. You might follow the following recommendations concerning the naming of identifiers in order to make it as unique as possible.
(1) Variable names
The naming of variables in applications and libraries as far as possible should follow the Hungarian notation:
For each variable a meaningful, short description should be found, the base name. The first letter of each word of a base name should be a capital letter, the others should be small ones (Example: FileSize). If needed additionally an translation file for other languages can be created.
Before the base name, corresponding to the data type of the variable, prefix(es) are added in small letters.
|
Data type |
Lower limit |
Upper limit |
Information content |
Prefix |
Comment |
|---|---|---|---|---|---|
|
BOOL |
FALSE |
TRUE |
1 bit |
x* |
|
|
|
|
|
|
b |
reserved |
|
BYTE |
|
|
8 bit |
by |
Bit string, not for arithm. operations |
|
WORD |
|
|
16 bit |
w |
Bit string, not for arithm. operations |
|
DWORD |
|
|
32 bit |
dw |
Bit string, not for arithm. operations |
|
LWORD |
|
|
64 bit |
lw |
not for arithm. operations |
|
|
|
|
|
|
|
|
SINT |
-128 |
127 |
8 bit |
si |
|
|
USINT |
0 |
255 |
8 bit |
usi |
|
|
INT |
-32.768 |
32.767 |
16 bit |
i |
|
|
UINT |
0 |
65.535 |
16 bit |
ui |
|
|
DINT |
-2.147.483.648 |
2.147.483.647 |
32 bit |
di |
|
|
UDINT |
0 |
4.294.967.295 |
32 bit |
udi |
|
|
LINT |
-263 |
263 - 1 |
64 bit |
li |
|
|
ULINT |
0 |
264 - 1 |
64 bit |
uli |
|
|
|
|
|
|
|
|
|
REAL |
|
|
32 bit |
r |
|
|
LREAL |
|
|
64 bit |
lr |
|
|
|
|
|
|
|
|
|
STRING |
|
|
|
s |
|
|
|
|
|
|
|
|
|
TIME |
|
|
|
tim |
|
|
TIME_OF_DAY |
|
|
|
tod |
|
|
DATETIME |
|
|
|
dt |
|
|
DATE |
|
|
|
date |
|
|
ENUM |
|
|
|
16 bit |
|
|
e |
|
|
POINTER |
|
|
|
|
p |
|
ARRAY |
|
|
|
|
|
a |
|
* pointedly for BOOLean variables x is chosen as prefix, in order to differentiate from BYTE and also in order to accommodate the perception of an IEC-programmer (see addressing %IX0.0).
Examples:
bySubIndex: BYTE;
sFileName: STRING;
udiCounter: UDINT;
In nested declarations the prefixes are attached to each other in the order of the declarations:
Example:
pabyTelegramData: POINTER TO ARRAY [0..7] OF BYTE;
Function block instances and variables of user-defined data types as a prefix get a shortcut for the FB- resp. data type name (Examle: sdo).
Example:
cansdoReceivedTelegram: CAN_SDOTelegram;
TYPE CAN_SDOTelegram : (* prefix: sdo *)
STRUCT
wIndex:WORD;
bySubIndex:BYTE;
byLen:BYTE;
aby: ARRAY [0..3] OF BYTE;
END_STRUCT
END_TYPE
Locale contants (c) start with prefix c and an attached underscore, followed by the type prefix and the variable name.
Example:
VAR CONSTANT
c_uiSyncID: UINT := 16#80;
END_VAR
For Global variables (g) and Global constants (gc) an additional prefix + underscore is attached to the library prefix:
Examples:
VAR_GLOBAL
CAN_g_iTest: INT;
END_VAR
VAR_GLOBAL CONSTANT
CAN_gc_dwExample: DWORD;
END_VAR
(2) User-defined data types (DUT)
The name of each structure data type consists of a library prefix (Example: CAN), an underscore and a preferably short expressive description (Example: SDOTelegram) of the structure. The associated prefix for used variables of this structure should follow directly after the colon.
Example:
TYPE CAN_SDOTelegram : (* prefix: sdo *)
STRUCT
wIndex:WORD;
bySubIndex:BYTE;
byLen:BYTE;
abyData: ARRAY [0..3] OF BYTE;
END_STRUCT
END_TYPE
Enumerations start with the library prefix (Example: CAL), followed by an underscore and the identifier in capital letters..
Regard that in previous versions of CODESYS ENUM values > 16#7FFF have caused errors, because they did not get converted automatically to INT values. For this reason ENUMs always should be defined with correct INT values.
Example:
TYPE CAL_Day :(
CAL_MONDAY,
CAL_TUESDAY,
CAL_WEDNESDAY,
CAL_THIRSDAY,
CAL_FRIDAY,
CAL_SATURDAY,
CAL_SUNDAY);
Declaration:
eToday: CAL_Day;
(3) Functions, Function blocks, Programs (POU)
The names of functions, function blocks and programs consist of the library prefix (Example: CAN), an underscore and an expressive short name of the POU (Example: SendTelegram). Like with variables always the first letter of a word of the POU name should be a capital letter, the others should be small letters. It is recommended to compose the name of the POU of a verb and a substantive.
Example:
FUNCTION_BLOCK CAN_SendTelegram (* prefix: canst *)
In the declaration part a short description of the POU should be provided as a comment. Further on all inputs and outputs should be provided with comments. In case of function blocks the associated prefix for set-up instances should follow directly after the name.
Actions get no prefix; just actions which should be called only internally, i.e. by the POU itself, start with prv_.
Each function - for the reason of compatibility with previous CODESYS versions - must have at least one parameter. External functions must not use structures as return values.
(4) Identifiers for Visualizations
Note: Currently you must avoid that a visualization has the same name like another POU in the project. This would lead to problems in case of changes between visualizations.