Hello,
During an import, the datapoint defined in a dpl file, with a DPEid calculated (32 bits unsigned), this DP is created in the WINCC OA database with an DPEid different.
Note: the DPEid is generated to make sure of a uniqueness according to the name of the DP
Example of contents of a file dpl imported
...
MY_DP MY_DPT 4294645458
...
After the import with the ASCII manager (please note that MY_DP does not exist initially in the WINCC OA database and my DPEId is not either used by another DP),
the datapoint MY_DP is associated with then DPEid 2147484055 after the import!!
When we use DpCreate function, the datapoint is associated well with the DPEid(4294645458) defined in the parameter iof the function DpCreate
Futhermore, the export via the ASCII manager after a DpCreate generates a file dpl with the good DPEid (4294645458) !
It seems there's a problem on the import via ASCII manager there!
regards
Emmanuel Michoux
Import with ASCII manager does not support DPEid unsigned int?
- eMichx
- Posts:64
- Joined: Thu Apr 24, 2014 11:24 am
Import with ASCII manager does not support DPEid unsigned int?
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: Import with ASCII manager does not support DPEid unsigned int?
Hello,
yes, this seems to be a bug at the ASCII-manager, but it is not critical. Under normal circumstances you'll never get a DP-ID which is higher than the limit for the integer variable (2147483648).
Creating a datapoint with such a high ID has some consequences you shall be aware of.
The next datapoint which is created (without defining a specific ID) afterwards will get an ID which is the last used ID (in your case 4294645458) + 1.
If several datapoints are created you will reach the limit for the ID in a short time. When trying to create then a new datapoint you'll get the following error and the datapoint cannot be created.
WCCILdata (0), 2014.10.22 11:11:32.085, IMPL, SEVERE, 54, Unexpected state, PersDpIdentification, assignNewDpId, DP id overflow
To get rid of this problem then you will have to make some manual modifications in the RAIMA database using a RAIMA database tool when the project is stopped.
This procedure may cause some other problems if again datapoints are created and the automatically assigned ID will get the same value like already existing datapoints. I'm not sure what is happening then because we have never tested such a scenario.
Why do want to create the datapoint with a specific ID?
Best Regards
Leopold Knipp
Senior Support Specialist
yes, this seems to be a bug at the ASCII-manager, but it is not critical. Under normal circumstances you'll never get a DP-ID which is higher than the limit for the integer variable (2147483648).
Creating a datapoint with such a high ID has some consequences you shall be aware of.
The next datapoint which is created (without defining a specific ID) afterwards will get an ID which is the last used ID (in your case 4294645458) + 1.
If several datapoints are created you will reach the limit for the ID in a short time. When trying to create then a new datapoint you'll get the following error and the datapoint cannot be created.
WCCILdata (0), 2014.10.22 11:11:32.085, IMPL, SEVERE, 54, Unexpected state, PersDpIdentification, assignNewDpId, DP id overflow
To get rid of this problem then you will have to make some manual modifications in the RAIMA database using a RAIMA database tool when the project is stopped.
This procedure may cause some other problems if again datapoints are created and the automatically assigned ID will get the same value like already existing datapoints. I'm not sure what is happening then because we have never tested such a scenario.
Why do want to create the datapoint with a specific ID?
Best Regards
Leopold Knipp
Senior Support Specialist
- eMichx
- Posts:64
- Joined: Thu Apr 24, 2014 11:24 am
Re: Import with ASCII manager does not support DPEid unsigned int?
Hello,
Thanks for your answer.
The content of a dpl file is generated with an external specific tools which use documents as entries for generation.
When there's a change in these entries, we want to be sure that a new complete generation
of WinCC OA database (done with an import with ASCII manager) will be compatible with the previous archives.
To be sure of the continuity of the archives, the DP ID must be identicals (please correct me if I'm wrong?)
We use an algorithm to have a unique ID, based on the DP name, but the DP ID is a number base on an unsigned int.
regards
Emmanuel
Thanks for your answer.
The content of a dpl file is generated with an external specific tools which use documents as entries for generation.
When there's a change in these entries, we want to be sure that a new complete generation
of WinCC OA database (done with an import with ASCII manager) will be compatible with the previous archives.
To be sure of the continuity of the archives, the DP ID must be identicals (please correct me if I'm wrong?)
We use an algorithm to have a unique ID, based on the DP name, but the DP ID is a number base on an unsigned int.
regards
Emmanuel
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: Import with ASCII manager does not support DPEid unsigned int?
Hello,
it is correct that you need to have the same DP-ID if want to have access to values stored already in the archives.
But not only the DP-ID also the DPE-ID (dp element ID) must be the same. This can only be ensured when the dp-types do not use type references. For a dp-type which is not using dp-type references you can define the DPE-ID in the ASCII-file. When a dp-type references some other dp-types then the ID for the referenced elementes is assigned automatically.
Please change your functionality to use a signed int instead of an unsigned int. Then you may not get the problem that the DP-ID reaches the limit when datapoints are created without a specific ID.
If the database is created again all historical information is deleted from the existing database. If you are not using RDB archivation including saved historical data in the new database will be difficult and probably not possible for some parts of the database (historical alert information).
Best Regards
Leopold Knipp
Senior Support Specialist
it is correct that you need to have the same DP-ID if want to have access to values stored already in the archives.
But not only the DP-ID also the DPE-ID (dp element ID) must be the same. This can only be ensured when the dp-types do not use type references. For a dp-type which is not using dp-type references you can define the DPE-ID in the ASCII-file. When a dp-type references some other dp-types then the ID for the referenced elementes is assigned automatically.
Please change your functionality to use a signed int instead of an unsigned int. Then you may not get the problem that the DP-ID reaches the limit when datapoints are created without a specific ID.
If the database is created again all historical information is deleted from the existing database. If you are not using RDB archivation including saved historical data in the new database will be difficult and probably not possible for some parts of the database (historical alert information).
Best Regards
Leopold Knipp
Senior Support Specialist