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.
CPU usage jumps to 100%
02 May 2018 06:04 #6281
by support
Replied by support on topic CPU usage jumps to 100%
Regarding how to make the settings from www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads in the C++ program:
The ReadAutomatic and WriteAutomatic properties are 32-bit signed integers, and Timeout.Infinite is -1 (all ones, in binary representation). I think (but I am not 100% sure) that LONG_MAX would be 2^32 -1, giving very long time but not the "never" semantics as intended. I think that -1 would be more appropriate.
And, the suggested code also includes setting static properties through EasyDAClient.SharedParameters. Since COM does not have static members, we have a made an object that you can instantiate and then set its instance properties, and that in effect would behave like setting the static property on EasyDAClient. The object is EasyDAClientConfiguration. So, in your code, you should also write an equivalent of the following two lines, using the EasyDAClientConfiguration object instead.
Best regards
The ReadAutomatic and WriteAutomatic properties are 32-bit signed integers, and Timeout.Infinite is -1 (all ones, in binary representation). I think (but I am not 100% sure) that LONG_MAX would be 2^32 -1, giving very long time but not the "never" semantics as intended. I think that -1 would be more appropriate.
And, the suggested code also includes setting static properties through EasyDAClient.SharedParameters. Since COM does not have static members, we have a made an object that you can instantiate and then set its instance properties, and that in effect would behave like setting the static property on EasyDAClient. The object is EasyDAClientConfiguration. So, in your code, you should also write an equivalent of the following two lines, using the EasyDAClientConfiguration object instead.
EasyDAClient.SharedParameters.Topic.SlowdownWeight = 0.0f;
EasyDAClient.SharedParameters.Topic.SpeedupWeight = 0.0f;Please Log in or Create an account to join the conversation.
02 May 2018 05:54 - 02 May 2018 05:56 #6280
by support
Replied by support on topic CPU usage jumps to 100%
Hello.
Regarding "Class not registered ":
Good sign is that the behavior differs depending on whether you are using the config file or not. This means that the file is named and picked up properly.
The "Class not registered" is most likely a negative side effect of turning off the boxing - see kb.opclabs.com/How_to_disable_prerequisites_boxing . When it is turned off, some prerequisites need to be installed manually. In this case, they are probably the OPC Core Components - from opcfoundation.org/developer-tools/developer-kits-classic/core-components/ .
Best regards
P.S.
I do not understand the part about messageBox - there was none to be expected. If you refer to the "displayProgress" setting, the progress would be in the trace output.
Regarding "Class not registered ":
Good sign is that the behavior differs depending on whether you are using the config file or not. This means that the file is named and picked up properly.
The "Class not registered" is most likely a negative side effect of turning off the boxing - see kb.opclabs.com/How_to_disable_prerequisites_boxing . When it is turned off, some prerequisites need to be installed manually. In this case, they are probably the OPC Core Components - from opcfoundation.org/developer-tools/developer-kits-classic/core-components/ .
Best regards
P.S.
I do not understand the part about messageBox - there was none to be expected. If you refer to the "displayProgress" setting, the progress would be in the trace output.
Last edit: 02 May 2018 05:56 by support.
Please Log in or Create an account to join the conversation.
01 May 2018 14:42 - 01 May 2018 15:08 #6279
by MPick
Replied by MPick on topic CPU usage jumps to 100%
For the second test you mentioned, I'm setting things up as below. I followed the same pattern for the TopicParameters as was used for the EasyDAClient in the examples, but I would like to confirm that this was the correct thing to do. Also should I use LONG_MAX or something else like 0 or -1 in place of Timeout.Infinite?
Not sure if the issue still occurs with this configuration yet.
Edit: The error still occurs with the changes made above.
Not sure if the issue still occurs with this configuration yet.
_EasyDAClientPtr ClientPtr;
_EasyDATopicParametersPtr topic_params;
DAClient(std::shared_ptr<json> InputTags, std::shared_ptr<PCS::ZMQ_Publisher>& opc_writeback_publisher,
_bstr_t _machinename, _bstr_t _servername) : machinename(_machinename), servername(_servername){
CoInitializeEx(NULL, COINIT_MULTITHREADED);
topic_params = _EasyDATopicParametersPtr(__uuidof(EasyDATopicParameters));
topic_params->SlowdownWeight = 0.0f;
topic_params->SpeedupWeight = 0.0f;
ClientPtr = _EasyDAClientPtr(__uuidof(EasyDAClient));
ClientPtr->InstanceParameters->UpdateRates->ReadAutomatic = LONG_MAX;// Timeout.Infinite;
ClientPtr->InstanceParameters->UpdateRates->WriteAutomatic = LONG_MAX;// Timeout.Infinite;
//default write item timeout is 60000, which means we get 60 cycles behind since we're being given new data every secondish
ClientPtr->InstanceParameters->Timeouts->WriteItem = 900;
//setup callback
AtlGetObjectSourceInterface(ClientPtr, &EventCallback.m_libid, &EventCallback.m_iid,
&EventCallback.m_wMajorVerNum, &EventCallback.m_wMinorVerNum);
EventCallback.m_iid = _uuidof(DEasyDAClientEvents);
EventCallback.DispEventAdvise(ClientPtr, &EventCallback.m_iid);
EventCallback.set_dependancies(opc_writeback_publisher, InputTags);
}
~DAClient() {
ClientPtr->UnsubscribeAllItems();
ClientPtr = NULL;
topic_params = NULL;
CoUninitialize();
}Edit: The error still occurs with the changes made above.
Last edit: 01 May 2018 15:08 by MPick.
Please Log in or Create an account to join the conversation.
01 May 2018 13:41 - 01 May 2018 15:06 #6278
by MPick
Replied by MPick on topic CPU usage jumps to 100%
I've got the following configuration file:
But when I use this config file the component gives me the error "Class not registered " when attempting to write. I've named the config file appropriately, and do not get this error when not using the config file. Any ideas?
edit: I forgot to mention I do not see a messageBox pop up
<configuration>
<appSettings>
<add key="OpcLabs.EasyOpc.Implementations.Native.Assemblies.EnableVC140RedistBoxer" value="false"/>
<add key="OpcLabs.EasyOpc.Internal.OpcPSBoxing.EnableOpcCorePSBoxer" value="false"/>
<add key="OpcLabs.EasyOpc.UA.Toolkit.UAClientEngineBase.EnableUACertificateGeneratorBoxer" value="false"/>
</appSettings>
<system.diagnostics>
<switches>
<add name="OpcLabs.Boxing.DisplayProgress" value="1" />
</switches>
</system.diagnostics>
</configuration>But when I use this config file the component gives me the error "Class not registered " when attempting to write. I've named the config file appropriately, and do not get this error when not using the config file. Any ideas?
edit: I forgot to mention I do not see a messageBox pop up
Last edit: 01 May 2018 15:06 by MPick.
Please Log in or Create an account to join the conversation.
30 Apr 2018 16:12 #6277
by support
Replied by support on topic CPU usage jumps to 100%
Note that the actual file name is *not* app.exe.config. In place of 'app', there should be the actual name of your EXE.
Verification is possible using instructions at kb.opclabs.com/QuickOPC-UA:_How_to_enable_extended_tracing . Majority of the switches listed there is for OPC UA, but the line
applies to OPC Classic as well.
First indication the the .config file is working is that you can actually create some output using this. And second, the output should differ depending on whether you turn off the "boxing" or not.
Best regards
Verification is possible using instructions at kb.opclabs.com/QuickOPC-UA:_How_to_enable_extended_tracing . Majority of the switches listed there is for OPC UA, but the line
<add name="OpcLabs.Boxing.DisplayProgress" value="1" />First indication the the .config file is working is that you can actually create some output using this. And second, the output should differ depending on whether you turn off the "boxing" or not.
Best regards
Please Log in or Create an account to join the conversation.
30 Apr 2018 15:40 #6276
by MPick
Replied by MPick on topic CPU usage jumps to 100%
I'm preforming the first test now. Since I'm using VC++ there isn't an app.exe.config file by default. I've added one as per the instructions in the link you posted, but I would like to validate that the feature is actually disabled. Is there a log file or something I can check to confirm this?
Please Log in or Create an account to join the conversation.
29 Apr 2018 13:45 #6274
by support
Replied by support on topic CPU usage jumps to 100%
Thank you. I think we can rule out GC as the cause, at least for now.
There is a second thing over which we have little influence ad that sometimes causes unexpected problems. I want to rule it out as well. Can you please perform the steps described here: kb.opclabs.com/How_to_disable_prerequisites_boxing .
If the above does not help: From your screenshots, there is a relation (of the time spent) to a particular algorithm/piece of code. It is possible to disable that as well. Instructions are here:
www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads
Can you please test that as well.
Regards
There is a second thing over which we have little influence ad that sometimes causes unexpected problems. I want to rule it out as well. Can you please perform the steps described here: kb.opclabs.com/How_to_disable_prerequisites_boxing .
If the above does not help: From your screenshots, there is a relation (of the time spent) to a particular algorithm/piece of code. It is possible to disable that as well. Instructions are here:
www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads
Can you please test that as well.
Regards
Please Log in or Create an account to join the conversation.
27 Apr 2018 18:38 #6273
by MPick
Replied by MPick on topic CPU usage jumps to 100%
I ran another test and it looks like the GC is behaving normally during the high CPU usage time. By which I mean, "# Gen X Collections" counters all increase at a slow rate similar to what they do when the CPU usage, and % Time in GC is near 0. I've attached the settings and image from PerfMon.
I've also attached the results of another debugging session from VS, where about 2 mins of data was collected while the CPU usage was 100%.
Any other ideas would be greatly appreciated. I'd be willing to share the code I'm using in case there's some grievous error in my usage of the QuickOPC api, but would prefer not to do so over a public channel.
I've also attached the results of another debugging session from VS, where about 2 mins of data was collected while the CPU usage was 100%.
Any other ideas would be greatly appreciated. I'd be willing to share the code I'm using in case there's some grievous error in my usage of the QuickOPC api, but would prefer not to do so over a public channel.
Please Log in or Create an account to join the conversation.
27 Apr 2018 17:15 #6272
by support
Replied by support on topic CPU usage jumps to 100%
Can you correlate the high CPU usage occurrences with times when .NET Garbage Collector is called? (e.g. using appropriate counters in PerfMon).
It could be the GC doing this.
Best regards
It could be the GC doing this.
Best regards
Please Log in or Create an account to join the conversation.
27 Apr 2018 16:01 #6269
by MPick
CPU usage jumps to 100% was created by MPick
Hi there,
I have an issue where after 5-10 minutes my opc-da client application jumps to 100 CPU usage. The opc client in this application can be disabled, and when it's disabled this issue does not occur. Typical CPU usage on the machine in question for this program is typically ~3% with short peaks of a about 20%.
The application is written in VC++, so I'm using the COM/procedural coding interface for your product.
The application is posting several hundred tags to an OPC server on the same machine at an update rate of roughly ~5s (though sets of ~100 tags are received at different times), with a smaller set of tags being posted every second (~15). A handful of tags are also being read back. I've used the 'WriteMultipleItemValues' and 'SubscribeItem' functions, with a a write timeout of 900ms since the thread that's calling the quick client has work to do every second.
From the CPU profiling I've done it looks like the QuickOPC component is making internal calls that result in this. I've attached CPU usage info for one debug session, mainly because I'm not sure what else to look at. That session was only in this state for a few seconds, the visual studio debugger struggles to collect usage data when the machine is completely choked out.
I realize this isn't a lot to go on, what sort of information can I collect to figure out why this is happening? Is there any known issue that I could be experiencing?
Thanks,
M
I have an issue where after 5-10 minutes my opc-da client application jumps to 100 CPU usage. The opc client in this application can be disabled, and when it's disabled this issue does not occur. Typical CPU usage on the machine in question for this program is typically ~3% with short peaks of a about 20%.
The application is written in VC++, so I'm using the COM/procedural coding interface for your product.
The application is posting several hundred tags to an OPC server on the same machine at an update rate of roughly ~5s (though sets of ~100 tags are received at different times), with a smaller set of tags being posted every second (~15). A handful of tags are also being read back. I've used the 'WriteMultipleItemValues' and 'SubscribeItem' functions, with a a write timeout of 900ms since the thread that's calling the quick client has work to do every second.
From the CPU profiling I've done it looks like the QuickOPC component is making internal calls that result in this. I've attached CPU usage info for one debug session, mainly because I'm not sure what else to look at. That session was only in this state for a few seconds, the visual studio debugger struggles to collect usage data when the machine is completely choked out.
I realize this isn't a lot to go on, what sort of information can I collect to figure out why this is happening? Is there any known issue that I could be experiencing?
Thanks,
M
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.078 seconds