The DP identification in WinCC OA (shortly DP Id) is
a unique internal identifier for data point types, data points,
configs etc. The identification is mandatory when accessing DPs
via CTRL or from a user interface. The DP Id of the systems is
also exchanged when configuring a distributed system. The Id is
exchanged to be able to use the DPs on foreign systems (see also
Principle
and functionality of distributed systems). The Data Manager
administers the identification. Each manager gets the identification
from the Data Manager when starting. (Exception: when using a
local identification the DP Id is saved in files - further information
concerning the local Id is given later on this page).
Each DP of a system is accessed in WinCC OA internal via a number
instead of the name for performance reasons. This number is the
DP identification (= Id). The names are converted internal to
Ids via tables. The following information is used when converting
the names:
Data point types:
There is an internal table per DPT. This table contains the
name of types and elements.
Data points: There
is an internal table with the name per DP.
Data point elements:
There is an internal table per DPE. The table contains the
description, unit, format and alias.
System name
Config and attribute
names (these are fixed and not changeable in the project)
In bigger projects,
of course, also the DP ID is bigger and can be up to several MBs.
The access to DPs (e.g. with CTRL) would not be possible without
this Id.
WCCOAtoolNameToId
Use the tool WCCOAtoolNameToId
to determine the data point ID using the data point name
and vice versa. Start the tool via the Shell of the operating
system. The command has the following syntax:
C:\>WCCOAtoolNameToId
-proj <projectName> <SystemnName>:<data point name>
or
C:\>WCCOAtoolNameToId
-proj <projectName> <systemNumber>.<data point
ID>.<element ID>
Figure: Example of a Shell command
with specification of the data point name and the DP ID
The information is displayed in the WinCC OA log viewer, when
the project is running, or is written to the WCCOAtoolNameToId1.log
file of the /log directory
of the WinCC OA
project.
The following is displayed according to the
input order above:
Type: 37 Sys:
1 Dp: 93 El: 0 : 0..0)
whereby
Sys: 1
indicates the system number and Dp:
93 indicates
the DP-ID.
System1:ExampleDP_BarTrend
Independent of whether the data point name or the
ID is prompt in the Shell, the system number has always to be
passed.
Caution
When using WCCOAtoolNameToId on Solaris, WinCC OA has to run complete
or has to be stopped and the Im_ip has to run.
NOTE
Stop the tool by pressing Ctrl + Z.
Local identification
Specific for slow connections (e.g. remote UIs
via modem connection) is the start phase of a manager when the
whole ID is transferred. In bigger projects the start phase is
sometimes very long. To improve this the Id
can be saved on the local computer. There is the
following config entry for using the local Id:
Entry |
Range |
Default |
Description |
useLocalIdentification |
0, 1 |
0 |
Specifies
whether a manager should read the identification (TypeContainer
and DpIdentification) from a local file or gets it from
the Data Manager. When finishing, the Id is saved in the
<proj_path>/data/DpMsgTypeContainer.bin
and <proj_path>/data/DpMsgIdentification.bin
files. If the files do not exist in spite of this entry,
the manager starts normal and gets the identification
from the Data Manager. The entry can only be set in the
[ui] section. For example:
[ui_3]
useLocalIdentification
= 1 |
|
When the manager starts the first time (the manager
for which the config entry was set) the Id is transferred by the
Data Manager (since the files for the local Id are not created
at this time). When the manager runs it
processes normally all changes. When stopping the
manager writes the current Id in the DpMsgTypeContainer.bin
and DpMsgIdentification.bin
files. These files are at last saved in the directory <proj_path>/data.
Another start of the manager does not transfer
the Id from the Data Manager anymore but reads it from the local
disk. For example DPs, which were created/deleted with an UI that doesn't use the local Id, are
not present anymore (if the UI
with the local Id was stopped while creating/deleting DPs and
afterwards started, i.e. the local Id is not updated). In order
to get the current Id again the manager has to be stopped, the
files have to be deleted and the manager has to be restarted so
that the current Id is transferred by the Data Manager. |