Professional OPC
Development Tools

logos

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.

QuickOPC with PowerShell - Register-ObjectEvent

More
23 Dec 2017 21:21 - 23 Dec 2017 21:21 #5771 by support
I have had a second look at your code.
I wonder whether it is complete - that is, there anything that follows the last line? :
$client.SubscribeMultipleMonitoredItems($arrMonitoredItems)
I am asking because there should be *something*. Some kind of code that keeps the script around. Either time-based waiting (such as "wait for 10 minutes", or even "wait indefinitely"), or waiting for an event (used input, for example) - but there should be some waiting. This is because the subscription notification happen over time, and during that time, the event handler must still be around...

Have a look at our examples in other programming languages, they all have that.

Regards
Last edit: 23 Dec 2017 21:21 by support.

Please Log in or Create an account to join the conversation.

More
18 Dec 2017 11:18 #5743 by Enrico
Take your time and thanks for taking care.

In the meanwhile I will check the Excel-Functionality.

I also will try to work with the pull mechanism in order to get updated data. This may be a workaround.

By the way, the documentation is extremely good!

Please Log in or Create an account to join the conversation.

More
17 Dec 2017 18:17 #5742 by support
Hello,

thank you for all the new information. I was hoping that the LogEntry info might contain an information about the crash, but unfortunately it is not the case.

Therefore, what I am going to do is to take your scripts, and try to reproduce the issue here. Please allow some time before I have some results.


With regard to the memory consumption, this may, or may not be an issue. The underlying code is in .NET which means that the memory is managed for us by Microsoft, and is non-deterministic. Issues that look like small "leaks" may show several days of increase and then drop back down; see www.opclabs.com/forum/ua-general/2278-internal-long-running-test-results . Each case requires individual analysis.

Best regards

Please Log in or Create an account to join the conversation.

More
16 Dec 2017 18:25 #5740 by Enrico
Some of the measurements are in the namespace 5, thus the correct list is as follows

$nsuDataNodes = @(
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1285'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1259'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1276'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1274'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1275'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1278'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1279'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1280'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1244'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1280'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1267'
'nsu=http://opcfoundation.org/UA/Boiler/;ns=4;i=1288'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=29'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=11'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=20'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=18'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=19'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=24'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=22'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=23',
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=4'
'nsu=http://opcfoundation.org/UA/Boiler//Instance;ns=5;i=15'
)

Please Log in or Create an account to join the conversation.

More
16 Dec 2017 12:24 #5739 by Enrico
No weekend yet, second try to attach the files :unsure:
Attachments:

Please Log in or Create an account to join the conversation.

More
16 Dec 2017 12:18 #5738 by Enrico
Update

(1A) dump file - I tried with DebugDia, if this is activated to watch the PowerShell, than the PowerShell closes each time when I try to start the QuickUAOPC Server - I stopped to spend time on this

(1B) dump file - I tried with WER, I set it up, that it should dump, when the PowerShell fails, but it does not, no idea why.

(2) ServerLogging - Here I was successful and could establish the logging. It was straight forward. Good feature! I have attached the logfile, containing the data of today. It covers, two PowerShell crashes. The other times I stopped the PowerShell for beginning a new test. The last entries are from a scenario where the PowerShell crashed.

(3) Reference scenario - I put together a reference script, that
* hooks on your server
* crashes (from time to time)
* generates a memory anomalie on my machine
* Is only subscribing to dedicated Data Nodes to make it more traceable (otherwise I just subscribe to all DataNodes, below a selected Node)

(4A) Memory anomalie - I discovered yesterday, that the memory consumption of the PowerShell is steadily increasing when activating the Subscriptions. I made a new, simiple file, where I'm sure that I do not produce any new objects, all the time. Thus the steadily increasing memory consumption should not be caused by the script itself. For the scenario in the script, the memory increase is around 5 MB per Minute on my machine.

(4B) Event handling - I thought that the memory increase is caused by not handled events. Thus I tried to increase are priority of the PowerShell Process. And yes, the memory increase was not as high as before, but the PowerShell than fails from time to time. (All tests done with the reference script).

