Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
Reads sometimes take longer than usual
21 Feb 2014 10:29 - 21 Feb 2014 10:31 #1731
by support
Reads sometimes take longer than usual was created by support
From: J.
Sent: Thursday, February 20, 2014 10:11 AM
To: Zbynek Zahradnik
Cc: A.
Subject: OPC performance problem
Hi Zbynek,
In July of 2013, we had an email conversation about a problems between QuickOPC and the Moxa OPC server. That runs fine now.
I have used QuickOPC on some other projects without any problems, but as you may have guessed, I need your help now
I have been porting an old application of a colleague which basically transfers data between OPC tags and a database.
It was using old-school OPC routines, leaked memory like crazy and crashed regularly. It uses instances of one class to transfer a bunch of tags.
After porting, the pseudo code of the class looks like this:
Class in reading mode (FROM_OPC_xxx)Class in writing mode (TO_OPC_xxx)
The instances of the class come in pairs, one for reading, one for writing.
When I run the app, it creates a log file like the one attached (Opc2RdWrService.log for 10 pairs). I wrote a small program to tabularize this data and generate the csv files attached.
When I run the app with one pair, everything runs fine. Around 140 ms for reading and less than 100 ms for writing (see file Results2.csv).
The more pairs I add, the slower the system becomes. Not all calls, but some of them and not always on the same groups. This is the result for 10 pairs:
It looks like the excessive delays happen every 20-40 calls to the QuickOPC library. It gets worse and worse when adding more pairs. Also the individual calls take longer and longer.
My questions are:
1. Do you have any idea what is causing this (the OPC client lib, the OPC server or my app)?
2. If so, do you have a remedy for it?
3. If not, where do we go from here? I know subscribing to OPC items is faster, but it will take some time to rework the app and I’m not convinced yet that it will work in high stress situations (all cores in 100% CPU for a long time).
The data was gathered on the following target system:
• Windows Server 2008 R2 running on a VmWare ESX server
• SimaticNet Softnet-IE version 8.2
• QuickOPC version 5.22
Nice to know:
• The tag names are quite long, something like "SIMATIC 400 5C.CPU 416-3 DP.DB_MODOC.STATOC[1].OcOpdrachtNr"
• The target system may read/write as many as 100 pairs
If you need OPC log files, please let me know. You have sent me OPCAnalyzer 1.03.1014.msi in the past. If I need another version, please email it to me (we have no OPC membership).
Thank you in advance.
Met vriendelijke groeten, Kind regards,
J.
Sent: Thursday, February 20, 2014 10:11 AM
To: Zbynek Zahradnik
Cc: A.
Subject: OPC performance problem
Hi Zbynek,
In July of 2013, we had an email conversation about a problems between QuickOPC and the Moxa OPC server. That runs fine now.
I have used QuickOPC on some other projects without any problems, but as you may have guessed, I need your help now
I have been porting an old application of a colleague which basically transfers data between OPC tags and a database.
It was using old-school OPC routines, leaked memory like crazy and crashed regularly. It uses instances of one class to transfer a bunch of tags.
After porting, the pseudo code of the class looks like this:
Class in reading mode (FROM_OPC_xxx)
Create and initialize DAItemDescriptor[] Args = new DAItemDescriptor[53];
Every 3 seconds
{
new EasyDAClient().ReadMultipleItems(SrvDsc, Args);
if (results are ok)
WriteToDatbase();
}
Create and initialize DAItemValueArguments[] Args = new DAItemValueArguments[37];
Every 3 seconds
{
ReadFromDatabase();
if (results are ok)
new EasyDAClient().WriteMultipleItemValues(Args);
} The instances of the class come in pairs, one for reading, one for writing.
When I run the app, it creates a log file like the one attached (Opc2RdWrService.log for 10 pairs). I wrote a small program to tabularize this data and generate the csv files attached.
When I run the app with one pair, everything runs fine. Around 140 ms for reading and less than 100 ms for writing (see file Results2.csv).
The more pairs I add, the slower the system becomes. Not all calls, but some of them and not always on the same groups. This is the result for 10 pairs:
It looks like the excessive delays happen every 20-40 calls to the QuickOPC library. It gets worse and worse when adding more pairs. Also the individual calls take longer and longer.
My questions are:
1. Do you have any idea what is causing this (the OPC client lib, the OPC server or my app)?
2. If so, do you have a remedy for it?
3. If not, where do we go from here? I know subscribing to OPC items is faster, but it will take some time to rework the app and I’m not convinced yet that it will work in high stress situations (all cores in 100% CPU for a long time).
The data was gathered on the following target system:
• Windows Server 2008 R2 running on a VmWare ESX server
• SimaticNet Softnet-IE version 8.2
• QuickOPC version 5.22
Nice to know:
• The tag names are quite long, something like "SIMATIC 400 5C.CPU 416-3 DP.DB_MODOC.STATOC[1].OcOpdrachtNr"
• The target system may read/write as many as 100 pairs
If you need OPC log files, please let me know. You have sent me OPCAnalyzer 1.03.1014.msi in the past. If I need another version, please email it to me (we have no OPC membership).
Thank you in advance.
Met vriendelijke groeten, Kind regards,
J.
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.049 seconds