Slow response when reading control module properties using VBA
Hi All,
We developed a VBA tool which reads different properties from the system and saves them to a database, and as it reads thousands of properties it takes quite a long time. Basically the program iterates through all objects in a control project and reads certain properties from objects of a given type, and there is the following code in the core:
SomeVar = obj.Aspect("Control module").Properties("SomeProperty").Value
We've noticed that for some properties the code above takes up to 5-7 seconds to execute, especially for VT_BSTR type and function blocks with extensible parameters.
Is there a more efficient way to read object properties or something we can improve?
Does the above code reads from the OPC cache or device?
Second question. Is it possible to get a sub collection of objects of a given type from the System.Objects(SomeRootObject) collection?
Currently, we simply iterate through all objects in the collection and skip the ones we are not interested in.
Thank you in advance.
We developed a VBA tool which reads different properties from the system and saves them to a database, and as it reads thousands of properties it takes quite a long time. Basically the program iterates through all objects in a control project and reads certain properties from objects of a given type, and there is the following code in the core:
SomeVar = obj.Aspect("Control module").Properties("SomeProperty").Value
We've noticed that for some properties the code above takes up to 5-7 seconds to execute, especially for VT_BSTR type and function blocks with extensible parameters.
Is there a more efficient way to read object properties or something we can improve?
Does the above code reads from the OPC cache or device?
Second question. Is it possible to get a sub collection of objects of a given type from the System.Objects(SomeRootObject) collection?
Currently, we simply iterate through all objects in the collection and skip the ones we are not interested in.
Thank you in advance.
Asked 1 year ago
Voted best answer
1
The System 800xA Aspect Automation VB API was not developed with high performance in focus.
Each creation and subsequent destruction of an ABBProperties object (the result of your .Properties("SomeProperty").Value construction) results in the creation of an OPC Handler (an internal acting OPC client) and OPC groups with the source OPC server.
Each creation and subsequent destruction of an ABBProperties object (the result of your .Properties("SomeProperty").Value construction) results in the creation of an OPC Handler (an internal acting OPC client) and OPC groups with the source OPC server.
REM Note!
REM May need to be called from 32-bit version of WScript
REM E.g.: C:\WINDOWS\SysWOW64\wscript.exe mytest.vbs
dim systems
set systems = CreateObject("ABB.ABBSystems")
dim system
set system = systems.defaultsystem
dim obj
set obj = system.object("[Control Structure]Root/Control Network 2/SoftProj2/Applications/Application_2/Diagrams/Diagram2")
dim props
REM -- ABBProperties object represents an entire OPC connection (handler + opc group). Create/delete => large overhead
set props = obj.properties
REM -- property value is default member and can be omitted
REM --
props("Diagram:bool") = true
props("Diagram:int") = 1
props("Diagram:float") = 3.14
props("Diagram:string") = "hello"
props ...
props ...
Answers
0
Hi!
I would be very careful to use this kind of solution in a production system.
Generally: Controllers and PLC's are made for controlling a process. Execution of logics and control loops are essential. (Handling of strings is not the main focus...) Communication is "secondary" and will be handled if the time is available.
In the case of system 800xA, it is possible to access "everything" in the scope of the OPC communication, but the connection to the (AC800M) controller (which has to service the bulk of the OPC-questions), is made on a low bandwidth network.
For connection of a client to an 800xA system, I would also strongly advise to use of the AfwOpcDASurrogate (out proc) Server in stead of using the internal OPC-server. This will however not improve performance, but will result in a more robust solution.
Please take a moment to reflect on how OPC (DA) and the 800xA System works: Read the OPC-manual 3BSE035983-610 carefully before rolling out a function like the one you are suggesting.
You can also find that there are built-in functionality like the Bulk Data Manager and DataDirect, which make use of Addins to MS Excel for data extraction.
Regards
I would be very careful to use this kind of solution in a production system.
Generally: Controllers and PLC's are made for controlling a process. Execution of logics and control loops are essential. (Handling of strings is not the main focus...) Communication is "secondary" and will be handled if the time is available.
In the case of system 800xA, it is possible to access "everything" in the scope of the OPC communication, but the connection to the (AC800M) controller (which has to service the bulk of the OPC-questions), is made on a low bandwidth network.
For connection of a client to an 800xA system, I would also strongly advise to use of the AfwOpcDASurrogate (out proc) Server in stead of using the internal OPC-server. This will however not improve performance, but will result in a more robust solution.
Please take a moment to reflect on how OPC (DA) and the 800xA System works: Read the OPC-manual 3BSE035983-610 carefully before rolling out a function like the one you are suggesting.
You can also find that there are built-in functionality like the Bulk Data Manager and DataDirect, which make use of Addins to MS Excel for data extraction.
Regards
Answered 1 year ago
Add new comment