(4C) Event handling - I also counted the events handled. The maximum was something like 700 Events (not done with the reference script). The number of events handeld by the reference script is far less. That should not be a problem. Also 700 Events, does not sound too much. When we do Big Data with Drools, then we get 20.000 measurements per second throug the machine.

(4D) Memory anomalie - The long duration test done two days before, already suffered with the not discovered memory increase, I believe. The PowerShell crashed three times the same time after the QuickOPCClient was started. This is very unusal. And also the data log, showed that the client was fading away. At that moment I tought it was caused by PowerSaving mechanism of my laptop. But now I'm sure it was due to memory overrun.

Can you check if you see the same effects on your maching, when running the reference script? Especially the memory overrun.

It's now time for the weekend ;o)

Please Log in or Create an account to join the conversation.

More
14 Dec 2017 18:17 #5735 by support
Hello,

one more thing (I realized this too late): When attaching the Visual Studio debugger (maybe do it once more), make sure that next to the "Attach to:" line, you press "Select", and select "managed (v4.6, v4.5, v4.0) AND "Native".

Best regards

Please Log in or Create an account to join the conversation.

More
14 Dec 2017 15:36 #5734 by Enrico
Hi

thanks, for taking care.

I have done trough the last night some long duration tests. The logger was fully functional for more than 8 hours when connecting to your demo server. It failed when using one of our own server also running in the internet. I have integrated now a throughput measurement to make sure I load the OPCEasyClient with the same number of measurements per second with the both configurations. Based on this I will repeat the long duration test tonight.

Advice 1: Doesn't really bring more information :o( It crashes without indicating why.

I will now follow Advice 2 (maybe using DebugDiag instead of WER) and Advice 4.

When I have more information I will get back to you.

Ciao

Please Log in or Create an account to join the conversation.

More
13 Dec 2017 16:34 - 13 Dec 2017 16:35 #5726 by support
Hello,

thank you for your investigation and findings.

obviously, QuickOPC should work regardless of whether the server is on the same computer or not. I do not know why it behaves the way you have described.

The interrelation between OPC UA servers and clients is pretty loose - we are talking about separate processes, connected through TCP. I would not dare to "blame" the servers for causing the issue (but of course there must be some indirect influence, if it behaves the way you described).

If you are fine with way it is now, so be it. Otherwise, if you find some time to hunt a bit more, following things may be worth doing:

1. The Visual Studio debugger I mentioned before.
2. There are some configurable settings for how Windows behave when an app crashes (I think it is called WER). On some computers it is silent, whereas on others it shows more.
3. Isn't there anything in Windows event log at the time of crash?
4. Attach an event handler to static EasyUAClient.LogEntry event (or, if accessing static members is a problem, to a LogEntry of EasyUAClientConfiguration instance), record the generated events to a file (flush it often - after after every event!), and check whetehr it does not have generate an information about the problem.
5. Try to do the same subscription using the demo app or Connection Explorer that comes with QuickOPC - hoping that it would also crash but somehow in a "better" way that would show more details.

QuickOPC is based on the OPC Foundation .NET stack for the lower communication layers, but puts a whole lot of its own on top of that. Thanks for the nice words :-)

Best regards
Last edit: 13 Dec 2017 16:35 by support.

Please Log in or Create an account to join the conversation.

More
13 Dec 2017 15:37 #5725 by Enrico
Hi,

thanks for the quick answer. I followed your request in using your public demo server. With that I could not reproduce the error.

Than I have hooked one of the OPCUA servers that are causing the errors also into the net, to make it available for you. I connected to that server, too. The problem also disappears.

Thus the idea was, that the server and the client should not run on the same machine. The two servers mentioned above, don't produce heavy data. I moved the LabVIEW server, which produces some data (200 measurements with 5 HZ) to a different machine, the client remained on mine. With that setup I can't reproduce the PowerShell crashing.

Thus it seems to me, that having a server and client on the same machine leads to a conflict in the event handling (deep in the system). Did you hear of such a problem?

The servers we are using are based on the OPCUA Stack from the UA Automation(LabVIEW and the C++ SDK). Do you have your own OPCUA stack?

I can also contact UA Automation if they had similar issues.

Thus at the moment it runs stable. QuickOPC is simple and really cool. Amazing ;o)

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.064 seconds