The IzoT Markup Language (IML) consists of C comments that start with a //@IzoT tag. A //@IzoT string embedded within a C string constant or another C comment is not treated as an IML tag. The //@IzoT tag is not case sensitive, though many IML elements are case sensitive.
An IML declaration consists of the code to the left of the //@IzoT tag, the class name which follows, and all further attributes supplied in the remainder of the statement. You may use standard C comments within an IML statement.
The source to the left of the //@IzoT tag is required by most IML declarations, and generally declares one or more global C variables based on an IML-compatible type.
All variables implemented within the same declaration share the same attributes and modifiers, which are provided to the right of the //@IzoT tag.
The general form of an IML declaration is as follows:
type(modifier(s)) variable(s); //@IzoT class(modifier(s)) attribute(argument)...
The IML class names are block, datapoint, event, property, tag, and option. Class names are case insensitive. Each class has different requirements on type and class modifiers, and supports a different set of attributes.
You can split a single declaration over multiple lines using the standard C “\” line continuation character as the last character on the previous line. You must repeat the //@IzoT tag at the beginning of every continuation line. Failure to do so causes the C compiler to incorrectly read the declaration's attributes and generate errors or incorrect code.
Here's an example of a block implementation spanning multiple input lines. The example includes line numbers,starting at number 17.
17: SFPTopenLoopSensor(sensor ,SNVT_volt_f)sensor[8]; //@IzoT Block \
18: //@IzoT implement(nciGain, init={12, 13}), implement(nciLocation) \
19: //@IzoT external("sensor")
The IzoT Interface Interpreter reports IML syntax errors and warnings for any line of a multi-line IML declaration with the line in which the IML declaration was started. For example, this means that an error encountered when processing the external attribute supplied on the original line number 19 in the above example will be reported as an error occurring in line 17.
Multi-line IML declarations may trigger a C compiler warning about multi-line comments. You can ignore this warning, suppress it, or merge the multiline instruction into one line.If you use the GNU C/C++ compiler included with the CPM SDK, you can suppress this warning with the -Wno-comment compiler option.
The //@IzoT Block directive creates one or more blocks from a profile. The Block instruction syntax is as follows:
block-declaration ::= profile (profile-modifier) variables ; //@IzoT Block[(locator) [block-attributes ]where:
profile-modifier ::= type-modifier | type-modifier, snvt-xxx-type type-modifier ::= name xxx-type ::= datapoint type variables ::= variable | variable, variables variable ::= name | name[number] locator ::= location="Izot Python Resources package path" block-attributes ::= block-attribute | block-attribute, block-attributes block-attribute ::= external(external-name) | implement(member-name [, array=array-size] [, init=initial-value]) | onComplete(member-name, event-handler) | onUpdate(member-name, event-handler)
SFPTboilerController(boiler)boiler; //@IzoT Block
UFPTmyProfile(example)exampleA,exampleB[4]; //@IzoT Block(location="myResources.resources")
SFPTopenLoopSensor(sensor, SNVT_volt_f)sensor ; //@IzoT Block external("sensor")
| Syntax Element | Purpose |
|---|---|
| profile | The name of the profile, e.g. SFPTopenLoopSensor, UFPTheatExchanger. |
| type-modifier | A name or number which, in combination with the profile name (and, if provided, the xxx-type name, produces a unique name for the block type. You can use the block variable name for the type modifier. When a declaration implements multiple variables, you can use the name of the first. |
| xxx-type | The datapoint type to use for all generically typed (SNVT_xxx) profile members. This type is only required if the profile implements generic datapoint members. |
| variable | Name of the global C variable which implements this item. The optional external name for this item. This name appears in the device’s public network interface and helps the network integrator to identify the functionality you provide. |
external-name |
When a block’s external name is provided, all members are automatically implemented with external names derived from the member names defined in the profile. When a block's external name is not provided, block members have no external name.
Assigning an external name simplifies device installation for network integrators. |
member-name |
This can be a datapoint member, or a block property member. To specify a property which applies to a datapoint member, use the datapoint member name and the property member name, separated by a period. Example:
nvoLoad.cpnLoadControl |
array-size |
This attribute can only be applied to properties. The size supplied must be within the rules for array implementations detailed within the profile. If the size is not specified, the minimum array size specified by the profile is implemented. |
initial-value |
The initial value for the named member, expressed as a C language static initializer. You can specify any initial value, but the C compiler may report errors if the value provided does not meet the requirements of the type which is initialized. You can specify an i-string construct to simplify initialization of string-type members within a resource. For example, i"room 101" is equivalent to {"room 101"}. |
event-handler |
The name of your event handler function. The function must be a global function (not static) and match the IzoT Device Stack DX API requirements for the corresponding event. You do not need to specify the function prototype, but you must supply the implementation of this function. |
The //@IzoT Datapoint directive creates one or more device datapoints. The Datapoint instruction syntax is as follows:
datapoint-declaration ::= datapoint-type (type-modifier) variables ; //@IzoT Datapoint[(datapoint-modifiers)[datapoint-attributes]
where:
type-modifier ::= name variables ::= variable | variable, variables variable ::= name | name[number] datapoint-modifiers :: datapoint-modifier | datapoint-modifier, datapoint-modifiers datapoint-modifier ::= direction-identifier | locator locator ::= location="Izot Python Resources package path" direction-identifier ::= direction=(Input | Output) datapoint-attributes ::= datapoint-attribute | datapoint-attribute, datapoint-attributes datapoint-attribute ::= authentication(enabled= True | False [, configurable= True | False]) | comment("comment") | external(external-name) | init(initial-value) | onComplete(event-handler) | onUpdate(event-handler) | persistent(enabled= True | False [, configurable= True | False ]) | priority(enabled= True | False [, configurable= True | False ]) | service(servicetype= ACKD | UNACKD_RPT | UNACKD [, configurable= True | False])
The authentication attribute defaults to enabled=False, configurable=True.
The persistent attribute defaults to enabled=False, configurable=True.
The priority attribute defaults to enabled=False, configurable=True.
The service attribute defaults to servicetype=ACKD, configurable=True.
UNVT_test(a) a, b, c; //@IzoT Datapoint SNVT_switch(enable)nviEnable; //@IzoT Datapoint(direction=Output)
| Syntax Element | Purpose |
|---|---|
| datapoint-type | The name of the datapoint type, e.g., SNVT_switch, UNVT_lottery_numbers. |
| type-modifier | A name or number which, in combination with the datapoint type name, produces a unique name for the datapoint implementation type. You can use the datapoint variable name for the type-modifier. When a declaration implements multiple variables, you can use the name of the first. |
| variable | Name of the global C variable that implements this item. |
| initial-value | The initial value for the named member, expressed as a C language static initializer. You can specify any initial value, but the C compiler may report errors if the value provided does not meet the requirements of the type which is initialized.
You can specify an i-string construct to simplify initialization of string-type members within a resource. For example, i"room 101" is equivalent to {"room 101"}. |
| event-handler | The name of your event handler function. The function must be a global function (not static) and match the IzoT Device Stack API requirements for the corresponding event. You do not have to specify the function prototype, but you must supply the implementation of this function. |
The //@IzoT Event directive registers one or more handlers for device-wide events. The Event instruction syntax is as follows:
event-declaration ::= //@IzoT Event[event-specs]
where:
event-specs ::= event-spec | event-spec, event-specs event-spec ::= onOffline(event-handler) | onOnline(event-handler) | onReset(event-handler) | onWink(event-handler) | onService(event-handler)
| Syntax Element | Purpose |
|---|---|
| Event-handler | The name of your event handler function. The function must be a global function (not static) and match the IzoT Device Stack API requirements for the corresponding event. You do not have to specify the function prototype, but you must supply the implementation of this function. |
The //@IzoT Property directive creates one or more device properties. The Property instruction syntax is as follows:
property-declaration ::= property-type variables; //@IzoTProperty[(locator)] [property-attributes]
where:
variables ::= variable | variable, variables variable ::= name | name[number] locator ::= location="Izot Python Resources package path" property-attributes ::= property-attribute | property-attribute, property-attributes property-attribute ::= comment("comment") | flags(flags-value) | init(initial-value) flags-value ::= flag-value | flag-value + flags-value flag-value ::= Const | DeviceSpecific | Disable | Manufacture | Offline | Reset
The flags attribute defaults to zero (no flag).
SCPTlocation cpLocation; //@IzoT Property init("Room 101")
SCPTnwrkCnfg configurationSource; //IzoT Property init(CFG_EXTERNAL), flags(Reset)
The //@IzoT Tag directive creates one or more messages. The Tag instruction syntax is as follows:
tag-declaration ::= IzotTag variables ; //@IzoTTag[tag-attributes]
where:
variables ::= variable | variable , variables variable ::= name | name[number] tag-attributes ::= tag-attribute | tag-attribute , tag-attributes tag-attribute ::= bindable(True|False)
The bindable attribute defaults to True.
SCPTlocation cpLocation; //@IzoT Property init("Room 101")
SCPTnwrkCnfg configurationSource; //IzoT Property init(CFG_EXTERNAL), flags(Reset)
The //@IzoT Tag directive creates one or more messages. The tag instruction syntax is as follows:
tag-declaration ::= IzotTag variables ; //@IzoTTag[tag-attributes]
where:
variables ::= variable | variable , variables variable ::= name | name[number] tag-attributes ::= tag-attribute | tag-attribute , tag-attributes tag-attribute ::= bindable(True|False)The bindable attribute defaults to True. Here are usage examples.
IzotTag a, b; //@IzoT Tag IzotTag c; //@IzoT Tag bindable(False)
The //@IzoT Option directive selects one or more options. The Option instruction syntax is as follows:
option-declaration ::= Izot Option[option-attributes]
where:
option-attribues ::= option-attribute | option-attribute , option-attributes option-attribute ::= addresses (0..254) | aliases(0..127) | authentication(True | False) | buffersize(1000...65535) | output(“output-filename”) | programId(“program-id”) | strict(True | False) | target(“cpm-4200”) | variable(name, value) | verbose(True | False)
| Optipon Attribute | Purpose |
|---|---|
| addresses | The number of address table entries to be allocated for the device. If not specified, the IzoT Interface Interpreter computes a number based on inspection of your application"s interface. |
| aliases | The number of alias table entries to be allocated for the device. If not specified, the IzoT Interface Interpreter computes a number based on inspection of your application"s interface. |
| authentication | Enables authentication for the device. The default is False. |
| buffersize | The requested minimum buffer size for all input and output
buffers. The IzoT Device Stack allocates a buffer size equal to
or larger than the requested number if possible, or fails to initialize
if it cannot allocate the requested buffer size. If not
specified, the IzoT Interface Interpreter allocates buffers according
to the size of the largest datapoint (plus required protocol overhead).
If a Tag object is declared,
the IzoT Interface Interpreter ensures that the minimum
buffer size is at least 255 bytes.
Your explicit minimum buffer size request triggers warning 32 if it fails to meet the size required by the largest datapoint (and an allowance for protocol overhead). This warning becomes an error with the strict option. |
| output | The base name of the output files generated by the IzoT Interface Interpreter. The generated file names are basename.c and basename.h. The default base name is IzoTDev so the default output file names are IzoTDev.c and IzoTDev.h. |
| programId | The program ID for the device specified as a colon-separated string of hex digit pairs, e.g. "9F:FF:FF:00:00:00:00:01". |
| strict | Changes some of the generated warnings to errors. |
| target | The target platform for the application. The value is always "cpm-4200". |
| variable | Defines or modifies a variable in the IzoT Interface Interpreter's environment. These variables are defined as a name, value pair, and may be referenced in some Interface Interpreter output using UNIX-style $name or ${name} references. |
| verbose | Enables verbose IzoT Interface Interpreter output. |