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.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Reconnection to Schneider OPC Factory Server
Reconnection to Schneider OPC Factory Server
To the AddItems calls: When we add an item to an OPC group for a reason, and is not being used for some time, we remove it. That's what has happened to the tags you have previously written to - and that's why we need to call AddItems again. The "hold time" is configurable, so you can prolong it if you like. In fact, if the server has a bug related to adding/removing items, doing so may be a workaround for the problem.
www.quickopc.com/files/onlinedocs/QuickOpc/5.22/Reference/Qu...dcc-e84c-7d36-91511298df30.htm
www.quickopc.com/files/onlinedocs/QuickOpc/5.22/Reference/Qu...3be-3460-080d-9b43e7aa5624.htm
Best regards
Please Log in or Create an account to join the conversation.
In the first "plc shutting down.tra", our app starts up at 15:37:02.816 (I believe the entries prior to that were caused by one read subscription from an instance of the EasyOPC.NET Demo Application).
The system operates normally until 15:40:30.519 when the first (and all subsequent) writes fail.
At 15:40:30.784 OnDataChange to the EasyOPC.NET Demo Application fires with an error.
At 15:40:30.802, our app receives the equivalent OnDataChange error.
After that point, in addition to a bunch of failed writes, it looks like the system is repeatedly calling AddItems with various tags which it was previously writing to. I don't understand this.
The second trace 'app restart after plc restart.tra', continues like the first one left off.
At 15:50:55.713 our app was shut down (the last message in the log was occurred at that time, shutdown was requested slightly prior).
15:51:16.219 is the time of the first entry in the log after restart. After restart, data reads and writes normally.
I don't know exactly when the PLC reboot completed, but I believe it was before our app shutdown at 15:50:55.713.
I did not try synchronous writes instead of asynchronous (even if writes worked after the PLC restart, we would still have the issue of the read subscription not functioning properly).
Please review and if you still believe the OPC vendor is at fault for both reads and writes not working post-plc-restart, I will direct them to this thread.
Regards,
Shea
Please Log in or Create an account to join the conversation.
You should send the trace file, and a link to this thread, with the analysis below, to the OPC Server vendor, and ask them to clarify why they are sending E_FAIL - or fix it.
Here are the first 2 calls and 1 callback in the trace:
1. We are asking for an item to be added to the OPC group.
2. We are asking for a value be written into that item.
3. The server responds with "OnWriteComplete" carrying an item-level E_FAIL result.
Note: It might be worth trying (as a workaround) to force the client to use OPC synchronous calls instead of asynchronous (which is what it does by default if they are available). Async is more complicated, and some servers are struggling with it. To do so, set ClientMode.AllowAsynchronousMethod of the EasyDAClient object instance to 'false' after creating it.
Please Log in or Create an account to join the conversation.
Does the trace contain enough information to troubleshoot the problem or do we need a trace of before/during/after?
Thanks,
Shea
Please Log in or Create an account to join the conversation.
After installing, enter any necessary information in the "Category Filter" and "Remote Machine Name" fields, and press the "Refresh" button. Then, select your target OPC server from the "Server" drop-down, and make sure the trace is started (if "TRACE STOPPED" is displayed, press the "start trace" button).
You then need to modify your application (or change the settings in the demo app) to connect to the OPC Analyzer instead of your real target OPC server; the OPC Analyzer acts as an intermediate logger. The ProgID of the OPC Analyzer is "OpcTestLab.OpcAnalyzer.1". You can then run your application, and you should see the trace being collected in the OPC analyzer. It might be helpful to make handnotes of times of any relevant events, such as the time when you have started the application, when the PLC was power-cycled, and when the exception occurred. After you are finished, select File -> Save Trace in the Opc Analyzer, save the .TRA file, and send it to us - ideally, attach it to your reply in this forum (unless it contains something confidential).
Note: The OPC Analyzer tool is available to OPC corporate members only (such as OPC Labs are), and you can only use it for the purpose of troubleshooting this particular problem.
Best regards
Please Log in or Create an account to join the conversation.
Do you have a link to download the analyzer?
A google search yielded this link but it would require setting up an OPC Foundation account (which I am okay doing if necessary):
www.opcfoundation.org/DownloadFile.aspx?CM=3&RI=359&CU=1
Thanks,
Shea
Please Log in or Create an account to join the conversation.
The OPC Analyzer is supposed to be side-effect free, but there is no absolute guarantee. In addition, there are two things to consider with it:
- your application needs to be changed to connect to OPC Analyzer's ProgID (and the OPC Analyzer configured to connect to the actual target OPC Server)
- when run for long time, it generates a large amount data.
As you have indicated that the problem can be actually be reliably reproduced, I would recommend simply doing the analyzer session, trigger the problem, collect the data, and revert to original system configuration.
Please Log in or Create an account to join the conversation.
There are reads (subscriptions) which stop updating and do not work again until the app is restarted (I didn't think to check the exception or inner exception on the reads but will do so next time it happens).
I am open to installing an OPC analyzer between the server and our application. I assume there will not be any side effects?
Thanks,
Shea
Please Log in or Create an account to join the conversation.
Can you tell me more about your application?
How often are the writen being issued?
What else is the app doing, OPC-wise? Are there reads as well, or subscriptions - and they are they affected?
Would be possible to simulate the situtation on-site with special setup, putting an OPC Analyzer (which both OPC client and server) in between your app and the target OPC server, and let it log the communication?
Thank you
Please Log in or Create an account to join the conversation.
The outer exception contains the error message:
'An OPC operation failure with error code -2147467259 (0x80004005) occurred, originating from 'OpcLabs.EasyOPCRaw.DataAccess.RawEasyDAClient'. The inner exception contains details about the problem.'
The inner exception contains the error message:
'Unspecified error'
Please advise.
Thanks,
Shea
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Reconnection to Schneider OPC Factory Server