| The driver mediates for the application of the Control Web system data of system installation bus-bar EIB (European Installation Bus) for management of buildings connected by means of the interface module DataLab IF/EIB. |
Moravian instruments, Inc., source: https://www.mii.cz/art?id=191&lang=409, printed: 30.04.2025 23:33:43
Main page▹Products▹DataLab industrial input/output system▹DataLab - Industrial input/output devices | 27.4.2020 |
|---|
| The driver mediates for the application of the Control Web system data of system installation bus-bar EIB (European Installation Bus) for management of buildings connected by means of the interface module DataLab IF/EIB. |
|
Contents of section: Installation of the driverThe driver DataLab IF/EIB can be used in systems Control Web 5 and Control Web 2000 always in the environment of the operating systems Windows NT v5.0 and higher which corresponds to the current operating systems Windows 2000, Windows XP and Windows 2003. Warning: Other operating systems, e.g. Windows ME or Windows NT 4.0, do not contain system calling necessary for running of the driver and, therefore, the driver is not able to work in them. Due to the requirements for robustness of industrial applications, the use of safe systems with the core being Windows NT v5.0 is desirable in every case and support of only Windows 2000 and Windows XP systems does not represent restriction in practice. The driver communicates with the interface DataLab IF/EIB by means of USB, which means:
Installation of the system USB driverThe system USB driver can be installed in two manners, automatically and manually. Automatic installation is very easy because it is controlled by the operating system.
Manual installation is in principle similar: on the installation CD in the CD-ROM drive you can find in the folder '\dleibdrv' the file 'dleib.inf', open by left mouse button above the file context menu (local menu) and by selection of the command Install... you will install the driver. Hint: Installation from the folder on the CD-ROM is not necessary. It is possible to copy both files on each medium. If, for example, the target computer does not have the CD-ROM drive, it is possible to copy the driver on the hard disk or on USB Flash Disk and install it from this copy. Warning: The driver'dleib.sys' is not equipped with a digital signature and the Windows system will notify it and ask whether to continue. If you want to install the driver, select Yes. The presence or non-presence of the digital signature is only a formal matter ensuring the use of only drivers checked by the firm Microsoft and does not influence the function of the driver. Installation of own driver for the Control WebsystemThe driver is installed by means of the program 'setup.exe' in the folder '\dleibdrv' of the installation CD. After running this program the wizard will guide you through the whole installation. We recommend performing full installation. The driver also contains this documentation. In the case of common installation, this documentation is located in the folder '\Program Files\Moravian Instruments\Drivers\DataLab IF EIB\Doc'. EIBThe system installation bus EIB (European Installation Bus) is starting to be quickly disseminated and it is not surprising — that by its using it is possible to integrate very easily all the required functions of buildings (and not only them) into self-contained and very easily maintained systems. The beginnings of this bar date back to 1991 when in the early variant Siemens developed it by specialization of its industrial communication protocol ProfiBUS. The consortium EIBA (European Installation Bus Association) originated and hundreds of companies gradually joined it. Approximately from 2002 the EIB busbar achieved some advantage when under the roof of the consortium EIB-KNX there was standardization and joining with other control systems of buildings. EIB is very strongly standardized, starting from the internal behavior of basic microprocessor building modules (BAU, BCU), through exact specification of data transfer (EIB communication stack) and possible data types (EIS = EIB Internetworking Standard) up to abstract logical arrangement of parameters and configurations of bus units. This standardization makes it possible for producers of part of the bus to quickly and easily produce and for users of the EIB network to easily and in a unified manner create and configure (by means of ETS, EIB Tool Software). In terms of information technologies, it is possible to divide EIB into two parts. The first part is the distributed system of units, when each part of the system (unit, actor, device, module, ...) is fully independent and able to perform a certain activity. This part corresponds to EIB parts, like transfer medium (TP = twisted wire, PL = low-voltage distribution 230V or iETS = transfer by means of UDP), communication, configuration of the communication buffer, behavior of units in the case of breakdown of supply, etc. The second part of EIB is more interesting — it contains groups and their linkages. Groups and their linkages are the main parts which give EIB its great simplicity and elegance. Group is a highly abstract term which in principle is very simple. The group has a data type (even if it is a number or logical data), a value corresponding to the type (value of temperature) and an address. This is quite clear. The group can bear values, inside statuses of the bus, or it can serve as a process tool (e.g. increase in brightness), it is always located “above” the network of units. Each unit of the network can be connected to the group (by means of group address) (more exactly one or more of its communication points = SAP = Service Access Point). Each network unit receives its image of the group which is remembered and with which it operates. One abstract group so exists in all units in a concrete form. The whole EIB then resolves by means of communication the only matter — how to ensure that these concrete group images in units are identical so that their values mutually correspond to each other. EIB groups, EIS and driverGroup addressesEIB group is indicated by the address. The address of the group (group address) is a 15bit number which gives the possibility to define up to 32768 different groups. Group addresses are written in two manners (it is a matter of selection of the creator of the EIB implementation) as numbers separated by slashes:
Of course, the driver DataLab IF/EIB works with group addresses and supports both their possible forms. In the parametric file (see of the Section Parametric file) the driver naturally uses the mentioned form with slashes, in the map file (in most cases created automatically) and in the application of the Control Web system it is not possible to use slashes for writing. Therefore, for the map file and the application it is possible to use position writing of the group address where individual parts of the group address are written into the decimal series of the resulting number:
It is evident that the writing of a two-part group address starts with number 1 in tens of millions and that the writing of the mail group and the two-part and three-part group address correspond to each other. The group address in the position writing (or in the application or in the map file) means directly the number of channel driver (and, therefore, it is used, for example, directly in the writing of the attribute driver_index of channels), so during the development of the application it is clear at first sight which groups correspond to the channel. Data TypesIn addition to the address, the group also relates to its data type. The data type of the group as a part of the EIB system is exactly given by the EIB standard (EIS) and, therefore, in the driver it is defined as this EIB (EIS) type. However, the Control Web uses other data types, so it is necessary to introduce between EIS types and types of the Control Web system some rules.. The Control Web system uses series of various types, so linkage with EIS types is natural. EIS types supported by the driver, corresponding data types of the Control Web system and possible meaning of values are defined in the Table .
Mutual conversion of EIS types and data types of the Control Web system There are several recommendations for correct use of EIS types in the application:
Conversion of percentage to fractions of the value for EIS2 Speed of EIBThe most often used (and the basic) transfer medium for EIB is twisted wire (TP) by which the interface is connected to the interface DataLab IF/EIB. This transmission medium uses the transmission speed 9600bps, which when considering the length of the shortest possible EIB TP telegram (8 byte), timeout and confirmation of the telegram (ACK) gives the communication speed of 64 EIB telegrams per second. It would not be too much if we wanted to communicate without stated rules. For technology of buildings it is enough because speeds of monitored and controlled actions are in tens and hundreds of seconds. The Control Web as general visualization and control tool works with its speed and due to its high performance it is very easy possible to overload EIB bus by careless (or incorrect) application. Therefore, we recommend keeping in the application the EIS standard from which there is the following quotation: Warning: EIBA Handbook Series, Internetworking standards, 2.3 General Requirements for Interworking, 2.3.1 Busload: Speed of repeating — the speed of repeating should be selected very carefully because it significantly influences the operation on the bus and there is a risk of its overloading. The expected load of the bus should be part of the plan of installation of the EIB network. The following rules are recommended:
Note: In most cases of automatic operations the sufficient speed of repeating is in minutes — for example, measurement of temperature, brightness, time, etc. always measure values which change slowly. Driver behaviorData objectsThe term data objects is met with in EIB in functional units. Each unit has a certain function, in most cases multiple (for example, two dark channels) and each function relates for the purpose of control and change in behavior to several data objects. The data object in the unit is connected to the group (by means of the group address) and if it is connected only to one group this data object (as mentioned above) is a concrete image of the abstract group. Nevertheless, data objects can be connected to more groups at once, one data object summarizes data from all these groups. It is clear from the principle of EIB communication that data objects belonging to more groups always have the value of the last modified group. The keeping of concrete group images in data objects can (according to the EIB standard) be influenced by the following options:
By a combination of the described options it is possible to achieve varying behavior of data objects. The driver DataLab IF/EIB for Control Web fully supports the above-mentioned options, and for easier work with objects the behavior originated by various combinations of objects is named. Moreover, as described in the Section about the file with parameters, it is possible to determine own behavior (i.e. a combination of options), exactly according to the required behavior of the object. The data object in the driver needs some other setting (because Control Web also has other possibilities than defined by EIB); at present this is the only expansion option:
Names used for behavior of objects are used by the driver DataLab IF/EIB (together with the respective combinations of options) as follows:
Data objects which are connected into more groups are in the application accessible under more numbers of channels — one channel number corresponds to each group address. Because all group addresses belong to one communication object, for the use of the object in the application it is possible to use any of its channels (any channel number). EIB links with the data object its importance, which has practical impact mainly during data transmission in the EIB network. The importance or class of the object (or priority ), can be the following:
The importance of the data object is in the driver DataLab IF/EIB related to the behavior of the object and in the parametric file it is defined in the same place (as it would concern the option of behavior of the data object), see SectionSection[behaviours]. Control Web uses directions when defining channels, which is a simple expression of the way data are transferred (output channel passes data from the application to the outer world and similarly input channel passes data from outer world to the application). Control Web 5 (and its successors) determines channel directions directly from the driver, so it is not possible to assign wrong direction to channels during application development. Control Web 2000 does not implement this feature and proper channel directions must be defined in the Driver Map File (.'DMF'). The following assignments of channel directions in the '.DMF' file and application are recommended to achieve proper channel (data object) functionality in Control Web 2000. If the different direction is specified the Control Web 2000 can unnecessarily ban the channel usage in particular direction:
Reading from EIBReading of data from EIB can be performed in the driver in two manners:
Channels of the application which are linked with the data object must be input or bidirectional. At the same time, it is valid (see above) that the value of the data object can be obtained in the application by reading of any channel of the data object (if the channel communicates, the communication is always performed by means of the first group address irrespective of the channel number which was used for access to data of the object). Writing into EIBWriting of data into EIB is performed in the driver in only one manner — the value from the application is written into the data object and if in the behavior of the object the option transmit is on, this new value is written into the EIB network into the first group of the object (into the first address of the object). Therefore, writing of data into EIB typically communicates and, therefore, loads the EIB network. Because there is communication during writing, it is possible to control and monitor writing and its result by means of the mechanism of the application (communication timeouts output_timeout etc. Channels of the application which are linked with the data object must be output (output) or bidirectional (bidirectional). At the same time, it is valid (see above) that the value of the data object can be written from the application by means of any channel of the data object (the writing is always performed into the first group address irrespective of the channel number which was used for access to data of the object). Status of the interface DataLab IF/EIB, exception of the driverThe USB interface by which the driver communicates can be connected or disconnected irrespective of the running of the application and irrespective of the status of the driver, the same is valid for the EIB network (ON/OFF). These statuses may be very important for the application, therefore, the driver provides the application in its status channel. The number of the status channel is optional (in the file with parameters). The change in the status of the driver (or the change in the status channel) is always reported to the application of the Control Web system by means of driver exception (the parameter driver_exception of instruments), so the application does not have the possibility to react asynchronously to any discrepancies. The status channel is a 32-bit number (longcard), in which individual bits have the following meaning: Example of reaction to the change in the status of the driver (in the Control Web system it is also possible to use the event procedure OnDriverException()): program EIBStatus;
driver_exception = EIBDriver;
procedure OnActivate( Time, Instrument, Driver, Data : boolean );
begin
if not Driver then
return;
end;
if bitget( StatusChannel, 0 ) = 1 then
(* we have device *)
else
(* we did not find any device yet *)
end;
if bitget( StatusChannel, 1 ) = 1 then
(* we have EIB connection *)
else
(* EIB is not connected *)
end;
end_procedure;
end_program;
Unrequired dataWarning: The communication of unrequired data cannot be used in the system Control Web 2000. Support of communication of unrequired data is available in the Control Web 5 system and higher. By definition, the EIB network is an environment in which individual units perform executing activity quite independently. This means that each unit can modify the value of the group when it wants to according to its need. In terms of other units (and also in terms of the driver DataLab IF/EIB) such change in the group looks quite asynchronous and unexpected — the unit receives data (new value of the group) without requiring them. The writing into the group (modification of the group value) can be considered on each unit an asynchronous event (events in programs usually mean activities originated from somewhere, not from the program itself). Expression means of the Control Web system offer for asynchronous events event procedures. Because during the communication the work is performed with channels (with data elements linked with the driver), for processing of unrequired data it is possible to use event procedures of the section in which the respective channels are defined. Communication of unrequired data is totally automatic. As soon as the driver processes the unrequired event, it informs Control Web which will ensure communication of unrequired data outside the queue by the common communication mechanism. It means that unrequired communication is reflected in this respect inside the application in the same manner as required communication — after its completion there is calling of the event procedure On*Communicated (see the description of event procedures of data sections in the documentation) and then, if communications caused change in the value of the element, also the event procedure On*Change. The mechanism of receipt of unrequired data respects the application — if the application (in the respective data section) does not contain any of the mentioned procedures, no data outside the queue cause any activity of the application (of course, the received value is stored in the driver; only the application does not know about it). Because (see Section Data objects) each data element relates to possibly more group addresses, during the processing of unrequired data it would be possible to use any channel. For practical reasons it is stated that unrequired data are in the event procedures On*Communicated andOn*Change always offered in the channel which corresponds to the first group address of the object. Or, the first group address of the data object has an extraordinary position not only on the part of EIB (it is used for writing and required reading), but also on the part of the application of the Control Web system — it is the only one used during the messaging of unrequired communication. The following simple example shows the procedure which processes all event procedures 3/2/13 (EIS2 dimming/control) and stores inside the variable Level the actual status of brightness of the dimmer (the procedure executes part of the function of the dimmer). Always when in the EIB network somebody writes into the group 3/2/13unrequired data are transferred from EIB into the Control Web system, which results in calling of the event procedure (in the example specific for one data element): data
var LIGHTS;
Level : shortcard;
end_var;
channel {driver = eib; direction = input};
DimmingControl = shortint {driver_index = 302013};
procedure On_DimmingControl_Communicated( Status : longcard );
begin
if Status <> 0 then
(* communication error *)
return;
end;
Level = min2( 100, Level + DimmingControl );
(* limiting Level to 0 is not neccessary, as shortcard data type cannot contain numbers lower than zero *)
end_procedure;
end_channel;
end_data;
The mentioned example is elementary, it does not deal, for example, with multiple use of the procedure for more elements, etc., nevertheless, the objective of the documentation of the driver is not to repeat information which is described in detail in the documentation for the Control Web system. For more knowledge we recommend the main documentation of the system. Unrequired data must be (to make sense) stored in the driver during the period from the origination of the event (receipt of the value in the data object) up to its processing in the event procedure. The excess in performance of the Control Web system towards EIB is great, despite this fact it could happen (on old or very burdened computers) that something can be lost without storage (it does not matter for darkening, but somewhere it depends on the number of writings (e.g. the value true), it could cause a problem. The storage of unrequired data is performed in the driver automatically and it is restricted by the parameter input_queue_length (see the section Parametric file). In the case of overflow of the queue, the driver informs the application by means of exception of the driver and setting the bit 3 (queue_overflow) of the status channel. In this case, it is possible to modify (increase) the length of the queue of unrequired data from the beginning 256 events to a higher number. Specific erroneous driver codesThe driver uses the following specific erroneous codes (these erroneous codes appear in the Message Window and they are also in the attributes error and write_error):
Remark: Erroneous channel codes specific for the driver are in the Control Web system distinguished from general erroneous codes by the value 65,536 (10000H). According to this shift, the Control Web system knows whether it concerns a general error valid within the whole system or a specific error valid for the respective type of driver. In the log window (Log Window) it is possible to see error codes decreased by 65,536 (in the case of DataLab IF/EIB codes 1 to 4). If the application directly reads the codes through the attribute channel:error the value of this attribute will be 65,537 to 65,540. Parametric fileAlthough most configurations of the driver are performed by means of the tool of the Control Web system (see Chapter), it is necessary for the parametric file to be described in detail. The parametric file contains settings which depend on the type of driver, so the parametric file for the driver DataLab IF/EIB cannot be used for another driver (ADAM units, etc.). The parameter file of the driver DataLab IF/EIB is text file arranged into sections with configuration parameters written in lines in the format key = value. The section serves for main classification, whereas the keys represent own setting. The driver DataLab IF/EIB uses in its parametric file the following default sections:
Inside these objects other (also default) keywords are used for writing of EIS data types and for writing of default behavior (behavior of data objects is described in Chapter Data objects, for writing of behavior in the parametric file, see sectionSection[behaviours]). There are three manners of naming data types in the driver — by number and two symbolic names:
Section[device]Section[device] contains the following keys:
Section[interface]Section[interface] contains the following keys:
Sections [read_on_start] and [read_during_run]Both sections contain settings defining behavior of requested reads from EIB network. The [read_on_start] section defines parameters for initial read on driver startup, [read_during_run] section defines parameters for requested reads during application runtime for objects with communicate_on_read parameter. The reading is affected by the following keys (all keys can be defined in both sections):
Section[behaviours]Section[behaviours] contains the following keys:
Options are derived from options of communication of data elements (see Section Data objects); so it is possible to write into the key the list selected from the following keywords:
Example: [behaviours] behaviour = all, readable, updateable, transmit, communicate_on_read, writable behaviour = my_transmitter, transmit, alarm Names of behavior (in the example all and my_transmitter) can be used in the driver anywhere the writing of the behavior name is required, which is either in the keys object and objects in the Section objects and in the key behaviour in the Section [<block_name>]. In addition to such user-defined behavior, the driver distinguishes default behavior, so it is probable that in common EIB settings it will not be necessary for [behaviours] to be used. Default behavior is (for more information, including its explanation, see Section Data objects): reader, tracker, transmitter, transmitter_with_status, server, source and concentrator. Section[objects]Section [objects] contains the following keys:
Keys object, as well as keys objects may be repeated without restrictions. Each object is written by means of these keys on individual lines. The format of writing of keys is as follows: object/objects = <behaviour>, <EIS type>, <address_list> Individual parts in the line mean:
Everything can be illustrated from the example: [objects] object = transmitter_with_status, switch, 3/1/9, 3/0/9 objects = transmitter, scaling, 3/3/0..3/3/13, 3/3/24 object = transmitter, 5, 4/0/0 ...
The definition of object having more group addresses (definition using object =) allows determine the single group address used for required reading (aka the reading directly from EIB network). The determination need not be set for any of defined address, in such case the first group address for the required reading will be used. Selecting of the group address used for required reading is simple only by writing the letter r or R exactly (without a space) before the group address. Slightly modified preceding sample shows this: [objects] object = transmitter_with_status, switch, 3/1/9, r3/0/9 ... So, the object defined in the sample will use the group address 3/1/9 for sending data and for the announcement of receipt of unrequired data, the group address 3/0/9 for required reading and both the addresses for receiving of data from EIB network. Section[blocks]Section[blocks] contains the following keys:
Section[<block_name>]Section[<block_name>] in the parametric file serves for easy writing of many data objects only by writing of their group address. The name of the section can be arbitrary. For the use of these sections there is only one condition: the name of the section (or <block_name>) must be known for the driver from some key block of the Section blocks. Section[<block_name>] contains the following keys:
Parameters of the object and objects are written similarly as in SectionSection[objects] with the difference being that not even behavior or EIS type is mentioned in the writing. The following example shows the definition of several sections <block_name>: [Lights] behaviour = transmitter type = switch objects = 10/5/20..10/6/20, 11/1/0..11/1/15, 1/1/5 object = 1/1/6, 1/1/7 [Presence] behaviour = tracker type = switch objects = 2/0/1, 2/1/1, 2/2/1, 2/3/1, 2/4/1, 2/5/1 [Temperatures] behaviour = tracker type = eis5 objects = 3/4/128..3/4/143 objects = 3/5/64..3/5/95 |