Hello,
the error-message should be the same for the UI or the ASCII-manager when the limit is exceeded.
I'm not sure if changing the limit is a simple task, maybe we have to make some modifications at the database structure to allow a higher number of elements for one dp-type. Therefore those changes would only be possible in a new release.
If a dp-type has such a high number of dp-elements you will have only a few datapoints in your project.
How many datapoints shall be created for a datapoint-type with such a high number of elements?
Best Regards
Leopold Knipp
Senior Support Specialist
error importing with WCCOAascii
- xavi.aran
- Posts:63
- Joined: Thu Apr 21, 2011 1:21 pm
Re: error importing with WCCOAascii
Hi Leopold! The number of datapoints with high number of dp-elements is small yes, is around 50.
This datapoints has a tree datapoint structure that contains another dp-types than can be contains another dp-types....
The structure can be similar to this:
station
element_device (dp-type)
alarm (dp-type)
state (dp-type)
param(dp-type)
analog(dp-type)
atribute1 (dp-element)
atribute2 (dp-element)
............
element_device1 (dp-type)
alarm (dp-type)
state (dp-type)
......
attribute_station1
attribute_station2
.....
One alarm/state/param/analog can be around 6/10 dp-elements, and one element_device can have around 20/40 alarms, 20 states, 10 params, 15 analogs, 20/30 atributes.
One station can have around 50/60 element_device.
We need this tree structure for facility the alarms management, easy structure for maintenance, fast and easy reporting.
Thanks for all!
This datapoints has a tree datapoint structure that contains another dp-types than can be contains another dp-types....
The structure can be similar to this:
station
element_device (dp-type)
alarm (dp-type)
state (dp-type)
param(dp-type)
analog(dp-type)
atribute1 (dp-element)
atribute2 (dp-element)
............
element_device1 (dp-type)
alarm (dp-type)
state (dp-type)
......
attribute_station1
attribute_station2
.....
One alarm/state/param/analog can be around 6/10 dp-elements, and one element_device can have around 20/40 alarms, 20 states, 10 params, 15 analogs, 20/30 atributes.
One station can have around 50/60 element_device.
We need this tree structure for facility the alarms management, easy structure for maintenance, fast and easy reporting.
Thanks for all!
- xavi.aran
- Posts:63
- Joined: Thu Apr 21, 2011 1:21 pm
Re: error importing with WCCOAascii
Hi again! I need to open again this problem....because nobody can tell me why this limitation. Really is so dificult expand this number? Why??
Nobody makes projects with this number of datapoints? i can't belive....
My structures is the follow:
Station->-type of element ( Lift for example)
type of element ( escalator for example)
type of element ( ...)
......................................
type of element->Element ( Lift 01)
Element (Lift 02)
Element->Analog signals
State signals
Alarms signals
Params signals
atributes generics
XXX signals-> Some atributes ( some alarms, states, analogs, etc..)
Is very dificult for me split this tree in diferents trees ( for internal calculations, reports, maintenance....)
Please, can you check if expand this limitations is possible....is this is not possible maybe i will need to change the WinCCOA for another SCADA wihtout this limation....i'm very sad because i'm very happy with this.
Thanks,
Nobody makes projects with this number of datapoints? i can't belive....
My structures is the follow:
Station->-type of element ( Lift for example)
type of element ( escalator for example)
type of element ( ...)
......................................
type of element->Element ( Lift 01)
Element (Lift 02)
Element->Analog signals
State signals
Alarms signals
Params signals
atributes generics
XXX signals-> Some atributes ( some alarms, states, analogs, etc..)
Is very dificult for me split this tree in diferents trees ( for internal calculations, reports, maintenance....)
Please, can you check if expand this limitations is possible....is this is not possible maybe i will need to change the WinCCOA for another SCADA wihtout this limation....i'm very sad because i'm very happy with this.
Thanks,
- Gertjan van Schijndel
- Posts:634
- Joined: Mon Aug 02, 2010 10:37 am
Re: error importing with WCCOAascii
I think this limitation can be relative easy increased to 65535. But increasing it further would also increase the memory requirements and database size, so it makes the product less scalable.
I have seen a project with over a million dpe's, but never a project, that ran out of DpElementIds. Most projects use the panel topology to create a tree structure.
But you could also create multiple tree structures with cns, but there are no configuration panels available yet, only control and c++ functions.
I have seen a project with over a million dpe's, but never a project, that ran out of DpElementIds. Most projects use the panel topology to create a tree structure.
But you could also create multiple tree structures with cns, but there are no configuration panels available yet, only control and c++ functions.
- xavi.aran
- Posts:63
- Joined: Thu Apr 21, 2011 1:21 pm
Re: error importing with WCCOAascii
And can be possible in a next version change this limitation? Maybe in a config or a parameter when BD starts?
Please, answer, because nearly i have to start a new project and this problems will be a big problem for me.
Thanks,
Please, answer, because nearly i have to start a new project and this problems will be a big problem for me.
Thanks,
- fmulder
- Posts:330
- Joined: Wed Feb 03, 2010 9:46 am
Re: error importing with WCCOAascii
I can not imagine that anyone would ever make a datapoint type that is so big. I do remember that I once made some types (PID ?) that had a little over 1000 nodes.
Making bigger types doesn't seem to make much sense.
From an OO point of view : it doesn't make much sense to turn one station into a 'typical'. Each station will probably be a little bit different and you wont be able to 'just' copy the first station.
An object (e.g. datapoint type) should be soemthing that you can easily copy and re-use. A bigger object is normally not very re-usable.
What we often do is:
- Just display(!) the N objects as one big one. You can easily give an object a node called 'parent' and use this to build up a graphical(!) tree structure without needing the super-big datapoints
- WinCC OA support CNS. This is a way to model(!) a big structure. Unfortunatly, 3.12 doesn't have the feature to display this model. Or, in the database you can define a structure (e.g. a station) that is as big as you want. Internally, you're still using the small datapoijnt.
My advise:
- use smaller datapoints
- use scripting to display them as one big structure
....
- On the long term : consider using CNS (contact ETM for details)
Making bigger types doesn't seem to make much sense.
From an OO point of view : it doesn't make much sense to turn one station into a 'typical'. Each station will probably be a little bit different and you wont be able to 'just' copy the first station.
An object (e.g. datapoint type) should be soemthing that you can easily copy and re-use. A bigger object is normally not very re-usable.
What we often do is:
- Just display(!) the N objects as one big one. You can easily give an object a node called 'parent' and use this to build up a graphical(!) tree structure without needing the super-big datapoints
- WinCC OA support CNS. This is a way to model(!) a big structure. Unfortunatly, 3.12 doesn't have the feature to display this model. Or, in the database you can define a structure (e.g. a station) that is as big as you want. Internally, you're still using the small datapoijnt.
My advise:
- use smaller datapoints
- use scripting to display them as one big structure
....
- On the long term : consider using CNS (contact ETM for details)
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: error importing with WCCOAascii
Hello,
I just talked to our developers. Changing this limit is not a simple task because all parts of the database are affected. Also we have to do some changes for the alert handling, datapoint functions and archiving functionality which refer to the DPE-IDs (which have then another range).
WinCC OA is using internally only DPE-IDs, the datapoint names can only be seen when converting the DPE-ID into a string, e.g. in the user interface, in an ASCII-file, ...
As described before you can use the feature CNS (Common Name Service) to build complex structures, similar to the structure of datapoint-types.
Within this (user defined) structure you can combine the information for several datapoints. Accessing this information is working in nearly the same way like accessing a datapoint element.
CNS uses "views" as 1-st level information. You can create several views for different tasks, e.g. a view for an operator, a view for a administrator, a view for a guest-user.
Within this "view" you can create several "trees" (structure information). The leafs within a tree can refer to a datapoint.
By accessing the "view + tree + leaf" you can address datapoint elements.
If you are interested in this feature I can give you a preview of the documentation. Then you can have detailled look at it.
I just want to inform you that right now not all CTRL-functions (e.g. query functions) are supporting CNS, for basic tasks it can be used.
Another opinion would be to take a look at the current configuration of your project.
Maybe we can find another solution where the limit of dp-elements for a singe datapoint-type is not exceeded.
If you want to choose this option please get in contact with the official WinCC OA support (http://support.automation.siemens.com). Then we can tell you which parts of the project are needed for the analysis. There is no need to get the complete project (inlcuding historical information).
Best Regards
Leopold Knipp
Senior Support Specialist
I just talked to our developers. Changing this limit is not a simple task because all parts of the database are affected. Also we have to do some changes for the alert handling, datapoint functions and archiving functionality which refer to the DPE-IDs (which have then another range).
WinCC OA is using internally only DPE-IDs, the datapoint names can only be seen when converting the DPE-ID into a string, e.g. in the user interface, in an ASCII-file, ...
As described before you can use the feature CNS (Common Name Service) to build complex structures, similar to the structure of datapoint-types.
Within this (user defined) structure you can combine the information for several datapoints. Accessing this information is working in nearly the same way like accessing a datapoint element.
CNS uses "views" as 1-st level information. You can create several views for different tasks, e.g. a view for an operator, a view for a administrator, a view for a guest-user.
Within this "view" you can create several "trees" (structure information). The leafs within a tree can refer to a datapoint.
By accessing the "view + tree + leaf" you can address datapoint elements.
If you are interested in this feature I can give you a preview of the documentation. Then you can have detailled look at it.
I just want to inform you that right now not all CTRL-functions (e.g. query functions) are supporting CNS, for basic tasks it can be used.
Another opinion would be to take a look at the current configuration of your project.
Maybe we can find another solution where the limit of dp-elements for a singe datapoint-type is not exceeded.
If you want to choose this option please get in contact with the official WinCC OA support (http://support.automation.siemens.com). Then we can tell you which parts of the project are needed for the analysis. There is no need to get the complete project (inlcuding historical information).
Best Regards
Leopold Knipp
Senior Support Specialist