3.1 Configuration dialog
The configuration dialog shown in Fig. 3.1 is part of the OwsDrv_H.dll file. It can be activated from RexDraw by pressing the Configure button in the parameters dialog of the IODRV block (see chapter 2).
The upper part of the dialog defines the connection to the owserver. The owserver typically runs on the same machine as RexCore but it is not a rule.
The individual signals to read or write from the REX control algorithm are defined in the lower part of the configuration dialog. Simply add the signals, use the device IDs displayed by the owdir command.
Signals can be added or edited after the double click on the selected item in the parametric dialog in Fig. 3.1 or after pressing the Add or Edit button in a small dialog in Fig. 3.2.
For an output signal (in the I/O column the output is selected), the Value is once written to the output if it is not overwritten from the control algorithm.
The signal table in the driver configuration dialog is processed cyclically during the run-time in the following way. Each output signal which has been changed since the last write is written with the value. Similarly, all input signals are being cyclically read in the same order. When a large number of inputs is configured the reading of the whole table can take quite a long time. Therefore, the owserver program allows to indicate signal changes as so called alarms in the /alarm directory, see section 3.2. This driver is able to process alarms from REX version 2.5.
Moreover, if the Uncached option is checked then the given signal will be always read directly from the connected integrated circuit (e.g. from the thermometer). If the Uncached is not checked then the returned value will be read from the cache memory which is typically updated each 15 seconds. Note: The more signals has chosen Uncached, the slower the response of this driver.
To optimize the performance of this driver it is helpful to know how the driver operates internally. The main loop activated each period of the driver always handles no more than one request to the owserver program and after sending a request to owserver, it does not wait on an immediate response (ie. If the response data are not available, it tries to get them in the next loop run). After initializing the driver (when the real/time executive is running) the main loop operates as follows:
- It check whether the currently processed request (from the previous call of this loop) has been completed.
- If so, it starts to process alarms (for details see next section).
- If no alarm is processed, it tries to write a single output value from the control algorithm.
- If no write is processed, it tries to read one input value to the control algorithm.
The above procedure shows that the highest importance (priority) has alarm processing, then writing the output values from the algorithm, and the lowest reading signals. In frequent occurrence of alarms (which is not normal) it could happen that writting and reading requests are not served at all (this effect is also called starvation). Therefore, it is possible to set the maximum number of consecutive served alarms in the driver configuration in Fig. 3.1. After this number of served alarms, the first of the other pending requests (writing or reading items) is processed.
[Back to top] [Up] [Next]