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.
$iec2cc oven.st > oven.cc
$cat oven.st | iec2cc > oven.cc
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
Once compiled, the resulting object code will have to be linked
the standard matplc library
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.
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.
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.
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.
varint : INT := 99;
varreal : REAL := 99.9;
TASK t1(INTERVAL := t#20ms, PRIORITY := 2);
PROGRAM foo WITH t1: PROG1(param1 := varint, param2 := varreal);
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
include another anywhere in the code using the syntax:
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.
leds AT %Lights : INT := 1;
left_bt AT %left_bt : BOOL;
right_bt AT %right_bt : BOOL;
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).
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 (In the above code sample, the embeded IL for 'param3' is not yet supported.
param1 = var1,
param2 = 45,
param3 = (
param4 = var4
$Date: 2005/12/08 09:13:44 $