AVEVA™ Products Feedback Portal
Welcome to our new feedback site!
We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.
To start, select the product of your interest in the left column. Then take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas will first be moderated before they are made visible to other users of this portal.
This page is for feedback for specific AVEVA solutions, excluding PI Systems and Data Hub. For links to these other feedback portals, please see the tab RESOURCES below.
Hi All. This has now been corrected and fixed with significant speed improvements in Plant SCADA 2023 July Update 7. This is looking to be backported into the PS2020 line in a future service pack. It will also be included on the main branch for the PS2023R2 release.
I agree fully.
My understanding is that ODBC queries are being used to update the DBF records directly, to be able to respect manual adjustments that were made. This is the correct way, but it has a horrible performance rate.
Better would be to cache the dbf data in RAM first, perhaps even in a proprietary format. Then perform all the generation queries and write it back to disk as a dbf.
And if there have been no manual adjustments, just build a new file from scratch. This way a task that currently takes hours, can be done in seconds.
For a longer term solution: replace the dbf files with a fast configuration database.
it seems to me that a lot of the inefficiencty comes from the fact that it accomodates an incremental update so that any manual tweaks to the generated tags can be maintained. Personally I create my templates so that all customisations are kept in the templates themselves and so if tags etc were corrupted, they could be regenerated. Also it is thenpossible to see all relevant details for a piece of equipment in the eq editor rather than having to parse every single generated item an analyse its impact. So if this is the case, generation should be a much simpler proposition. If a project meets this criteria, then the generator should have an option to do a once through generation and this should be much quicker.
This has been reported to Tech Support as well, and currently under investigation and working towards a fix to this solution. More information coming soon on this topic.