07/04/2023
Hi,
Using Advosol OPC DA SDK for .NET 6/7 and OPC Core Components 3.00.108 (latest?)
Our target OPC server is a SattLine ADSOPC in-proc OPC server.
We are facing a limitation when writing an OPC group with more than 511 items in it.
We get a weird error “-2147023843 The service did not respond to the start or control request in a timely fashion” returned through the Advosol OPC SDK.
We have tried swapping dll’s (using our customers ADSOPC.dll), upgrading/downgrading number of CPUs, different O/S, different OPC server (ABB, Kepware sim.). All work in our environment but not in the customer’s environment.
Do anyone know of this limitation (probably 512 tags per write request) or where this can be set or investigated?
BR
Ulrik
07/04/2023
Our project is about upgrading an old application (VB6 with OPCDAAuto.dll from around year 2001).
– The old application works fine both in our dev and in the customers test environment
– The old application uses async reads and writes (callbacks) (the new one does so too)
If there is a group write limit imposed in the customers SattLine OPC server configuration, the old application should also “block” on groups larger than 512 tags I would think.
So “something” is communicating differently with the SattLine OPC server in the new application or the SattLine OPC server is acting differently when a modern OPC DA SDK kit is communicating with it or something completely different – in the customers environment.
For now, I dont see a reason for rewriting the group-write mechanism, as it works perfectly in our development environment against ABB SattLine and Kepware with download groups of 2000 tags which is the maximum limit production recipes will be.
Best
Ulrik
07/04/2023
Well, it doesn’t seem to relate to the 512 tags limit. We have groups with less than 100 tags that fail as well.
Maybe something with data size of the “packets” being sent from either the OPC DA SDK through the OPC Core components and on to the ABB ADSOPC server?
We have already implemented a retry mechanism which retries the failed tags. It seems that the download completes after several retries. Maybe something about performance issues/bottleneck in the ABB OPC server because our new gateway performs way better and is multi-threaded as opposed to the old gateway (VB6) which was single-threaded.
One note to this is: All our recipe download groups are not subscribed and all tags in them are inactive. We have some groups (not recipe download groups) that have 1 active tag and where the group is subscribed. These are used to trigger upload and state changes (journalisation) from the SattLine system.
BR
Ulrik
1 Guest(s)