To query about the value of a data point, you need to know its complete name. It consists of three (or possibly four) parts as follows:
VDDSAIA does not require configuring individual data points; using a correct query, you can request the value of any existing data point (of a supported type) in a correctly connected PCD. You only need to create at least one working topic through which you will access the data points. All data points of a single topic share the same connection (and, consequently, the same communication channel) and the same value update rate.
One connection may be used by several topics, which may differ in their update rate. Typically, a topic with high priority (update rate) will be used for several critical data points, while a topic with low priority (update rate) will be used for a larger number of less-important points. One data point can be accessed through several topics, whether they use the same connection or not - a PCD may be connected to the PC over the Ethernet and a serial line at the same time, e.g. for security reasons.
These are topics created and configured by the user. The brackets following the description of each data point contain its data type.
These are data points corresponding 1:1 to data points (registers) in a PCD.
These are data points providing statistical and operating information relating to the connection to which the given topic belongs. They do not have any image in the PCD memory; they are only VDDSAIA internal values.
The maximum value of all counters in the application is 1 billion. If this value is reached, the counter resets to zero.
This topic is always available upon start-up, regardless of configuration. Its name is always 'STATUS'. Its data points provide statistical and operating information relating to the entire instance of VDDSAIA.
The smallest quantity unit of working block update is a planning block. A planning block includes one or several successive data points of the same type. It is specified by the indices of the first and last data points.
For example, block I_50-I_65 includes 16 data points (PCD inputs) with indices from 50 to 65. Block RI_145 contains a single data point with index 145 (PCD register expressed as an integer).
The reason for combining data points into blocks is the fact that querying the connected PCD about a whole block of successive points with a single query is much faster and less demanding on the communication channel capacity than making individual queries point by point, even if the block includes inactive data points, i.e. points that are not queried by user applications and whose values are totally uninteresting for VDDSAIA.
The list of planning blocks, i.e. the update plan, is kept in the memory throughout the application runtime. Plan adjustment, i.e. planning, is only performed at the moment when some of the data points are activated or deactivated. Combining neighbouring points into blocks as well as merging/splitting neighbouring blocks is governed by their position on an imaginary number line, which is given by the index, and the priority of points. The distance of two neighbouring active points/blocks is measured as the number of inactive points in between them. The user can set up the maximum distance of points in a block, as well as a condition determining whether points have to have the same priority to be included in a common block. If the user allows points with different priority to be included in a single block, the block gets the highest priority assigned to one of its blocks.
For example, if the maximum distance of points in a block is set to 2, points I_2 and I_5 will be included in one block when the second of them is added (regardless of their order), while with a maximum distance of 1, they will constitute separate blocks.
If follows from the above that when designing an application for the PCD, it is advisable to make data exchange with a PC use such data points (inputs, outputs, registers, etc.) whose indices constitute as few clusters as possible on the imaginary number line, if we can do that.
As said in the previous chapter, Planning, the smallest quantity unit of the update of working data points is a planning block including one or several successive data points of the same type. The smallest time unit of update is an update period. Planning blocks updated in one update period constitute an update batch. The user can specify both the frequency of update periods and the maximum number of blocks constituting one update batch.
An update cycle is finished when the whole planning list is updated. However, only planning blocks with a priority of 1 are updated in each cycle. Blocks with a priority of 2 are updated in each 2nd cycle, blocks with a priority of 3 in each 3rd cycle, etc. Each planning block keeps a counter saying how many cycles remain before it is updated. Only if a new data point has just been added to a block, the block will be updated on the next occasion (out of order).
If the current total number of planning blocks is less than the user-specified maximum number of blocks that may constitute one update batch, the entire update cycle is carried out in one update period. However, if there are more blocks, several update periods are needed to carry out one cycle, which will decrease the update rate of individual points. It results from this that the update frequency of individual points cannot be fixed, since it depends on the number of active (queried) data points and their distribution among blocks.
The application allows recording information about the occurrence of different types of events, i.e. logging. Data can be logged in a file and/or in the main application window. Below is a list of available types according to which all events are classified, together with the numerical value that states their seriousness.
The user can choose the level of seriousness for events to be logged in the main application window and in a file independently. When a level is selected, all events with the same or lower level number are logged.
To allow for easy localization of the application, all texts have been taken out of the application and put in a special file called "language definition file." To localize the application, only the texts contained in this file need to be translated and the actual application (exe file) does not need any modification, which makes localization a lot easier.
The only exception in localization is the communication channel settings window, since this window is opened and managed by the communication libraries developed by SAIA-Burgess. The possibilities of the window are described in the delivered SCommDlg.hlp help file in English.