IEC ST/IL compiler

Introduction

To write an ST or IL program, use a text editor and save the file with whatever name you wish. We sugest you use <prog_name>.st or <prog_name>.il as this is the convention that has been followed in the MatPLC demo directories. The IEC 61131-3 standard simply uses files names <prog_name>.txt in their examples, so you may want to use that instead.

Turning the ST/IL file into a module

The resulting C++ code will need to be further compiled by a C++ compiler. Note that it needs to include the standard $MATPLC/lib/plc.h header file, as well as $MATPLC/logic/iec/stage4/generate_cc/plciec.h

Once compiled, the resulting object code will have to be linked with the standard matplc library $MATPLC/lib/matplc.[so|a]. We sugest that you use the working demo programs and makefiles in the $MATPLC/demo/basic_iec directory as a starting point.

The resulting executable code may be run as any other MatPLC module, including all the standard --PLC<plc_option> command line switches.

The ST and IL languages

A useful on-line reference is IEC 61131-3: Programming Industrial Automation Systems.

Note, however, that most books currently available on programming with the IL and ST languages refer to the first version of these languages, whereas the iec2cc compiler was built based on the 2nd verion of the standard. More precisely, the publicly available draft version of the standard, dated 10th december 2001, was used.

Current State of the IEC Compiler

Note however that not all syntax is yet suported when generating the equivalent C++ code. Aditionally, semantic checking is not yet performed, so most semantic errors (e.g. storing a TRUE value in a variable of type INT) in your programs will not be caught by the iec2cc compiler. Many semantic errors will nevertheless result in semantic errors in the resulting C++ code, so they will probably be caught later on by gcc, but this is not guaranteed.

Writing an IL/ST Program

However, only the first configuration will be used by the iec2cc compiler. Remaining configurations will simply be ignored. Currently, this configuration may only contain a single program attributed to a single task.

For e.g.

CONFIGURATION config1
  VAR_GLOBAL
    varint : INT := 99;
    varreal : REAL := 99.9;
  END_VAR

  TASK t1(INTERVAL := t#20ms, PRIORITY := 2);
  PROGRAM foo WITH t1: PROG1(param1 := varint, param2 := varreal);
END_CONFIGURATION

This implies that at the moment you will be writing a single program type, since a single instance of a single program type is currently supported.

The remaining functions and function blocks may be written in either ST or IL, as long as each function or function block uses a single language. The iec2cc compiler automatically distinguishes which language is being used.

Before calling a function, and before a function block or program instance is defined, the referenced function/function block/program must be defined. This means that when you can call a function, or create a function block instance, that function or function block instance must appear earlier in the file being compiled.

Note that your program may be divided into several files. A file may include another anywhere in the code using the syntax: (*#include "<filename>"*)

Note the lack of spaces between '(*' and '#include', as well as between the last '"' and '*)'. This syntax will be interpreted as a comment by other IL/ST compilers, but will probably nevertheless be changed to conform to the 'pragma' directive as defined in the IEC 61131-3 standard.

Accessing MatPLC Points

VAR_GLOBAL
  leds AT %Lights : INT := 1;
  left_bt  AT %left_bt  : BOOL;
  right_bt AT %right_bt : BOOL;
END_VAR

From this declaration onwards, accessing the 'leds' variable from within the IL/ST program will directly access the 'lights' MatPLC point.

If the MatPLC point is wider (has more bits) than the data type of the corresponding ST/IL variable, writing to this variable will set the unused bits to zero, while reading the variable will ignore the extra bits.

Likewise, if the MatPLC point has less bits than the data type of the corresponding ST/IL variable, then writing to the variable will essentially discard the higher valued bits, while reading from the variable will set the higher valued bits to zero.

Note however that MatPLC points may have names such as 'temp__alarm', that are not valid ST/IL identifiers. In this case it is not yet possible to map them to ST/IL variables (this issue will be resolved at a later date), so we sugest that an alternative name is given to these MatPLC points, or an alias be established (see the 'alias' table in the [PLC] section of the matplc.conf file).

Limitations and extensions

Namely, the following elementary data types are not yet supported: TIME, DATE, TIME_OF_DAY, DATE_AND_TIME, STRING, WSTRING

In addition, the following derived data types are also not yet supported: SUBRANGE. ENUMERATION and ARRAY. Note that STRUCTREs are supported.

Standard functions and function blocks have not yet been written, except for tentative test functions/function blocks such as: BCD_TO_INT, INT_TO_BDC, SR, RS, CU, CD, CUD, R_TRIG, F_TRIG.

Due to the way located variables are implemented, we do not yet support the passing of EXTERNAL variables, declared in programs or functions blocks, as OUT or IN_OUT parameters to functions.

Another restriction is in the calling of function blocks using the formal syntax from within IL code. In this case, a parameter may not be given the value obtained from an embedded list of IL instructions. For example, consider the following function block call:

CAL fb_instance (
      param1 = var1,
      param2 = 45,
      param3 = (
                LD var2
                ADD var3
               ),
      param4 = var4
    )      

$Date: 2005/12/08 09:13:44 $