Citect for Windows Driver Specification DanBuss DNIP Driver

3.1 Cache
Driver Design Specification
3. General Driver description
This driver is of the ‘Front-End-Back-End’ type, and therefore has a cache list of variables that has
been read by Citect. The driver automatically updates the variables in the cache list with the highest
possible speed. If Citect has not re-read the value within 30 seconds (adjustable, default) then the
cache element will be erased (another page is selected etc). The size of a cache element is minimum
29 bytes, and maximum 243 bytes. This is allocated from the linear 32-bit memory space.
The cache list limit depends on the system.
3.2 Request Performance
Due to the nature of the DANBUSS protocol, Citect blocked reads will almost always decrease
performance. However, the driver will group all cache elements that belongs to the same device together
at allocation time, and then automatic block read requests in the way that is required by
DANBUSS. The internal blocking will request a maximum of 36 values at one time from one device.
The medium time for such a request is about 1,0-1,2 seconds. If the variable is not set as ‘ScanList
Request’ in DANBUSS.DBF, it will never be blocked. An exampel of such variables are texts, which
can not be read by the DANBUSS blocked read function. Non-blocked reads has a medium request
time of 0,4-0,9 seconds.
This means that Citect indicates a very high channel usage, though the default is to handle 75 outstanding
DCB’s at one time.
3.3 Reads and Request Priority
‘First time’ cache elements always gets the highest priority, and will be handled directly when the
outstanding request is finished. This is true because the driver places all ‘first time’ cache elements
that is created (caused by a DCB for a new variable) first in the request list for that device. The driver
scans the cache list for ‘first time’ cache elements, and then requests upto 36 variables from the
same device. In that request, maybe only the first 6 are ‘first time’. Next, it will check for the next
device if there are any ‘first time’ cache elements and it will be treated in the same way. This is also
true when a write request has been handled. The cache element that has the same address (variable)
gets the highest priority. Write requests always has the highest priority.
3.4 DANBUSS Performance
The DANBUSS is a routing net protocol (though routing is not supported by the driver), which communicates
with the maximum speed of 4800 bps. This means that it has a generally bad performance.
When a user uses the DANSETT hand-held manouver device, that is to be connected directly to
DANBUSS, it will significally decrease performance of the bus. To avoid that the DANSETT gets
slow and packets are dropped, the driver will increase the delay between reads when only normal
priority cache elements exists in the cache list (the high priority can only be achieved in two ways;
first time reads, and directly following a write). Most of the time the driver only will scan for alarms,
which always will get normal priority following their first read. The increment of the delay is made by
multiplying the delay by a factor of 5 (default, may be changed). The default delay is 250 ms, and
therefore the normal (idle) update interval will be 1,25 seconds.
DanBuss DNIP.doc 8