Thanks a lot. We renamed the .exe, and the Applicationtitle, and generated a new certificate. That worked.
And the long transfer times come from the server, whenever they use a certain development view for the PLC. When they stop that view, transfer times are better.
Best regards,
Andreas

Hello,
What a question Three characters only: WPS.exe.
Best regards,
Andreas

Hello,

Thanks a lot for your reply - you share my impression that it's a configuration thing on the PLC side. The CPU load on the PC says the same.

Anyway, there is one thimg, let's call it an irregularity, I cannot explain and I feel very very uncomfartable with. As long as we start our PC program clicking the .exe in windows explorer or clicking a link on the desktop it runs fine - despite of the slowness.
If we start the .exe by calling it from the commandline, the communication does not work at all. This is strange - usually it should not matter how the program is started.
For every attempt to call a WriteValue or ReadMultipleItems we have an exception in our log file which looks like in the attached log excerpt.:
I saw several similar ´looking stack traces in some forum entries, but could not find anything useful in there for me.
Can you help with that?

Best regards,
Andreas

Hello,
this helped a bit. At least the software does not crash any more, and all the non-communication-releted functions work fine.
Anyway, communication seems to be slow: 450 msec typically for requesting 70 variables in a single ReadMultiple call is much slower as we have seen before.
What is a good UA data rate in your experience?
Andreas

Hi,
we have a test bench software using QuickOPC (2018.3) for OPC UA communication with a S7 PLC. The (Windows) application runs without problems in two installations (unfortunately in China, and we don't have access any more)...
Now, our customer ordered a new testbench here in Germany.
We took the code, installed it on a PC of our costomer and ran into a nightmare.

First problem is solved already: Our program did not generate the certificate for the client. We created one with the Opc.Ua.CertificateGenerator. Worked fine.

The application itself is a windows apllication handling test parameters and results in a (SqlServer Express) database.
The communication architecture is pretty basic, an EasyOPCClient instance is polling values from the PLC (ReadMultipleValues) driven by a windows timer, and then there are WriteValues for interactions from the user. Nothing fancy.
Communication is hidden behind an interface (with functions like GetAllValues() and WriteThisAndThat()). We have two implementations: a dummy for simulated tests (without QuickOPC) and a real QuickOPC UA implmentation.

The program works fine with the simulation. As soon as we use the real thing, the nightmare starts again.
As long as we keep our fingers off the program, it seems to run fine, and shows the values we read from the PLC.
As soon as we interact with the program (e.g. open a form that shows parameter sets in our database or a list of protocols), the program crashes at random places. The user interactions that causes the crash doesn't even need to be communication-related. There are no exceptions shown in our log file (we have try/catchs with logging around Application.Run() and around the EasyOPCClient calls). The eventlog shows GPFs (error code 000005) in an 'unknown' module or (sometimes) in ntdll.dll.
For me it looks like some unwanted interaction in maybe a secondary message loop or so - but I have no idea what happens behind the scenes of EasyUAClient.
As I said, we have two installations of the same code that run fine.
Operating system on the new PC is Windows 10 Entrerprise 22H2.
Any idea?

Andreas