Hello!

Thanks for the detailed answer.

I am asking b/c I would like to be aware of (any) drawbacks of using COM objects.

For instance there is an integration tool pythonnet , would it be "more beautiful" than COM objects accesses? There would be a reason for using pythonnet instead of pywin32?

The aim is to have a reliable OPC UA connection with as little overhead as possible - as the OPC UA communication would happen in a thread.
Basically we use OPC UA server as a gateway between the field and the higher controlling system PC.
The requested publishing interval would be some 100 milliseconds, currently we are testing 300 ms as our processes don't require higher refresh rate.

I don't know whether you have experience from customers using this kind of system (QuickOPC, Python, COM, publishing interval ~300 ms)?

Thanks for your help in advance.

Best Regards!

Hello.

pybind11 is a binding to C++. That would not be a good idea with QuickOPC. Most of QuickOPC is written in .NET (C#). There is a COM layer on top of that. That already is somewhat ugly, but makes it consumable from Python. Pybind11 will have to be used on top of that. So you will have QuiOPC.NET -> COM -> C++ -> pybind11 -> Python. Too much complexity and no gain.

Best regards

Hello!

Thanks for your answer.

There is one more thing, as I have mentioned I went for COM objects, but I am wondering, it would be better if I implemented QuickOPC via pybind11 ?

Thanks for your help in advance.

Hello.

Thanks for asking.

It is absolutely OK to have multiple instances of QuickOPC client objects (EasyDAClient, EasyAEClient, EasyUAClient). They are actually designed to be used that way! And, at least in the default setting, QuickOPC acts as a "broker" - it merges the requests made from the different client instances. So for example, you will get just one connection to every target server, even if you have many client objects using it. (this can be changed, but only if needed, by setting EasyXXClient.Isolated to 'true').

I would only recommended against having a *huge* number of the clients - I mean, tens of thousands or so. There is some resource consumption (memory, CPU) associated with each of them. But having couple of them, tens, hundreds - should be no problem.

Best regards

Hello!

I would like to ask for some help.
Currently I am using your trial version but in the end I would like to buy a QuickOPC Ultimate, but first I have to convince my boss.

I am developing in Python so I went for COM objects.

I created a draft class with actually two methods, a subscription one and a write value one.

Here is the gist .

I would like to avoid marshaling, unmarshaling COM objects between different threads, so I instantiate the client object within each method (which can run in different worker threads), I mean within _subscribe_multiple_monitored_items or _write_value.

I have done some tests and it seems to me that there is no drawback, I mean the 2nd client can pick up the existing connection without any issue.

So the question is that it would be a good practice?

Thanks for your help in advance.

BR!